Secure SDLC Policy Template: Security Gates from Design to Release

Secure development fails when security checks are optional, run by whoever remembers, and skipped when a release is late. This template turns secure development into a policy with defined gates from design to release: security requirements, threat modelling, code review, automated testing, secrets scanning, protected build pipelines, signed releases and vulnerability response. It is organised around the four practice groups of the NIST Secure Software Development Framework (SSDF, SP 800-218) and gives explicit rules for the non-human identities that pipelines depend on, such as CI service accounts, deployment tokens and code signing keys. It is written for engineering leaders, application security teams and CISOs who need a policy that developers can follow and auditors can test. Adapt the values in brackets and approve the final text through your normal governance route.

How to use this template

• Replace text in square brackets, such as [Organisation], [AppSec team] and [30 days], with your own terms and values. Values in brackets are illustrative.
• "Must" is mandatory; "should" is recommended practice where a documented deviation is acceptable.
• Gates scale with risk. Assign every application a [risk tier 1 to 3] and apply the gate table below by tier, so a static marketing site does not carry the same burden as a payments service.
• Keep tool names out of the policy. Name tools (SAST, SCA, secret scanner, signing service) in a supporting standard that can change without re-approval.
• Use this alongside the [Patch Management Policy] for deployed third-party software and the [Vulnerability Management Policy] for findings in production.

Security gates by stage

1. Purpose

This policy sets the minimum security requirements for software developed, modified or configured by or for [Organisation]. It aims to reduce the number and severity of vulnerabilities in released software, protect source code and build systems from tampering, give customers and regulators evidence of how software is built, and respond quickly when vulnerabilities are found, in line with [Organisation]'s [Information Security Policy].

2. Scope

This policy applies to:

• All software developed by [Organisation] staff or contractors, including web and mobile applications, APIs, internal tools, scripts and automation, and AI-enabled features.
• Infrastructure as code, container images, pipeline definitions and configuration managed in source control.
• Software built for [Organisation] by suppliers, through contract requirements (section 4.9).
• Source code repositories, CI/CD systems, artefact registries, package feeds and the identities and credentials they use.
• Code produced with AI coding assistants, which is subject to the same gates as any other code.

Commercial software that [Organisation] only configures and runs is covered by the [Patch Management Policy] and [Third-Party Risk Procedure].

3. Roles and responsibilities

4. Policy statements

4.1 Prepare the organisation (SSDF PO)

• [AppSec team] must maintain a secure development standard covering coding rules, approved languages and frameworks, and gate thresholds, mapped to [OWASP ASVS level].
• Every application must be registered in [application inventory] with an owner and risk tier before its first production release.
• Developers must complete secure coding training on joining and at least [annually]; content must reflect the languages they use.
• Development, test, build and production environments must be separated. Production data must not be used in non-production without [Data protection officer] approval and masking.
• Developer endpoints must meet the [Endpoint Security Standard], and access to repositories and CI/CD must use SSO with phishing-resistant MFA.

4.2 Design (SSDF PW.1 and PW.2)

• Security and privacy requirements must be recorded for each new system or significant change, including authentication, authorisation, logging and data protection needs.
• Tier 1 and Tier 2 systems must be threat modelled before build starts and after significant architectural change, with mitigations tracked as backlog items.
• Designs must apply secure defaults: no default passwords, MFA available by default, least privilege, and security logging enabled out of the box.

4.3 Code and review (SSDF PW.4, PW.5, PW.7)

• All changes to protected branches must be made through a pull request reviewed by at least [one] person other than the author. Tier 1 changes to authentication, authorisation or cryptography must be reviewed by a security champion or [AppSec team].
• Branch protection must prevent direct pushes, force pushes and self-approval on protected branches.
• Third-party components must come from [approved registries or mirrors], be pinned to specific versions, and be checked by SCA for known vulnerabilities, malicious packages and licence conflicts.
• AI-generated code must be reviewed and tested to the same standard as human-written code and must not be merged without a named human reviewer.

4.4 Secrets and non-human identities

• Secrets (passwords, API keys, tokens, private keys, connection strings) must not be stored in source code, pipeline definitions, container images or build logs.
• Secrets scanning must run on every push with blocking push protection enabled for all repositories. Bypasses must require a recorded reason and are reviewed by [AppSec team] within [2 working days].
• Any secret detected in a repository, history, image or log must be treated as compromised: revoked and rotated within [24 hours], not just deleted from the code.
• Pipelines must obtain cloud and deployment credentials through short-lived workload identity federation (for example OIDC tokens) where the platform supports it. Long-lived static credentials require an exception.
• Each pipeline service account must be unique to the pipeline and environment, have an owner, be scoped to least privilege, and be reviewed [quarterly]. Personal access tokens of individual developers must not be used in pipelines.
• Pipeline secrets must be stored in [approved secrets manager] or the CI platform's protected secret store, scoped to the environment and unavailable to builds triggered from forks or untrusted branches.

4.5 Build and pipeline integrity (SSDF PO.3, PO.5, PS.1, PW.6)

• Release builds must run on [Organisation]-managed or hosted build platforms, never on developer workstations, with each build isolated from other builds.
• Pipeline definitions must be version controlled and changes to them reviewed like code. Third-party CI actions, plugins and scripts must be pinned to an immutable reference (commit hash or digest) and integrity-checked.
• Administrative access to CI/CD, repositories and artefact registries must be limited to named [Platform team] members and logged.
• Build platforms should meet [SLSA Build Level 2] for all tiers and [Level 3] for Tier 1, so that provenance is signed and signing secrets are inaccessible to user-defined build steps.

