Secure SDLC Policy Template thirteen sections that turn secure development into a defensible, audit-readable policy
A free, copy-ready secure software development lifecycle policy template for AppSec, product security, security engineering, internal security, DevSecOps, platform engineering, vulnerability management, GRC and compliance teams, and CISOs who need to publish the rule for how the organisation builds, reviews, tests, ships, and maintains software so the audit, the regulator, and the engineering leadership all read against one document. Thirteen structured sections covering policy charter and authority, scope and lifecycle phase definitions and applicability matrix, roles and the approval ladder, security requirements at intake and design, threat modelling and secure design, secure build and dependency management, secure coding and code review, automated security testing across SAST and SCA and DAST and IAST and secrets scanning, manual security testing and penetration testing inside the lifecycle, release security gates with explicit pass criteria and waiver process, post-release vulnerability handling and patch management and incident loop, audit evidence and framework crosswalk, and review revision and sign-off. Aligned with NIST SP 800-218 SSDF Versions 1.1 and the CISA Secure Software Development Attestation, ISO/IEC 27001 Annex A 8.25 through A 8.34, SOC 2 CC8.1, PCI DSS 4.x Requirements 6.2 through 6.5, NIST SP 800-53 SA-3, SA-8, SA-11, SA-15, SA-17, SI-2, NIS2 Article 21, DORA Article 8, GDPR Article 25, HIPAA 164.308 and 164.312, the EU Cyber Resilience Act, OWASP SAMM, OWASP DSOMM, OWASP ASVS V1, the SLSA framework, and the BSIMM observation set.
Run the SSDLC policy on the live workspace, not on a static document drive
SecPortal pairs every release-gate finding, every code-scan detection, every threat-model action item, every retest evidence pack, every exception, and every framework crosswalk on one engagement record so the policy you publish is the policy your audit, your regulator, and your engineering leadership read against. Free plan available.
No credit card required. Free plan available forever.
Thirteen sections that turn secure development into a defensible policy
A secure software development lifecycle policy is the rule a security organisation publishes to declare how the firm builds, reviews, tests, ships, and maintains software so security is delivered as part of the engineering work rather than retro-fitted before release. The discipline matters because the audit, the regulator, the customer security questionnaire, and the engineering leadership all read against the same document for a consistent answer to the question, who has accountability for the security properties of the shipped software and what is the rule. The thirteen sections below cover the durable shape of the artefact, aligned with NIST SP 800-218 SSDF, the CISA Secure Software Development Attestation, ISO/IEC 27001 Annex A 8.25 through A 8.34, SOC 2 CC8.1, PCI DSS 4.x Requirements 6.2 through 6.5, NIST SP 800-53 SA family controls, NIS2 Article 21, DORA Article 8, GDPR Article 25, HIPAA, the EU Cyber Resilience Act, OWASP SAMM, OWASP DSOMM, OWASP ASVS, SLSA, and BSIMM. Copy the section that fits your stage and paste the rest as you go.
Copy the full policy (all thirteen sections) as one block.
1. Policy charter and authority
Open the policy with the firm intent and the executive authority. A reviewer reading the first paragraph should know who publishes the rule, which engineering organisation it covers, which executive signed it, and when it went into effect. ISO/IEC 27001 Clause 5.2 expects documented information security policies with named authority; NIST SP 800-218 SSDF practice PO.1.1 expects documented secure development policy. The secure SDLC policy sits one level below the umbrella information security policy and the application security programme charter, and one level above the operational secure coding standard, the threat modelling runbook, the release gate runbook, and the per-scanner triage workflow.
Policy title: Secure Software Development Lifecycle Policy
Policy version: {{POLICY_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Last review date: {{LAST_REVIEW_DATE}}
Next review date: {{NEXT_REVIEW_DATE}}
Policy purpose:
{{PLAIN_LANGUAGE_PURPOSE_PARAGRAPH}}
Policy objectives (the rule the audit reads against):
- Embed security activities into every lifecycle phase rather than retro-fitting before release.
- Maintain a documented threat model for every new application and every material design change.
- Run a baseline of automated security testing across SAST, SCA, DAST, IAST, secrets scanning, container image scanning, and infrastructure-as-code scanning on every change to in-scope code.
- Hold release gates with explicit pass criteria so security debt does not accumulate silently across releases.
- Operate a published exception ladder so accepted residual risk is distinct from undetected risk.
- Maintain an audit-readable evidence chain across requirements, design, build, review, test, release, post-release vulnerability handling, and policy revision.
- Retain release-gate decisions, waiver approvals, threat model action items, and post-release defects on the same workspace record as the engineering work that produced them.
Programme sponsor (executive authority that publishes the policy):
- Name: {{EXECUTIVE_SPONSOR_NAME}}
- Role: {{EXECUTIVE_SPONSOR_ROLE}}
Approving authority: {{APPROVING_AUTHORITY_NAME_AND_ROLE}}
Approval date: {{APPROVAL_DATE}}
Policy hierarchy:
- Parent policy: Information Security Policy and the Application Security Programme Charter.
- Sibling policies referenced by this policy:
- Vulnerability Management Policy (governs the wider finding lifecycle this policy plugs into for SAST, SCA, DAST, IAST, and secrets findings).
- Vulnerability Remediation SLA Policy (governs the SLA windows for development-phase findings and release-gate waivers).
- Security Exception Register Policy (governs the residual-risk path for development findings that cannot be remediated before release).
- Risk Acceptance Policy (governs the per-decision artefact behind every release-gate waiver and every accepted-risk finding).
- Audit Evidence Retention Policy (governs the retention of release-gate decisions, threat models, scan logs, and SBOMs).
- Secrets Management Policy (governs the credentials the development pipeline handles).
- Cryptographic Key Management Policy (governs cryptographic primitives the policy references in secure coding).
- Data Classification Policy (governs the data tiers the design phase reads against).
- SBOM Policy (governs the bill of materials the build phase emits).
- Acceptable Use Policy and AI System Acceptable Use Policy (govern the developer-machine and developer-AI-tool boundaries this policy depends on).
- Vulnerability Disclosure Policy (governs the inbound researcher channel that may report SDLC defects in shipped products).
- Incident Response Policy (governs the post-release security defect handling chain).
Frameworks the policy evidences (map your scope into Section 12):
- NIST SP 800-218 SSDF Versions 1.1 Practices PO.1.1, PO.1.2, PO.1.3, PO.2.1, PO.3.1, PO.5.1, PS.1.1, PS.2.1, PS.3.1, PW.1.1, PW.4.1, PW.4.4, PW.6.1, PW.7.1, PW.7.2, PW.8.1, PW.8.2, PW.9.1, RV.1.1, RV.1.2, RV.1.3, RV.2.1, RV.2.2, RV.3.1, RV.3.2, RV.3.3, RV.3.4.
- CISA Secure Software Development Attestation form (Self-Attestation Common Form).
- ISO/IEC 27001:2022 Annex A 8.25 (Secure Development Lifecycle), A 8.26 (Application Security Requirements), A 8.27 (Secure System Architecture and Engineering Principles), A 8.28 (Secure Coding), A 8.29 (Security Testing in Development and Acceptance), A 8.30 (Outsourced Development), A 8.31 (Separation of Development, Test, and Production Environments), A 8.32 (Change Management), A 8.33 (Test Information), A 8.34 (Protection of Information Systems during Audit Testing).
- SOC 2 Common Criteria CC8.1 (Change Management).
- PCI DSS 4.x Requirements 6.2 (Bespoke and Custom Software), 6.3 (Identify Vulnerabilities), 6.4 (Public-Facing Web Applications), 6.5 (Common Vulnerabilities).
- NIST SP 800-53 Rev. 5 SA-3 (System Development Life Cycle), SA-8 (Security Engineering Principles), SA-11 (Developer Security Testing and Evaluation), SA-15 (Development Process Standards and Tools), SA-17 (Developer Security Architecture and Design), SI-2 (Flaw Remediation).
- NIS2 Directive Article 21 (Cybersecurity Risk Management Measures).
- DORA Regulation Article 8 (ICT Risk Management Framework) and Article 9 (Protection and Prevention).
- GDPR Article 25 (Data Protection by Design and by Default).
- HIPAA Security Rule 45 CFR 164.308(a)(8) and 164.312.
- EU Cyber Resilience Act Articles 10 and 11.
- OWASP SAMM v2 Practices (PA-V Verification), OWASP DSOMM Levels 1 to 4, OWASP ASVS V1 Architecture, OWASP API Security Top 10, OWASP MASVS.
- SLSA Specification Versions 1.0 Source, Build, Provenance, Distribution layers.
- BSIMM Observation Set.
- Internal policy: {{INTERNAL_POLICY_REFERENCES}}
2. Scope, lifecycle phase definitions, and applicability matrix
Scope is the contested part of the policy at audit. Name what counts as in-scope software, which lifecycle phases the policy enforces, and how strictness tiers with service criticality. Tier services the way the rest of the security programme tiers assets so the activity intensity, the gate strictness, and the evidence depth scale with the underlying risk.
In-scope software classes:
- Customer-facing applications shipped under the {{ENTITY_NAME}} brand (web, mobile, desktop, API).
- Internal-facing applications that process customer data or that have administrative authority over production systems.
- Customer-facing infrastructure-as-code modules (Terraform, Pulumi, CloudFormation, Bicep, Ansible, Kubernetes manifests, Helm charts).
- Container images and base images published to customer-facing registries.
- Firmware embedded in hardware products under the {{ENTITY_NAME}} brand.
- Open-source projects the firm publishes externally under the {{ENTITY_NAME}} brand.
- Software-as-a-service offerings consumed by customers.
- {{ADDITIONAL_IN_SCOPE_SOFTWARE_CLASSES}}
Out-of-scope or modified-scope items:
- Marketing collateral, content websites, and short-link redirectors that do not host application code.
- Internal-only tooling consumed only by the {{ENTITY_NAME}} workforce that does not process customer data and that has no production write authority.
- One-off proof-of-concept code that does not enter the production release lifecycle.
- {{ADDITIONAL_OUT_OF_SCOPE_BOUNDARIES}}
Service criticality tiers (the policy applies activity intensity per tier):
- Tier 1 critical: customer-facing services with regulated data, payment processing, authentication, or material business impact. Activity baseline: full threat model at design, full automated test suite, manual security testing in the lifecycle, full release gate, post-release weekly continuous monitoring.
- Tier 2 important: customer-facing services without regulated data, internal services with administrative authority. Activity baseline: threat model at design for new services and material changes, automated test suite, manual testing at major releases, full release gate, post-release biweekly continuous monitoring.
- Tier 3 standard: internal-facing services with limited blast radius, supporting tooling. Activity baseline: lightweight threat model at design for new services, automated test suite, release gate, post-release monthly continuous monitoring.
Lifecycle phase definitions (the policy applies named activities per phase):
- Requirements: security requirements intake from the engineering ticket or design document, abuse-case capture, data classification check, regulatory check, privacy review check where applicable.
- Design: documented threat model, secure architecture review for material services, design pattern review against the secure coding standard, dependency selection review.
- Build: secure-by-default project scaffolding, locked dependency versions, reproducible build configuration, SBOM generation, build provenance recording.
- Code review: human reviewer required per the code review rule, automated security review (SAST, SCA, secrets scan) per the build configuration.
- Test: SAST and SCA on every change, DAST on a scheduled cadence against pre-production, IAST where supported, secrets scanning on every change, container image scanning per release, infrastructure-as-code scanning on every change.
- Release: release gate evaluation against published criteria, named release approver sign-off, SBOM publication, provenance attestation, post-release monitoring activation.
- Maintain: vulnerability intake, patch management, post-release security defect handling, dependency upgrade cadence, sunset and decommissioning discipline.
Environments in scope: {{IN_SCOPE_ENVIRONMENTS}}
Repositories in scope: {{IN_SCOPE_REPOSITORY_INVENTORY_REFERENCE}}
Container registries in scope: {{IN_SCOPE_CONTAINER_REGISTRIES}}
Build platforms in scope: {{IN_SCOPE_BUILD_PLATFORMS}}
Service tagging:
- Every in-scope service records the criticality tier, the data tiers it processes per the data classification policy, the regulated controls it falls under, the lifecycle phase the policy is currently enforcing for the service, the named service owner, and the named engineering accountable lead.
- The tagging lives on the service inventory and the engagement record rather than in tribal knowledge.
3. Roles, responsibilities, and the approval ladder
Name the roles so the policy is enforceable rather than aspirational. Without a named Accountable role per lifecycle phase, secure development decisions stall at the question of who should call it. Without a named Approver per release-gate exception band, waivers accumulate without a defensible decision trail.
Policy owner: {{POLICY_OWNER_ROLE}} (typically the AppSec Lead or Head of Product Security)
- Maintains the policy text, schedules the annual review, drives material revisions.
- Sole authority to publish a new version after approval.
Operational owner (programme function that operates the policy day to day): {{OPERATIONAL_OWNER_ROLE}}
- Operates the secure SDLC programme.
- Owns the SAST/SCA/DAST/IAST/secrets-scan/IaC-scan configurations across connected repositories and pre-production environments.
- Owns the release gate runbook and the per-service release gate configuration.
- Owns the threat modelling cadence schedule and the threat model action item backlog.
- Reports programme performance into the wider vulnerability management programme review cycle and the application security programme leadership read.
Per-lifecycle-phase responsibility:
- Requirements: engineering team lead is Accountable; AppSec engineering is Consulted; GRC is Informed for regulated-data services.
- Design: engineering lead and the technical architect are Accountable for the design; AppSec engineering and security architecture are Consulted; threat model is Responsible at the engineering side with AppSec reviewer sign-off.
- Build: engineering team is Responsible; platform engineering is Consulted for build platform changes; security engineering is Consulted for build provenance and signing.
- Code review: code author and code reviewer are Responsible; AppSec engineering is Consulted for security-sensitive changes flagged in the review checklist.
- Test: engineering team is Responsible for fixing detections in the team backlog; AppSec engineering is Responsible for the scan configuration and the false-positive intake; security engineering is Consulted for novel detection patterns.
- Release: named release approver (typically the engineering manager for the service) is Accountable for the release decision; AppSec engineering is Consulted on release-gate waivers; CISO is Accountable for material risk acceptance per the exception ladder.
- Maintain: engineering team is Responsible for vulnerability remediation per the SLA policy; AppSec engineering is Consulted on novel defect classes; vulnerability management programme is Accountable for the wider backlog discipline.
Approval ladder for release-gate waivers and exception decisions:
- Documentation-grade or false-positive suppression on a SAST or SCA finding: AppSec engineer with rationale recorded on the finding.
- Release-gate waiver at residual rating low or medium: AppSec Lead with named compensating control and expiry.
- Release-gate waiver at residual rating high: CISO or delegated Head of Security with documented compensating controls and a default 90-day expiry.
- Release-gate waiver at residual rating critical: CISO and Executive Sponsor with documented compensating controls, hard expiry not exceeding 90 days without renewed approval, and audit committee notification.
- Policy revision: policy owner, operational owner, CISO sign-off, audit committee notification on material revisions.
RACI summary (referenced from the operating model documentation):
- Responsible per phase: see the lifecycle responsibility list above.
- Accountable end to end: CISO or delegated head of security.
- Consulted: GRC for framework crosswalk, internal audit for evidence design, legal for regulated-data service review.
- Informed: business unit heads for service-portfolio releases, engineering leadership, audit committee at quarterly cadence.
Named developer enablement:
- Every engineer in scope completes secure development training at hire and on the published refresher cadence ({{ENGINEER_TRAINING_REFRESH_CADENCE}}).
- Every release approver completes release-gate decision training and exception decision training before being named as an approver.
- Every threat model facilitator completes threat modelling training on the firm method before facilitating a session.
4. Security requirements at intake and design
Requirements are the cheapest place to introduce or remove security obligations. The policy names the intake activities and the design-phase activities so the security activities run on the engineering cadence rather than appearing as last-mile blockers at release. Threat modelling is the load-bearing design-phase artefact; the policy commits to it explicitly rather than treating it as optional.
Requirements-phase rules:
- Every new feature ticket or design document records the data classes the feature handles (per the data classification policy), the regulated controls in scope (per the compliance tracking inventory), the user-facing trust boundaries the feature crosses, and the abuse cases the team has identified.
- Security requirements (authentication, authorisation, audit logging, input validation, output encoding, cryptography, secrets handling, error handling, logging, monitoring, rate limiting) are pulled from the secure coding standard and recorded on the ticket where they apply.
- Privacy review is triggered automatically where personal data classes are recorded; the data protection impact assessment artefact governs that branch separately.
Design-phase rules:
- Every new application and every new feature with material security impact gets a documented threat model.
- The threat model is produced at the design phase rather than at the release phase so identified mitigations land inside the implementation rather than the release-gate exception register.
- The threat model uses the firm default method: {{DEFAULT_THREAT_MODELLING_METHOD_STRIDE_PASTA_LINDDUN}}.
- The threat model artefact captures: assets in scope, trust boundaries, attacker profiles considered, attack paths against each asset, mitigations in place or planned, residual risks accepted with named approver and expiry.
- Threat model action items become findings on the engagement record with named owner, due date, and SLA aligned to the vulnerability remediation SLA policy.
- Material architecture changes that cross a trust boundary trigger a fresh threat model update rather than relying on the prior model.
Secure architecture review:
- Tier 1 services and material architecture changes go through a secure architecture review.
- The review covers authentication and authorisation design, secrets handling design, data-in-transit and data-at-rest cryptography design, audit logging design, network exposure design, identity and access boundaries, third-party data flow.
- The review artefact lives on the engagement record alongside the threat model.
Design-phase exit criteria:
- Threat model is captured and reviewed.
- Identified mitigations have engineering owners and a target landing release.
- Security requirements derived from the threat model are captured on the engineering tickets that will implement them.
- Material residual risks are recorded on the security exception register with named owner and expiry.
5. Secure build and dependency management
Build is the phase where most supply chain attacks land and where the SBOM and the provenance attestation are produced. The policy commits to the locked dependency discipline, the SBOM generation discipline, and the build provenance discipline so the artefact the firm ships is reproducible and audit-traceable rather than an opaque binary.
Build platform rule:
- In-scope code is built on the firm-controlled build platform: {{BUILD_PLATFORM}}.
- Build runs are pinned to a named build configuration with the build steps captured in the build configuration file in the source repository.
- Build platform credentials follow the secrets management policy and the OIDC federation pattern where the platform supports it.
Dependency management rule:
- Every in-scope project records its dependencies in a manifest file checked into the source repository.
- Dependencies are version-locked through the package manager lock file or equivalent.
- Direct dependencies are selected from approved sources: official package registries, vetted private registries, and the firm-curated mirror where the firm operates one.
- Dependency selection considers the upstream project health (release cadence, maintainer count, signed releases, known compromise history, license compatibility) per the firm dependency selection guidance.
- Dependency upgrade cadence is published per service tier and per dependency criticality.
- Vulnerable dependencies surfaced by SCA become findings on the engagement record per the SCA rule in Section 6 and the vulnerability remediation SLA policy.
SBOM generation rule:
- Every production release of every in-scope product produces an SBOM as part of the release pipeline.
- The SBOM is published alongside the release artefact per the SBOM policy.
- The SBOM covers the depth tier committed in the SBOM policy: top-level only, full transitive closure, or transitive plus runtime layers.
Build provenance and signing:
- The build platform emits a provenance attestation per release using the firm-selected attestation format (SLSA Provenance v1 or in-toto link statement).
- Release artefacts are signed using the firm-selected signing model (Sigstore Cosign, in-house signing CA, hardware-backed signing key per the cryptographic key management policy).
- The signature, the provenance attestation, the SBOM, and the release notes are published together so downstream consumers can verify the artefact integrity.
Reproducibility commitment:
- Tier 1 services target reproducible builds where the language and build platform support reproducibility.
- The build configuration documents the steps a third party would follow to reproduce the build from the source tag.
Build artefact hygiene:
- Build artefacts do not contain secrets (per the secrets management policy).
- Build artefacts do not contain debug symbols, temporary files, build logs, or test fixtures that should not ship.
- Container images are built from the minimal base image consistent with the runtime requirement and follow the firm base-image policy.
- Infrastructure-as-code modules ship without baked-in secrets and without target-environment hardcoded references that should be parameters.
Build evidence:
- The build platform records the build identifier, the build configuration version, the source commit, the build start and end timestamps, the named build runner, the build logs reference, the SBOM reference, the provenance attestation reference, and the signing record on the build engagement record.
6. Secure coding and code review
Code review is where most defects can be caught at lowest cost. The policy commits to the human reviewer rule and the automated review rule so the discipline is enforceable rather than implied. The secure coding standard the policy references is a separate, language-specific document; this section commits to the review discipline rather than re-publishing the coding patterns.
Secure coding standard reference:
- The firm secure coding standard lives at {{SECURE_CODING_STANDARD_LOCATION}} and is referenced from this policy.
- The standard covers language-specific patterns to use and to avoid, input validation rules, output encoding rules, the CWE Top 25 classes the team defends against, the OWASP Top 10 classes for web applications, the OWASP API Security Top 10 for APIs, the OWASP MASVS for mobile applications, the approved cryptographic primitives, the prohibited cryptographic primitives, the error handling and logging rules, and the secrets handling rules from the secrets management policy.
Code review rule:
- Every change to in-scope code goes through a human reviewer.
- Reviewer cannot be the code author.
- Reviewer is named on the pull request, the merge request, or the change request.
- Reviewer is responsible for the security properties of the merged change.
- For Tier 1 services, security-sensitive changes (authentication, authorisation, cryptography, secrets handling, deserialisation, sandbox boundaries, input validation, output encoding, file handling, network handling) require an AppSec engineer reviewer or an engineer with security-trained sign-off authority recorded on the engineer record.
Automated review rule:
- SAST runs on every commit to in-scope code through CI using the firm-configured ruleset.
- SCA runs on every commit to in-scope code and on a scheduled cadence to catch published vulnerabilities against pinned dependencies.
- Secrets scanning runs on every commit to in-scope code using the firm-configured ruleset.
- IaC scanning runs on every commit to in-scope infrastructure code.
- The automated review surfaces detections to the team backlog through the findings management workflow rather than blocking merges automatically; the policy mandates triage rather than CI red-light enforcement so false positives do not become a deployment-prevention pattern.
AI-generated code rule:
- AI-suggested code is treated as code the human engineer has authored.
- The reviewer is responsible for the security properties of the merged change regardless of who or what wrote the draft.
- AI-suggested code passes the same review discipline, the same automated security testing, the same threat model review for material changes, and the same release gates as engineer-written code.
- Engineers do not paste production secrets, customer data, source code from proprietary or restricted-access repositories, or unredacted personally identifiable information into AI assistants whose data handling has not been reviewed and approved per the AI system acceptable use policy.
- Material AI-suggested architecture or security control decisions are reviewed by a human security engineer rather than accepted on autopilot.
- See the companion AI system acceptable use policy for the prompt-content rules and the leakage-incident reporting chain.
Code review evidence:
- Every merged change carries the reviewer identifier, the reviewer approval timestamp, the automated scan summary (findings count by severity), and any security comments recorded during review.
- The activity log carries the named-actor record of each review event on the workspace engagement record.
7. Automated security testing baseline
The automated testing baseline is the rule that turns secure SDLC discipline into observable scanning rather than asserted practice. Name the test types, the cadence per test type, the false-positive intake, and the SLA tiers per severity so the activity is auditable rather than implied. The policy does not name a specific scanner brand because that is an operational decision; this section names the rule and the scope.
Automated test types and minimum coverage:
- SAST (static application security testing): every commit to in-scope code through CI for every in-scope service, plus scheduled full-repository sweep on the published cadence for in-scope repositories.
- SCA (software composition analysis): every commit that changes a dependency manifest, plus daily scheduled scan against pinned dependencies to catch newly published vulnerabilities.
- DAST (dynamic application security testing): scheduled cadence per service tier against pre-production or staging environments for in-scope web and API services. Tier 1 weekly, Tier 2 biweekly, Tier 3 monthly minimum.
- IAST (interactive application security testing): supported where the firm has decided IAST instrumentation is operationally tractable and the false-positive rate is within the firm tolerance.
- Secrets scanning: every commit to in-scope code through CI, plus scheduled full-repository sweep on the published cadence to catch credentials in repositories.
- Container image scanning: on every container image build for in-scope services, plus scheduled rescan of published images on the published cadence to catch newly published base-image vulnerabilities.
- Infrastructure-as-code scanning: every commit to in-scope IaC repositories, plus scheduled full-repository sweep on the published cadence.
Scanner inventory:
- Approved SAST scanners: {{APPROVED_SAST_SCANNERS}}.
- Approved SCA scanners: {{APPROVED_SCA_SCANNERS}}.
- Approved DAST scanners: {{APPROVED_DAST_SCANNERS}}.
- Approved IAST scanners: {{APPROVED_IAST_SCANNERS}}.
- Approved secrets scanners: {{APPROVED_SECRETS_SCANNERS}}.
- Approved container image scanners: {{APPROVED_CONTAINER_SCANNERS}}.
- Approved IaC scanners: {{APPROVED_IAC_SCANNERS}}.
- Onboarding a new scanner requires written approval from the AppSec Lead, a documented rule set review, and a documented false-positive baseline.
Per-finding handling rule:
- Every detection from an approved scanner lands on the engagement record as a finding with severity, owner, due date, and the scanner evidence pointer (scan run identifier, ruleset version, file path or URL, line number or endpoint, scanner confidence indicator).
- Severity tiering follows the vulnerability prioritisation matrix template, with CVSS 3.1 or 4.0 scoring where applicable and reachability adjustment for SCA findings per the reachability analysis discipline.
- SLA windows per severity follow the vulnerability remediation SLA policy.
Suppression rule:
- Documentation-grade and known-false-positive detections may be suppressed.
- Every suppression carries rationale, named suppressor, scope (which file or path or detection class), and an expiry date.
- Open-ended suppressions are prohibited; renewal requires fresh evidence and fresh approval.
- The suppression rule list is reviewed quarterly to confirm rationales still hold.
False-positive intake:
- The engineering team flags false positives through the findings management workflow with rationale.
- The AppSec engineering team reviews the flag, classifies as true-positive, false-positive, or documentation-grade, and updates the suppression rule or the scanner configuration accordingly.
Scan coverage reporting:
- The operational owner reports scan coverage by service tier (percent of in-scope services with active scanning per test type) to the quarterly governance review.
- Services that fall out of scan coverage become findings on the operational engagement record until coverage is restored.
8. Manual security testing and penetration testing inside the lifecycle
Automated testing does not catch business-logic flaws, authorisation chain weaknesses, or novel design defects. Manual testing inside the lifecycle is where those defects surface. Name the cadence per service tier, the test scope, the named tester role, and the artefact retention so manual testing is part of the release discipline rather than a one-off compliance activity.
Manual testing cadence per service tier:
- Tier 1 services: full-scope manual security test annually plus targeted test at every material architecture change and at every release of regulated functionality.
- Tier 2 services: full-scope manual security test every 18 to 24 months plus targeted test at material architecture changes.
- Tier 3 services: full-scope manual security test on a programme-driven cadence or following a material change.
Manual test scope:
- Authentication and session management
- Authorisation chain including IDOR, BOLA, BFLA, and broken function-level authorisation
- Business logic flaws and state machine weaknesses
- Input validation chain across user input, API input, file input, and third-party callbacks
- Output encoding chain across HTML, JSON, XML, CSV, PDF, and downstream consumers
- Cryptography in use including key handling and protocol selection
- Audit logging and monitoring coverage
- Rate limiting and abuse-resistance
- Multi-tenant isolation where applicable
- Trust boundary integrity per the threat model
Test execution model:
- Internal manual testing is performed by named AppSec engineers or named in-house security testers.
- External manual testing is performed by named third-party providers per the procurement rule.
- Every test has a documented scope, a documented rules of engagement artefact, and a documented authorisation record.
- Authenticated testing follows the credential handover rule from the engagement record.
Penetration testing inside the lifecycle:
- Tier 1 services receive a penetration test before initial production release and on the published periodic cadence post-release.
- Tier 1 features with material security impact receive a pre-release penetration test focused on the new attack surface.
- Penetration test findings land on the engagement record alongside automated scan findings with the same severity, SLA, and ownership discipline.
- Penetration test retests pair to the original finding through the retesting workflow so closure is on evidence rather than on plan.
Artefact retention:
- Manual test plans, manual test execution logs, manual test reports, and penetration test reports are retained per the audit evidence retention policy.
- Manual test findings are retained on the engagement record per the findings retention rule.
9. Release security gates and waiver process
Release gates are the policy lever that prevents security debt from accumulating silently across releases. Publish the explicit pass criteria, the named approver per service, the waiver process per residual rating, and the rollback discipline so the gate is defensible at audit rather than implied.
Release security gate pass criteria (a release proceeds only when all criteria are met or a documented waiver is in force):
- No open critical-severity vulnerabilities against in-scope code at the release tag.
- No open high-severity vulnerabilities older than the published SLA window without a documented exception.
- No leaked secrets in the release commit per the secrets management policy.
- No vulnerable dependencies above the published severity threshold without a documented waiver.
- Threat model action items for the release are closed or carried with explicit acceptance per the exception register.
- Required automated security tests for the release have run and passed per the test configuration.
- Required manual testing for the release tier has completed and findings are closed or covered by exception per Section 8.
- The SBOM is generated and the artefact provenance is recorded per the SBOM policy.
- The release notes capture the security defects fixed in the release and any deferred security defects with rationale.
- The named release approver has signed off.
Per-service-tier release approver:
- Tier 1: the engineering manager for the service and the AppSec engineer on rota sign off jointly.
- Tier 2: the engineering manager for the service signs off; AppSec engineering is notified.
- Tier 3: the engineering team lead signs off; AppSec engineering is informed on the published cadence.
Waiver process:
- A waiver is requested through the findings management workflow with rationale, named compensating controls, named expiry, and named approver per the exception ladder in Section 3.
- The waiver carries the release-gate context: which release, which finding, which compensating control, which monitoring step verifies the compensating control remains effective.
- The waiver is logged in the activity log with the named approver and the timestamp.
- The waiver expires on the recorded date; renewal requires fresh evidence and fresh approval.
False-positive handling at the gate:
- The release gate does not block on false positives.
- Documentation-grade detections that have been classified through the suppression rule from Section 7 are excluded from the gate evaluation.
- A new detection that arrives at the gate is triaged before the gate decision is taken rather than being suppressed at the gate.
Rollback discipline:
- If a release ships with a deferred security defect that materialises post-release, the post-release vulnerability handling chain in Section 10 governs the response.
- If the released artefact introduces a critical security defect undetected by the gate, the release is rolled back per the firm rollback runbook and the failure is logged on the engagement record for the post-incident review.
Release gate evidence:
- Every release records the gate evaluation summary, the findings considered, the waivers in force, the named approver, the SBOM and provenance references, and the timestamp.
- The release gate decision is observable in the activity log rather than reconstructible from a side document.
10. Post-release vulnerability handling and patch management
Post-release is where the lifecycle becomes a loop rather than a line. Name the vulnerability intake channels, the triage discipline, the patch cadence, and the customer notification expectations so post-release security defect handling is part of the policy rather than a separate firefighting domain.
Vulnerability intake channels:
- Internal scanning surfaces post-release findings on the continuous monitoring cadence (per Section 7).
- Manual security testing surfaces post-release findings per the cadence in Section 8.
- The vulnerability disclosure programme surfaces inbound reports from external researchers per the vulnerability disclosure policy.
- Customer-reported defects surface through the customer support intake with security defects routed to the AppSec engineering rota.
- Third-party threat intelligence and CVE feeds surface newly published vulnerabilities affecting in-scope dependencies through the emerging vulnerability and CVE watch programme.
- Security operations and incident response surface defects discovered during incident investigation per the incident response policy.
Triage discipline:
- Every inbound vulnerability is triaged within the published intake SLA per severity.
- Triage assigns severity (CVSS 3.1 or 4.0 where applicable), reachability and exploitability assessment, named owner, target remediation window per the vulnerability remediation SLA policy, and customer notification disposition.
- Reachability analysis adjusts the priority for SCA findings against pinned dependencies so the team works the reachable subset first.
Patch management cadence:
- Critical-severity post-release defects are patched on the published critical SLA.
- High-severity defects are patched on the published high SLA.
- Medium and low defects are batched into the regular release cadence per the firm patch management policy.
- Zero-day and emergency response defects are handled on the emergency release path documented in the zero-day and emergency vulnerability response workflow.
Customer notification:
- Material security defects in customer-facing products trigger customer notification per the firm vulnerability disclosure and customer notification rules.
- The notification carries the defect description appropriate to the audience, the affected versions, the fix version or workaround, the upgrade guidance, and the named contact for follow-up.
- Customer-facing security advisories are published on the firm advisory channel per the firm advisory format.
Patch verification:
- Every patched finding receives a verification scan or manual retest before closure per the security finding fix verification discipline.
- The retest pairs to the original finding through the retesting workflow.
- Closure on evidence rather than closure on plan is the policy rule.
Sunset and decommissioning:
- Services that are sunset record the decommissioning decision, the final security state, the data retention disposition, and the asset removal from scanning and monitoring scope.
- Findings against decommissioned services are closed with the rationale "service decommissioned" and the engagement record is archived per the audit evidence retention policy.
11. Audit evidence and framework crosswalk
Evidence is the artefact a reviewer reads when auditing the policy against the live record. Name the evidence classes, the retention rule, the source-of-truth location, and the framework crosswalk so the audit can re-derive the policy against the operational record rather than reconstructing it from email threads.
Evidence classes the SSDLC programme retains:
- Threat model artefacts per service and per material design change.
- Code review records (reviewer identifier, approval timestamp, automated scan summary at merge time).
- Automated scan logs per scanner per repository per run with scan-run identifier and ruleset version.
- Manual security test plans, execution logs, and reports.
- Penetration test reports and retest evidence packs.
- Release gate decision records (criteria evaluated, findings considered, waivers in force, named approver, timestamp, SBOM and provenance references).
- Waiver and exception records (scope, rationale, compensating controls, named approver, expiry).
- Post-release vulnerability records with patch evidence and customer notification record where applicable.
- Engineer training completion records per engineer per training module.
- Scanner inventory change records.
- Policy revision history.
Retention rule:
- Evidence is retained per the audit evidence retention policy with the retention class set at evidence creation rather than at archival time.
- The retention class scales with the regulated context of the service the evidence supports.
- Default retention for SDLC artefacts is the longer of seven years or the operating life of the supported service plus three years.
Source of truth:
- Threat models, code review records, scan logs, manual test artefacts, penetration test artefacts, release gate decisions, waivers, exceptions, post-release vulnerability records, and policy revision history live on the workspace engagement record.
- The engagement record is the single source of truth the audit reads against rather than across a chat history, a wiki, a deck, and a closed-out ticket.
Framework crosswalk (map each in-scope framework into the per-control evidence locations):
- NIST SSDF Practices to engagement record evidence: {{NIST_SSDF_CROSSWALK_NOTES}}.
- CISA Secure Software Development Attestation to engagement record evidence: {{CISA_ATTESTATION_CROSSWALK_NOTES}}.
- ISO 27001 Annex A 8.25 to A 8.34 to engagement record evidence: {{ISO_27001_CROSSWALK_NOTES}}.
- SOC 2 CC8.1 to engagement record evidence: {{SOC_2_CROSSWALK_NOTES}}.
- PCI DSS 6.2 to 6.5 to engagement record evidence: {{PCI_DSS_CROSSWALK_NOTES}}.
- NIST 800-53 SA-3, SA-8, SA-11, SA-15, SA-17, SI-2 to engagement record evidence: {{NIST_800_53_CROSSWALK_NOTES}}.
- NIS2 Article 21 and DORA Article 8 to engagement record evidence: {{NIS2_DORA_CROSSWALK_NOTES}}.
- GDPR Article 25 to engagement record evidence: {{GDPR_CROSSWALK_NOTES}}.
- EU Cyber Resilience Act to engagement record evidence: {{EU_CRA_CROSSWALK_NOTES}}.
- OWASP SAMM and DSOMM observation references: {{OWASP_OBSERVATION_NOTES}}.
Audit re-derivability test:
- A reviewer reading the workspace record can re-derive: which services are in scope, which release-gate decisions were taken in the period, which waivers are in force, which threat models exist, which scans ran with which findings, which manual tests completed, which penetration tests ran, which post-release defects were handled, and which policy version was in force at each decision point.
- The activity log carries the timestamped chain across all of the above.
12. Programme metrics and governance review
Metrics tell the programme whether the policy is delivering durable secure development discipline or accumulating residual risk. Governance review reads the metrics against the policy intent. Name the metric set, the cadence, and the read-out audiences so the policy is a managed programme rather than a publishing event.
Headline programme metrics (read at the quarterly governance review):
- Closure rate on in-scope findings by severity over the rolling twelve months.
- Mean time to remediation by severity and by service tier.
- SLA breach count by severity and breach reason distribution (capacity, dependency, exception-pending, owner unavailability).
- Active exception count by residual rating with named overdue-for-review count.
- Release-gate waiver count per period by service tier and waiver rationale class.
- Scan coverage by service tier across SAST, SCA, DAST, IAST, secrets scanning, container scanning, IaC scanning.
- Threat model coverage by service tier (percent of in-scope services with current threat model).
- Manual testing coverage by service tier (percent of in-scope services with manual test in the published window).
- Penetration testing coverage by Tier 1 services with current penetration test.
- Reopen rate on closed findings (proxy for verification discipline).
- Mean time from disclosure to patch on customer-facing post-release defects.
- Engineer training completion rate per training module per engineer cohort.
Operational metrics (read at the monthly operating review):
- Detection volume per scanner per period.
- False-positive rate per scanner per period.
- Suppression rule count and age distribution.
- New service onboarding completion rate.
- Release-gate evaluation count and pass-versus-waiver distribution.
Read-out cadence and audiences:
- Monthly operating review: AppSec engineering, security engineering, vulnerability management programme leadership.
- Quarterly governance review: AppSec leadership, CISO, internal audit liaison, GRC liaison, engineering leadership representatives, named business unit representatives.
- Annual board briefing: CISO and AppSec leadership read into the board cyber risk briefing per the board cyber risk briefing template.
Governance review questions (asked at every quarterly review):
- Is the residual risk in the secure SDLC programme acceptable against the firm risk appetite, or is the trend line moving against the firm?
- Are the release-gate waivers a concentrated risk class that requires structural remediation rather than continued waiver?
- Is the suppression rule list still calibrated to the current code base and the current scanner ruleset?
- Are the manual testing and penetration testing cadences holding against the published windows, or is testing in arrears?
- Is the engineer training programme keeping pace with engineer turnover and new technology adoption?
- Has any regulation, scanner, framework, or threat-environment change in the period triggered a policy revision that is overdue?
- Is the programme metric trend line consistent with the wider vulnerability management programme trend line, or is there a structural divergence?
13. Policy review, revision, and sign-off
Close the policy with the review cadence, the revision triggers, the sign-off block, and the revision history. The audit reads the close of the policy to verify the policy is a managed artefact rather than a published-and-forgotten document.
Review cadence:
- Annual minimum policy review with material-change-triggered revision.
Material change triggers (an off-cycle revision is required):
- A new regulation in scope (DORA, NIS2, EU AI Act, EU Cyber Resilience Act, a US state privacy law, sector-specific overlays).
- A new SAST, SCA, DAST, IAST, secrets scanner, container scanner, or IaC scanner adoption or migration.
- A major engineering reorganisation that changes role definitions.
- A release-gate failure or post-release defect that surfaces a question the policy should have answered.
- An acquisition that brings inherited lifecycle practices into scope.
- A customer audit that requires the firm to demonstrate stricter discipline.
- A material AI-tool adoption that changes the developer experience.
Acknowledgement cadence:
- The policy is acknowledged annually by every engineer in scope through the engineer acknowledgement workflow.
- The policy is acknowledged at hire by every new engineer in scope.
- The acknowledgement record is retained per the audit evidence retention policy.
Sign-off block:
- Policy owner: {{POLICY_OWNER_NAME_AND_ROLE}}
- Operational owner: {{OPERATIONAL_OWNER_NAME_AND_ROLE}}
- Approving authority (CISO or delegated head of security): {{APPROVER_NAME_AND_ROLE}}
- Reviewer (Head of Engineering or VP Engineering): {{REVIEWER_NAME_AND_ROLE}}
- Internal audit acknowledgement: {{INTERNAL_AUDIT_REFERENCE}}
- Audit committee notification reference: {{AUDIT_COMMITTEE_REFERENCE}}
- Effective date once all signatures are collected: {{EFFECTIVE_DATE_FINAL}}
Revision history table (maintained on the policy):
| Version | Date | Summary | Approver | Rationale |
| {{V1_VERSION}} | {{V1_DATE}} | {{V1_SUMMARY}} | {{V1_APPROVER}} | {{V1_RATIONALE}} |
Ten failure modes the policy has to design against
The secure SDLC policy fails the audit read in recognisable patterns. Each failure has a structural fix the template above is designed to enforce. Read this list before you customise the template so the customisation does not weaken the discipline that makes the policy defensible.
Security activities sit at the release gate instead of inside the lifecycle
The team treats security as a release blocker rather than an activity baseline. Threat models are written at the last minute to clear the gate, automated scanning surfaces defects too late to remediate cleanly, and waivers accumulate as the de facto release pattern. The fix is the per-phase activity baseline in Sections 4 to 8 enforced through the named accountable roles in Section 3 so security work lands inside the engineering ticket budget rather than at the gate.
Threat modelling is treated as a deliverable rather than a practice
The team produces a threat model artefact at the design phase, files it in a wiki, and never reads it again. Identified mitigations do not become engineering tickets. Residual risks are not tracked. The next architecture change is not paired to a fresh threat model. The fix is the threat model action item discipline in Section 4 where every identified mitigation becomes a finding on the engagement record with named owner and SLA, and material architecture changes trigger a fresh threat model rather than relying on the prior artefact.
Release gates block on false positives and erode developer trust
The release gate fires on every SAST or SCA detection regardless of triage state. Engineers learn to route around the gate through emergency waivers or by bypassing the configuration. The gate becomes ceremonial rather than load-bearing. The fix is the suppression rule and false-positive intake in Section 7 paired with the gate evaluation in Section 9 that excludes suppressed detections rather than blocking on noise.
Waivers expire by silent rollover rather than fresh approval
Release-gate waivers get filed and approved at one release, then quietly carry forward into subsequent releases without fresh approval. The exception register grows; the named approver list is stale; the compensating controls are no longer in force. The fix is the hard expiry per residual rating in Section 3, the fresh-evidence renewal requirement, and the quarterly governance review reading on overdue exceptions.
AI-generated code passes review on autopilot
AI suggestions are accepted without the reviewer applying the same scrutiny as engineer-written code. Insecure default cryptography choices, hallucinated APIs that do not enforce security properties, and hardcoded credentials in scaffolded code land in production. The fix is the AI-generated code rule in Section 6 paired with the AI system acceptable use policy that names the prompt-content rules and the human-reviewer responsibility regardless of code origin.
Closures happen on plan rather than on evidence
The triager moves the finding to closed because the developer reported they fixed it. No verification scan or retest ran. The next scheduled scan re-detects the same defect because the fix landed on the wrong branch or was reverted. The reopen rate climbs and the audit reads closure-on-plan as a control weakness. The fix is the verification requirement in Section 10 enforced through the retesting workflow so closure is on evidence rather than on developer self-report.
Service inventory drifts and scanning coverage drops silently
New services are launched without being added to the in-scope service inventory; existing services are sunset without being removed. The scanner runs against the old inventory; new services accumulate undetected security debt; sunset services consume scanner capacity. The fix is the scan coverage reporting in Section 7 read into the quarterly governance review so coverage drift is visible and corrected.
Suppression rules cover real findings because the rationale was never recorded
An engineer files a suppression rule to silence a high-volume false positive without recording why. A subsequent real defect in the same code path inherits the suppression and never reaches the triage queue. The fix is the rationale-mandatory rule in Section 7 plus the quarterly suppression rule review that re-validates rationale against the current code base.
Manual testing falls behind because the cadence is not policy-enforced
Penetration testing and manual security testing slip on the calendar because there is no policy lever that names the cadence per service tier. The audit reads stale test reports against current services; new functionality ships without manual review; the team relies on automated scanning for assurance that automated scanning cannot provide. The fix is the cadence in Section 8 enforced through the engagement record so manual testing is a tracked activity rather than a discretionary one.
Engineer training is treated as an onboarding event rather than an ongoing programme
Engineers complete secure development training at hire and never refresh. New defect classes emerge; new technology adoption changes the threat surface; the training content drifts away from the current secure coding standard. The fix is the engineer training cadence in Section 3 paired with the engineer acknowledgement workflow in Section 13 so training currency is a tracked policy obligation.
Ten questions the quarterly governance review has to answer
Operational review keeps the programme on top of scan detections, release-gate decisions, and waiver flow. Governance review answers whether the policy is delivering durable secure development discipline or accumulating residual risk the audit will read as policy drift. Run these ten questions at every quarterly review and capture the answers in the governance record.
1.What is the closure rate on in-scope findings per severity over the rolling twelve months, and is the trend line up, flat, or down per service tier?
2.How many release-gate waivers were granted in the period, what was the residual-rating distribution, and what is the underlying defect class that drives the waiver mix?
3.How many active exceptions are in the register against the SDLC programme, broken down by residual rating, and how many are approaching expiry within 60 days?
4.What is the scan coverage by service tier across SAST, SCA, DAST, IAST, secrets scanning, container scanning, and IaC scanning, and where is coverage drifting?
5.How many in-scope services have a current threat model against the policy cadence, and which services are out of compliance?
6.How many manual security tests and penetration tests have run against the policy cadence per service tier, and which services are in arrears?
7.What is the SLA breach count per severity in the period, what is the breach reason distribution, and what is the structural remediation landing?
8.How many post-release security defects were patched in the period, what was the mean time from disclosure to patch on customer-facing defects, and is the customer notification discipline holding?
9.What is the engineer training completion rate per training module per engineer cohort, and is the refresh cadence keeping pace with engineer turnover and new technology adoption?
10.Has any framework, regulation, scanner, AI tool, or threat-environment change in the period triggered policy review, and is the policy revision on schedule against the material-change trigger list in Section 13?
How the policy pairs with SecPortal
The template above is copy-ready as a standalone artefact. If your team already runs findings, remediation, and compliance evidence on a workspace, the SDLC lifecycle becomes the byproduct of the engineering work rather than a separate set of spreadsheets and decks. SecPortal pairs every release-gate decision and every scan detection to an engagement record through findings management, so the threat model action items, the SAST detections, the SCA findings, the DAST findings, the secrets-scan results, the IaC-scan results, the release-gate evaluation, the waiver decisions, and the post-release defect handling all live on one record rather than across tickets, chat threads, and a closed-out runbook. The code scanning feature runs Semgrep SAST and dependency analysis against connected repositories (GitHub, GitLab, Bitbucket) so the SAST and SCA baseline named in Section 7 is observable rather than asserted. The external scanning and authenticated scanning features cover the DAST surface for pre-production and production web and API services on verified domains. The repository connections feature carries the encrypted git provider tokens that authorise the code scan; the tokens themselves follow the secrets handling pattern the secrets management policy publishes.
The finding overrides primitive holds the release-gate waiver decisions with rationale, named compensating control, named approver, scope, and expiry on accepted-risk decisions, so the waiver audit in Section 9 is queryable rather than reconstructible. The activity log captures the timestamped chain of state changes by user, so the elapsed time between detection, triage, fix, retest, and closure is observable rather than asserted. The continuous monitoring feature schedules the recurring code scan and the recurring external scan so security debt introduced after the previous release is detected on the published cadence rather than the next manual run. The retesting workflows feature pairs verification scans and manual retests to the original finding so closure is on evidence rather than on developer self-report.
The document management feature retains the policy file, the threat model artefacts, the manual test plans, the penetration test reports, and the revision history alongside the operational record so the policy version in force at any release decision is reconstructible from one record. The team management feature carries role-based access control that gates the severity override path, the waiver approval ladder, the release approver authority, and the policy publishing authority referenced from Section 3. The multi-factor authentication enforcement at the workspace boundary protects access to the operational record that carries the SDLC programme trail. The compliance tracking feature maps SDLC findings and surrounding controls to ISO 27001, SOC 2, PCI DSS, NIST SSDF, NIST 800-53, NIS2, and DORA frameworks with CSV export, so the framework crosswalk in Section 11 reads against the live record rather than a separate evidence spreadsheet. The AI report generation workflow produces leadership summaries from the same engagement data so the audit committee read and the operational read are the same record. The bulk finding import intake brings in scanner outputs from external SAST, SCA, DAST, IAST, container, and IaC scanners through Nessus, Burp, and CSV formats so the unified finding view in Section 7 works against the actual scanner inventory rather than the scanners SecPortal ships.
Explicit honest scope: SecPortal does not replace the SAST tool itself (Semgrep is the SAST surface SecPortal runs; other SAST tools such as Snyk Code, Veracode, Checkmarx, Fortify SCA, Coverity remain the firm choice for surfaces SecPortal does not cover), does not replace the IDE-side developer experience, does not enforce release gates inside the CI/CD platform at runtime (the policy is enforced through the firm-owned CI/CD configuration; SecPortal carries the gate decision record after the gate fires), does not replace the build platform or the registry, does not integrate with Jira, ServiceNow, Slack, SIEM, or SOAR, and does not carry the supply chain attestation signing infrastructure (Sigstore, SLSA attestations, in-toto layouts) which remain the responsibility of the firm-operated build platform.