What does secure software delivery mean?
Getting software from a developer’s change to a running system without losing track of what was built, what went in it and who approved it.
What the term covers
Secure software delivery is the set of practices that get a change from a developer to a running system without losing track of what was built, what went into it, and who approved it. It covers the pipeline, the artefacts it produces and the evidence it leaves behind.
DevSecOps is the more common name for the same idea, expressed as a working arrangement rather than a set of tools: security work happens inside the delivery process, carried out by the people who build and run the software, rather than as a gate applied afterwards by a separate team.
Both terms suffer from being sold as products. Neither describes a tool you buy. They describe where in the process decisions are made, and what the process can prove afterwards.
What a secure delivery pipeline actually does
Most of the substance sits in a handful of properties. A pipeline has them or it does not:
- Every change is traceable to a person and a review. Not "was scanned", but "was approved by someone who could have said no".
- Builds are reproducible enough that you can say what went into a released artefact, which in practice means a component record produced by the build itself.
- The pipeline’s own permissions are scoped. A build system that can deploy anything anywhere is usually the widest privilege in an organisation and the least reviewed.
- Artefacts are signed, and the thing deployed is verified to be the thing that was built.
- Secrets are not in the repository, the image, or the build log.
- Findings have an owner and a decision, including the decision to accept them. A scanner wired to a pipeline that nobody acts on adds delay, not security.
Secure distribution
Delivery does not end at deployment when the software goes to someone else. Signing, a verifiable path from build to download, and a way to tell customers that an update matters are part of the same chain. Supply-chain attacks of recent years mostly targeted this segment rather than the source code.
Why auditors and customers ask about it
A delivery process that records its own decisions answers most of what an ISO 27001 auditor, a NIS2 assessment or an enterprise security questionnaire asks about change management, without anyone assembling a document by hand. That is the practical argument for doing the work: the evidence is a by-product rather than a project.
The questions that tend to be hard to answer are consistent across all three: what exactly is running in production, what went into it, who approved it, and what would you do if a component in it turned out to be vulnerable tomorrow.
Scanning without ownership.
Dependency scanning runs on every build and reports findings.
No one is named to triage them, so the backlog grows and the build is set to warn rather than fail.
The control exists on paper and produces no decisions. An auditor sampling three findings will see this immediately.
Composite example of a common pattern, not a client case.
Where to start if little of this exists
Starting with tooling is the usual mistake. The cheaper opening moves are organisational:
- Write down how a change actually reaches production today, including the exceptions. The gap between that and the assumed process is usually the finding.
- Establish what is running in production and what it was built from. Everything else depends on this.
- Reduce what the pipeline is allowed to do, and separate build credentials from deploy credentials.
- Pick one class of finding, give it an owner and a response time, and make that real before adding a second scanner.
- Add signing and verification once you can say reliably what you built.
Common questions
Is DevSecOps a tool or a team?
Neither, although both get sold under the name. It is an arrangement in which security tasks sit with the people delivering the software, supported by tooling and by someone accountable for the decisions.
Do we need to fail the build on every finding?
No, and doing so usually leads to the check being bypassed. A useful pipeline fails on a small, agreed set of conditions and routes everything else to a named owner with a response time.
How does this relate to SBOM and VEX?
The pipeline is where an accurate SBOM comes from, because only the build knows what it included. VEX statements are the assessment applied to that inventory afterwards.
We use a managed platform. Does this still apply?
Yes, with a different boundary. The platform takes on part of the chain; what remains yours is the configuration, the permissions granted to pipelines, the secrets, and the decisions about findings.
Is this the same as shifting left?
"Shift left" describes moving checks earlier. It is one part of this, and on its own it tends to produce earlier findings without changing who acts on them.
You do not need to know the technical term.
Tell us what is happening, what it affects and when you need help. We’ll discuss whether we can help and what a useful first piece of work would be.