Requirement
What risk, policy, contract, standard, or engineering objective creates the need?
Secure software delivery
Make the pipeline produce evidence while it produces software.
Continuous compliance works when requirements become repeatable development and release controls—not when teams rebuild screenshots, approvals, dependency lists, and test history after the release is already in production.
Substantively reviewed . This revision preserves the corrected federal attestation baseline and strengthens release-evidence, exception, and reconstruction guidance.
Start with the right authority
NIST SP 800-218, the Secure Software Development Framework (SSDF), remains the durable federal secure-development reference for organizing practices across preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities. It is a framework for practices, not a demand that every organization use the same CI product or identical pipeline stages.
For federal software-producer attestation, the current CISA common form explains that the underlying OMB policy is M-22-18 as amended by M-23-16. The prior version of this guide cited M-24-04 as if it were secure-software attestation policy; that was incorrect. M-24-04 is FY2024 FISMA information-security and privacy management reporting guidance.
The operating lesson is simple: store the source and version beside the control mapping. Do not copy a memorandum number into a pipeline rule and let it live there indefinitely. When policy changes, the mapping should be reviewable without reverse-engineering why a job exists.
Build one traceable chain from requirement to release evidence
For each consequential release control, connect six things: the requirement or risk, the expected engineering behavior, the automated or manual check, the evidence artifact, the failure response, and the accountable owner. This creates a control that developers can understand and reviewers can inspect.
Gate
What test, review, approval, policy-as-code rule, or verification determines whether the release can proceed?
Evidence
What immutable or versioned artifact proves what happened, against which source revision and code revision?
Avoid gates that exist only because “security asked for them.” A developer should be able to understand what failure means and what a valid exception requires.
Place controls where they provide useful feedback
| Stage | Useful controls | Evidence to retain |
|---|---|---|
| Source / change | Protected branches, required review, signed or attributable changes, secrets prevention, ownership rules | Commit identity, review record, policy result, exception record |
| Dependencies | Locking, source restrictions, vulnerability/licence policy, integrity verification, update policy | Resolved dependency graph, scanner result, exception and expiry |
| Build | Controlled runner, ephemeral credentials, reproducible inputs where practical, isolated secrets, artifact integrity | Build identity, inputs, logs, artifact digest, provenance |
| Test | Unit/integration tests, security tests, IaC checks, API/schema tests, accessibility tests where relevant | Test version, environment, result, coverage or scope, known exclusions |
| Release | Required approvals, deployment policy, signed artifact verification, environment constraints, rollback readiness | Release decision, artifact identifier, approver, environment, deployment result |
| Post-release | Telemetry, vulnerability intake, incident path, configuration drift, rollback, customer/security notification triggers | Operational signals, findings, remediation, change history |
Treat attestation as a claim supported by engineering records
A signed software attestation should not be the first time leadership discovers how software is built. If an organization needs to support federal attestation or equivalent customer assurance, the pipeline should already make the relevant practices observable.
Maintain an evidence map showing which repositories, build systems, policies, reviews, test results, vulnerability processes, and exceptions support each attested practice. Record product scope and version boundaries. A corporate statement that “we use the SSDF” is weak if no one can show which products and release paths the statement covers.
Where a requirement is not met, do not manufacture green status. Record the gap, affected products, risk, compensating controls, remediation plan, owner, due date, and the authority that accepted the temporary condition. CISA's common-form instructions explicitly contemplate situations where a producer cannot attest to all required practices and an agency evaluates documented mitigations and a plan of actions and milestones.
Build a release evidence packet that can be reconstructed without tribal knowledge
A defensible release record should let an independent reviewer determine what source revision was approved, what artifact was produced, which controls ran, what failed, what was waived, who approved the release, and what actually reached the target environment. Screenshots are weak evidence because they are difficult to validate, search, correlate, or regenerate. Prefer machine-produced records tied to durable identifiers such as commit hashes, build IDs, artifact digests, deployment IDs, policy versions, test-result files, and exception records.
The packet should also preserve scope. A passing security scan of one repository does not prove that a separately built frontend, infrastructure module, migration job, container base image, or deployment script received the same treatment. Record the components and environments covered by the release decision, including any intentionally excluded path. That makes later assurance work faster and prevents a broad compliance statement from quietly exceeding the evidence behind it.
Keep provenance and dependency evidence close to the artifact rather than in a separate compliance folder. At minimum, the organization should be able to identify the source inputs used to build a release, the resolved dependency state, the build environment or runner identity, the resulting artifact, and the verification performed before deployment. The objective is not paperwork volume; it is preserving enough information to investigate an incident, reproduce a decision, compare releases, and demonstrate that an approved artifact is the artifact that was deployed.
Finally, test reconstruction as a control. Select a completed production release and ask someone who did not perform it to rebuild the decision history from retained evidence alone. Any step that depends on memory, private chat, a personal inbox, an unversioned spreadsheet, or a mutable dashboard should be treated as an evidence gap. Fixing those gaps improves security operations, auditability, incident response, and engineering resilience at the same time.
Design exceptions so they expire
Fast delivery sometimes requires a controlled exception. The dangerous pattern is a permanent bypass hidden in CI configuration. Every exception should identify the control, reason, scope, approver, compensating measure, risk owner, expiration, and closure condition.
Prefer an explicit exception object or ticket that the pipeline reads rather than a branch-specific comment or disabled job. Alert before expiration. Prevent an expired exception from silently becoming the new default. Track repeat exceptions because recurring bypasses often indicate the control design, tooling, ownership, or delivery model itself needs improvement.
Apply the same release standard to AI-assisted code
Code generated or modified with an AI assistant does not need a separate definition of “done.” It needs the same—or risk-proportionate stronger—review, testing, dependency, provenance, secrets, and release controls as human-authored code. The important difference is input and permission governance: what repository context the tool can access, what data can leave the environment, and whether the tool can take actions rather than only suggest text.
Use the AI-Assisted Development Governance Guide for tool permissions, data boundaries, agent controls, and AI-specific evaluation. Keep the final software-delivery evidence in the normal release record so there is one authoritative history.
Measure control usefulness, not pipeline ornamentation
- Escape rate: material defects or security findings discovered after the release gate should have caught them.
- False-block rate: releases blocked by rules that do not correlate with meaningful risk.
- Exception aging: open, expired, recurring, and high-risk exceptions.
- Evidence completeness: releases that can be traced to source, build, test, artifact, approval, and deployment records.
- Remediation latency: time from a material finding to verified correction or accepted risk.
- Developer feedback time: how quickly a failed control explains what failed and how to resolve it.
A 30-day pipeline evidence reset
- Week 1
Inventory release paths, protected repositories, build systems, deployment mechanisms, manual approvals, and existing compliance/security jobs. Identify controls with no current owner or source.
- Week 2
Map the highest-consequence requirements to concrete pipeline checks and evidence. Delete or rewrite rules whose purpose cannot be explained.
- Week 3
Standardize exception records, evidence retention, artifact identity, and release-decision records across the highest-value services.
- Week 4
Select a real release and reconstruct its full decision chain. Fix every place where the evidence relies on memory, screenshots, or an individual's inbox.
Current sources
- NIST SP 800-218 — Secure Software Development Framework
- CISA Secure Software Development Attestation Form and instructions
- CISA Secure by Design
- NIST SP 800-53 Revision 5, Update 1
Apply contract, agency, sector, and regulatory requirements according to actual scope. This guide provides implementation structure, not a universal compliance determination.
Put this guide to work
Turn Continuous Compliance CI/CD Guide: Evidence, Secure Development & Release Gates into a decision-ready next step.
Use the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.