Secure SDLC and DevSecOps: making the pipeline your evidence

The conflict looks unavoidable: auditors want documented approval and testing for every change, and your team deploys thirty times a week. It resolves once you stop treating compliance as paperwork alongside engineering, and start treating the engineering workflow as the record.

What frameworks actually require

Strip away the language and change management requirements come down to four things:

1. Changes are authorised by someone other than the author.
2. Changes are tested before production.
3. Changes are traceable - what changed, when, by whom, and why.
4. Changes can be reversed.

Nothing in that list requires a change advisory board or a ticket typed by hand. A pull request with a required reviewer satisfies authorisation. A passing pipeline satisfies testing. Git history satisfies traceability. A documented rollback satisfies reversibility.

Mapping the pipeline to controls

• Branch protection with required review - and self-merge disabled. This one setting is the most common SOC 2 exception in engineering-led companies.
• CI pipeline logs - test results as evidence that testing occurred.
• Commit-to-ticket linkage - business justification, without a separate process.
• Deployment records - what version went where, when.
• Infrastructure as code - configuration evidence with the same review trail as application code.
• Signed artefacts and restricted deploy credentials - only the pipeline deploys to production.

The test of whether this works: could you export the last 90 days of changes with reviewer, test outcome and deploy time, in a few minutes? If yes, change management is solved. If not, that is the gap - not the process.

Security gates worth having

• Secret scanning - pre-commit and in CI. Credentials in repositories remain a leading breach cause.
• Dependency scanning (SCA) with a policy on which severities block a build.
• Static analysis (SAST), tuned - an unusable signal-to-noise ratio guarantees it gets bypassed.
• Infrastructure-as-code scanning for misconfiguration before deployment.
• Container image scanning and a policy on base image currency.
• Dynamic testing (DAST) against a running environment for the paths static tools miss.

Be deliberate about which gates block versus which merely report. Blocking on everything trains people to bypass; blocking on nothing means the gates are decorative. Block on secrets and critical vulnerabilities in new code; report the rest.

Where the SSDF fits

The NIST Secure Software Development Framework organises practices into preparing the organisation, protecting the software, producing well-secured software, and responding to vulnerabilities. It is increasingly referenced in procurement - particularly for anyone selling to US government - and it maps cleanly onto the pipeline controls above, which makes it a useful structure for evidencing what you already do.

Emergency changes

Every framework accepts that emergencies happen; none accept an undocumented emergency path. Define it explicitly: who can invoke it, what minimum controls still apply, and the requirement for retrospective review and approval within a defined window. Then measure how often it is used - a rising emergency change rate is a process problem, and auditors sample these first.

The human parts you cannot automate

• Threat modelling for significant features.
• Security review of architectural changes.
• Secure coding training with completion records.
• A documented vulnerability disclosure process.
• Periodic review of who can approve and who can deploy.

Key takeaways

• Change control needs authorisation, testing, traceability and reversibility - not a board.
• Disabling self-merge removes the most common engineering audit finding.
• Block on secrets and critical new findings; report the rest.
• Define the emergency change path and measure how often it is used.