1. Ownership and governance
- The engineering owner must maintain the SSDLC, assign an accountable security reviewer, and record the named approver and adoption date before representing it as formally adopted.
- Each security-sensitive change must have an implementation owner and a reviewer. Where staffing limits independent internal review, document the limitation and obtain a qualified review before approval.
- Review this policy at least annually and after material architecture, authentication, data-handling, or incident-response changes. Record revisions and role-appropriate secure-development training.
2. Requirements, data flows, and threat assessment
- Identify sensitive data, permitted uses, retention and deletion needs, third-party processors, OAuth scopes, and the systems that store or transmit the data.
- Document trust boundaries and threats for authentication, Team and account isolation, privilege escalation, connector actions, token handling, and agent or runtime execution.
- Review new permissions, external endpoints, dependencies, storage, and infrastructure changes for least privilege and abuse cases before implementation. Maintain an architecture and data-flow record that matches the actual service.
3. Secure implementation and review
- Use server-side authorization, validated inputs, safe output encoding, appropriate CSRF defenses, controlled outbound destinations, and safe error handling. Evaluate applicable OWASP risks.
- Keep credentials out of source code, client-side bundles, URLs, logs, and test artifacts. Require protected transport, encrypted sensitive storage, and scoped access to secrets and connected accounts.
- Review security-sensitive code and dependency changes before release. Record the change, reviewer, security considerations, and resolution of findings; distinguish dependency analysis from source-code security analysis.
4. Verification and release decision
- Run applicable functional and negative security tests, source-code security analysis, dependency and secret checks, and authorized dynamic security tests under the Application Security Testing Policy.
- Validate cross-Team and cross-account denial, OAuth state and token handling, credential redaction, and access to sensitive files and APIs. Preserve the tested version, test results, and coverage limits.
- Block release for known exploitable critical findings. Resolve high-severity findings or document compensating controls, an accountable security approval, and an expiry date before release. Missing required verification must remain visible in the release decision.
- Record the release approver, exact source and artifact identity, verification evidence, deployment authorization, and rollback plan. Server software installation or replacement requires explicit approval of the exact operation; security work does not authorize automatic updates.
5. Maintenance, incidents, and records
- Review vulnerability notices and security reports, triage findings by severity and exposure, assign owners, and verify remediation. Prepare software updates for explicit approval rather than enabling unattended installation.
- For a suspected incident, preserve evidence, contain exposure, revoke affected credentials where authorized, investigate, and make notifications required by applicable obligations.
- Retain threat assessments, reviews, test evidence, release decisions, exceptions, and remediation/retest records under the evidence requirements in the security overview. An expired exception requires a fresh decision.
Questions and evidence requests
Contact [email protected] for security policy questions, evidence requests, or corrections to this disclosure. Do not include passwords, access tokens, or sensitive customer data in an initial message.
Related documents: security overview, Privacy Policy, and Terms of Service.