4.6 Testing (SSDF PW.7 and PW.8)

• SAST, SCA and secrets scanning must run automatically in the pipeline for every change to Tier 1 and Tier 2 applications.
• A release must not proceed with unresolved Critical or High findings unless an exception is approved under section 5.
• Tier 1 applications must have dynamic or API security testing before each major release and an independent penetration test [annually] and after major change.

4.7 Release (SSDF PS.2, PS.3, PW.9)

• Release artefacts (binaries, packages, container images) must be signed, and deployment must verify signatures before running them.
• Code signing keys must be held in [HSM / managed key service], never exported to build agents or developer machines, used only through the signing service, and covered by a documented rotation and revocation procedure. Access to sign must be reviewed [quarterly].
• Each release must have provenance data and an SBOM generated at build time and archived with the release for [retention period].
• Deployments to production must be performed by the pipeline, not by hand, and recorded under the [Change Management Policy].

4.8 Respond to vulnerabilities (SSDF RV)

• [Organisation] must publish a vulnerability disclosure route and acknowledge reports within [5 working days].
• Vulnerabilities in [Organisation] software must be fixed within the timelines in the [Vulnerability Management Policy]; vulnerabilities known to be exploited must be handled as emergencies.
• Critical vulnerabilities and recurring vulnerability classes must have a root cause analysis, with fixes applied to the standard, the tooling or training, not only to the instance.

4.9 Suppliers

• Contracts for developed software must require adherence to this policy or an equivalent framework such as the SSDF, delivery of an SBOM, and notification of vulnerabilities within [X days].

5. Exceptions

• Exceptions must be requested by the application owner, assessed by [AppSec team] and recorded in [risk register] with the gate affected, reason, compensating controls and expiry date.
• Approval: [AppSec lead] for Medium findings and Tier 3 gates; [CISO] for Critical or High findings, long-lived pipeline credentials and any signing or secrets control.
• Exceptions must not exceed [90 days]. Emergency fixes may bypass non-blocking gates only with retrospective review within [5 working days].

See the Security Exceptions and Risk Acceptance Guide.

6. Compliance and monitoring

Gate results must be recorded automatically by the pipeline so compliance is measured from evidence, not attestation. [AppSec team] must report at least [quarterly]:

Repository audit logs, CI/CD administrative changes, signing service use and secret scanning alerts must be sent to [SIEM]. Non-compliant applications may be blocked from release; breaches by staff may be handled under [disciplinary procedure].

7. Review and approval

• Policy owner: [CISO], with [Head of Engineering]. Approved by: [risk committee] on [date].
• Reviewed at least annually, and after any significant software supply chain incident, a change in regulation, or a major change in development tooling.
• Version history: [version], [date], [summary of change], [approver].
• Related documents: [Information Security Policy], [Vulnerability Management Policy], [Change Management Policy], [Secrets Management Standard], [Third-Party Risk Procedure].

Implementation guidance

Rolling out the policy

1. Inventory and tier: list repositories and applications, assign owners and risk tiers.
2. Start with secrets and identity: enable secrets scanning with push protection, rotate what it finds, and move pipelines to workload identity federation. These give the fastest risk reduction.
3. Turn on gates in report mode for [one quarter], fix the backlog and tune false positives, then make them blocking for Tier 1, then Tier 2.
4. Harden the pipeline: branch protection, pinned actions, isolated runners, then signing and provenance.
5. Measure from pipeline data and review gate results with engineering leads each quarter.
6. Roll back safely: if a gate blocks releases at scale because of a tool fault, switch it to report mode under a time-boxed exception rather than removing it.

Decisions for small and large organisations

• Small teams: use the security features built into the source control and CI platform, a single risk tier, and an external penetration test for the main product.
• Large organisations: use the three tiers, a champions programme, central signing service and maturity measurement with OWASP SAMM, which covers 15 practices across Governance, Design, Implementation, Verification and Operations.

Common failure patterns

• Static keys in the build chain: in the Codecov breach, a cloud storage key exposed through a Docker image process let attackers alter a CI script that then sent customers' pipeline environment variables, including tokens and signing keys, to the attacker. Statements 4.4 and 4.5 address both sides.
• Delete, not rotate: leaked secrets removed from code but still valid.
• Gates that everyone bypasses: blocking scans with high false positives, so teams get permanent exemptions.
• Unpinned third-party actions: pipeline steps referenced by mutable tags that can be changed upstream.
• Signing keys on build agents: keys exported to runners where any build step can read them.

Framework mapping

NIST CSF 2.0 places all of this under PR.PS-06. Implementation detail sits in the Secure Software Development Lifecycle (SSDLC) Guide, the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide, the Secure Coding Guide, the CI/CD Security Guide and the CI/CD Pipeline Identity Security Guide. Sources: NIST SP 800-218, NCSC secure development and deployment guidance, OWASP SAMM, SLSA v1.0 levels, CISA Secure by Design and GitHub push protection documentation.

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Code Signing Security Guide · Secrets Management Guide · Software Supply Chain Security Guide · SBOM Guide