DevSecOps

Executive summary

Security reviewed once, at the end of delivery, cannot keep pace with software that changes continuously. DevSecOps moves security into three places at once: the pipeline, where checks run automatically on every change; the platform, which offers a secure path that teams follow by default; and the culture, where developers and security specialists share ownership instead of handing work across a gate. Controls that run automatically also emit logs, approvals and attestations, so the evidence that an audit or an incident later requires already exists.

• The NIST Secure Software Development Framework (SSDF) provides a common, outcome-based vocabulary in four practice groups; the pipeline is where many of its practices become automatic.
• Secure development habits come first: threat modeling tied to change, secure coding standards, security in peer review, pre-commit secret detection and security champions.
• Static analysis, composition analysis, secret scanning, infrastructure and image scanning, and dynamic testing each find different flaws; gates block what is serious and actionable now and route the rest to the backlog.
• Supply chain integrity rests on pinned inputs, isolated builds, a software bill of materials (SBOM), signatures and provenance verified before deployment; SLSA describes levels of build integrity to aim for.
• Pipelines are high-value identities: secrets come from managed stores, cloud access uses short-lived federated credentials, and build and deploy run as separate identities.

The intent of each control is the same in organizations of every size; what changes is how it is run, from informal and manual toward automated, enforced and evidenced. The closing sections describe a five-stage maturity path, the pitfalls that recur, the measures that give early warning, and a first 90 days that produces working controls on one real service.

Why a gate at the end fails

Traditional application security was organized around a checkpoint: a penetration test or a security review shortly before release. That model assumed releases were rare and large. When a team deploys many times a week, a review at the end has two failure modes. It becomes a bottleneck that delivery learns to route around, or it becomes a rubber stamp that approves changes nobody had time to read. Neither reduces risk.

A security gate at the end of delivery cannot keep pace with continuous change.

The alternative is to build security into the places where software is made and run. In the pipeline, automated checks run on every change at the stage where each is cheapest and most accurate. In the platform, golden paths make the secure configuration the default configuration, so teams inherit controls instead of reimplementing them. In the culture, developers and security specialists share ownership of outcomes: the security function sets standards, builds tooling and advises, and delivery teams own the security of what they build.

Evidence is the quiet benefit. Controls that run automatically leave records: which checks ran, what they found, who approved an exception and which artifact was deployed. When an auditor asks whether a control operated, or an incident responder asks which builds contain a vulnerable component, the answer already exists rather than being assembled under pressure.

Security across the delivery flow

Shift left, and security everywhere

Shift left is often misread as moving every check onto the developer. The accurate reading is that security acts at every stage of delivery, as early as each risk can be caught, because a flaw is cheapest to fix closest to where it enters. Some risks can only be seen later: a misconfigured deployment, a vulnerability disclosed in a dependency after release, an attack in production. Security everywhere means that every stage has an owner and an automated control, and that what runtime detection finds flows back to the code.

Each control sits where its risk first becomes visible. A design flaw is cheapest to catch in a threat model before any code exists; a hardcoded key is cheapest to catch in a pre-commit hook before it enters shared history; a vulnerable library can be caught when it is added, but must also be caught on a schedule, because vulnerabilities are disclosed long after code is written. Tampering with a build can only be detected by verifying signatures and provenance at deployment, and an attack that exploits an unknown flaw can only be seen at runtime. A program that concentrates all its effort on one stage leaves the others open.

The pipeline and its dependencies are also an attack surface in their own right, not just a path to production. A compromised build system, a malicious dependency or a stolen pipeline credential can deliver an attacker's code to every user, signed with the organization's own keys. Securing the delivery system is therefore part of securing the software.

Anchoring on the NIST SSDF

The National Institute of Standards and Technology (NIST) Secure Software Development Framework, published as Special Publication 800-218, is not a tool or a product but a common vocabulary of secure development practices. It organizes them into four groups, and many of its tasks become automatic once they are built into the pipeline and the platform.

NIST describes the SSDF's practices as outcome-based: they state what a practice should achieve rather than which tool to use, so each organization chooses implementing controls appropriate to its size and risk. That makes the framework a good anchor for a pipeline program. Each automated check can be mapped to the SSDF tasks it satisfies, and the pipeline's records become evidence that those tasks are performed. NIST revises the framework from time to time and publishes community profiles that extend it, such as SP 800-218A for generative AI and dual-use foundation models, so teams should map their controls to the revision that their customers or regulators reference.

Secure development practices

Automated checks find known patterns; they cannot tell whether a design is sound. The practices in this section put security judgment into the design and review of each change, where it costs least.

Threat modeling as a design habit

The Threat Modeling Manifesto defines threat modeling as analyzing representations of a system to highlight concerns about its security and privacy characteristics. It is most useful small and frequent: triggered when a new feature, data flow or trust boundary appears, not scheduled once a year as a heavyweight gate. Four questions, associated with Adam Shostack and adopted by the manifesto, frame each session: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job?

A team sketches the components, data stores and trust boundaries involved in a change, then uses a structured prompt to find threats. STRIDE, a mnemonic that originated at Microsoft, is one widely used method: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege, each suggesting a class of threat to test against every element and flow. Shostack's Threat Modeling: Designing for Security sets out the practice in depth. Each identified risk is mitigated, accepted or transferred, and the decision is recorded with its reasoning. Mitigations then become backlog items and tests, so that threat modeling changes the code rather than filling a document.

What a secure change includes

A secure change carries its security with it, so the checklist below belongs in the team's definition of done rather than in a separate, later review.

Secure coding standards give developers concrete rules. The OWASP Top 10, published by the Open Worldwide Application Security Project (OWASP), is the reference standard for the most critical web application security risks and a common starting point for training. For requirements, the OWASP Application Security Verification Standard (ASVS) provides a catalog of verifiable security requirements organized into three levels, so a team can adopt the level that matches an application's risk and test against it. Peer review then treats security as an explicit item rather than an afterthought.

Pre-commit hooks catch formatting problems and secrets before they reach the shared history. This matters because a secret committed once must be treated as compromised: it persists in history, clones and forks even after the line is deleted, so the only safe response is to revoke and rotate it. Security champions, developers with additional security training embedded in each team, advise on higher-risk changes, help triage findings and carry practice between the security function and delivery teams. They extend a small security team's reach without turning it into a bottleneck.

Automated checks in the pipeline

Each automated check answers a different question, so a mature pipeline runs several, each at the stage where it is cheapest and most accurate.

No single tool covers the ground. Static analysis sees the code the team wrote but not the libraries it imports; composition analysis sees the libraries but not the team's own logic; neither sees how infrastructure is configured; and only dynamic application security testing (DAST) and application programming interface (API) security tests see the running application as an attacker would. Because dynamic tests are slower and noisier, they usually raise tickets rather than block. Composition analysis needs a schedule as well as a build trigger, because vulnerabilities are regularly disclosed in dependencies that have not changed since the last release.

Teams adopting automated checks for the first time usually start with secret scanning and composition analysis, which are precise and cheap, then add static analysis tuned to their languages and frameworks. Existing findings should be baselined, so that the gate applies to what each change introduces rather than to years of accumulated debt, while the backlog of older findings is worked down by priority.

What blocks the build, and what becomes a ticket

A gate must be sharp enough to stop real danger and loose enough that delivery keeps moving, or teams will route around it. The dividing line combines severity, exploitability and whether this change introduced the problem. A finding that is serious and actionable now should stop the build; everything else becomes a tracked ticket with an owner and a due date.

False positives are expected. They are managed by tuning rules and suppressing specific findings with a recorded reason, never by turning a check off. Every block needs a documented exception path with an approver and an expiry date, so that an exception is a time-boxed risk decision rather than a permanent bypass. Exceptions that are renewed again and again signal a rule that needs revision or a fix that needs funding.

Supply chain integrity

Modern applications are mostly assembled from components the organization did not write: open-source libraries, base images, build tools and hosted services. Supply chain integrity is the discipline of knowing what went into each artifact, proving how it was built, and ensuring that only trusted artifacts are deployed.

From source to a signed, verifiable artifact

The goal is an artifact that a deployer can trust without re-examining its source.

Pinning dependencies to exact versions, ideally by cryptographic digest, and resolving them from a private registry makes the build deterministic and its inputs auditable. The build then runs isolated on a trusted runner with access only to its declared inputs. A hermetic build goes further and has no network access beyond those inputs, and a reproducible build yields bit-for-bit identical output from the same inputs, so that anyone can rebuild an artifact and compare the result to detect tampering. The build produces a software bill of materials (SBOM), a machine-readable inventory of the components and versions in the artifact. The two widely used formats are SPDX, a Linux Foundation project published as the international standard ISO/IEC 5962, and CycloneDX, an OWASP project standardized by Ecma International as ECMA-424.

The artifact is then signed and given an attestation of its provenance: verifiable metadata about how, where and from what it was built. Sigstore, an Open Source Security Foundation (OpenSSF) project, makes signing practical at scale. Its Cosign client signs and verifies artifacts; its Fulcio certificate authority issues short-lived certificates bound to an OpenID Connect (OIDC) identity, such as a CI workflow; and its Rekor transparency log records each signing event in an append-only public ledger. Because the signing key is ephemeral, there is no long-lived private key to manage or leak. Finally, admission control in the target environment admits only artifacts whose signature and provenance verify. Build once, sign once and verify on the way in.

SLSA levels for build integrity

Supply-chain Levels for Software Artifacts (SLSA), an OpenSSF framework, describes incremental levels of supply chain assurance in separate tracks. Its Build track concentrates on provenance and on hardening the build platform; a Source track covers the integrity of source code, from version control and preserved change history through to enforced technical controls and two-party review.

For most organizations Build L2 is a realistic first target, because several hosted CI platforms can generate signed provenance with little effort, and Build L3 is the target for critical artifacts. Hermetic and reproducible builds are complementary practices rather than SLSA Build requirements: they make tampering easier to detect and are worth pursuing where the risk justifies the effort.

Minimum elements of an SBOM

An SBOM is only useful if it is complete and consistent enough to answer questions such as which deployed services contain a vulnerable library. Guidance on the minimum elements of an SBOM was first set out by the US National Telecommunications and Information Administration (NTIA), which grouped them into data fields, automation support, and practices and processes. The Cybersecurity and Infrastructure Security Agency (CISA), with the National Security Agency, the FBI and international partners, has since revised and expanded that baseline. In broad terms it expects:

• Component data: for each component, its producer, name, version, unique identifiers (such as a package URL), dependency relationships, a cryptographic hash and license information.
• SBOM metadata: who authored the SBOM and when, with which tool, in what format and version, and in what context it was generated.
• Machine-processable formats: SPDX or CycloneDX, so that SBOMs can be generated, exchanged and queried automatically.
• Practices: coverage of all components including transitive dependencies, explicit marking of what is unknown, a new SBOM for every new build or release, and defined arrangements for distribution and access.

The guidance creates no legal obligation on its own, but it gives producers and buyers a shared definition of a usable SBOM. That definition is easiest to meet by generating SBOMs automatically in the pipeline for every build, rather than by hand when a customer asks.

The supply chain around each artifact

Every element around the artifact is a potential entry point, and attackers target dependencies, build systems and distribution channels precisely because a single compromise reaches everyone downstream. Log4Shell, a critical vulnerability in the very widely used Apache Log4j logging library, showed how one flaw deep in the dependency tree can expose a vast population of applications, and how slowly organizations without an inventory find every affected system. The defenses are consistent: pin and verify the inputs, keep the build system isolated and least-privileged because it is itself a high-value target, sign the outputs and attach an SBOM and provenance, and keep base images minimal and patched, rebuilding rather than patching in place. With SBOMs and provenance recorded for every build, a newly disclosed vulnerability can be traced quickly to every artifact and deployment that contains it, instead of by manual search.

Taking in and acting on vulnerabilities

Vulnerability management only works as continuous intake, because new vulnerabilities arrive in code that has not changed. Four steps turn the stream of findings into closed risk.

A Common Vulnerabilities and Exposures (CVE) identifier gives each publicly disclosed vulnerability a shared name. The Common Vulnerability Scoring System (CVSS), maintained by FIRST (the Forum of Incident Response and Security Teams), scores a vulnerability's severity relative to other vulnerabilities from its characteristics. It is a useful starting point but not a decision on its own, because the same flaw can be critical in one deployment and unreachable in another. Exploitation signals sharpen the priority. The Known Exploited Vulnerabilities (KEV) catalog maintained by CISA lists vulnerabilities known to be exploited in the wild, and CISA recommends using it as an input to vulnerability prioritization; the Exploit Prediction Scoring System (EPSS), also from FIRST, estimates the probability that a published CVE will be exploited in the wild in the next 30 days. Due dates follow priority, and the same pipeline that found a flaw verifies its fix.

Secrets, identity and deploy-time policy

A pipeline is one of the most privileged identities in an organization: it can reach source code, build infrastructure, registries and, often, production. It deserves the protection given to an administrator.

Secrets and identity controls for pipelines

Securing a pipeline starts with secrets. They come from a managed secrets store and are injected at run time, never committed to code, baked into images or pasted into pipeline configuration, and they are masked and scrubbed from logs. The larger shift is away from stored cloud credentials altogether. Instead of a long-lived access key sitting in the continuous integration (CI) system, the pipeline authenticates through OpenID Connect (OIDC) federation: the CI platform issues a signed token describing the job, such as its repository, branch and target environment, and the cloud provider exchanges it for temporary credentials scoped to a role that trusts only that job. There is no durable key to steal. Deploy-time policy then admits only signed and compliant artifacts, and runtime detection and incident response close the loop for whatever escapes the earlier controls, feeding new rules back into the pipeline.

Long-lived keys and federated short-lived identity

Both approaches let a pipeline act on the cloud, but they fail differently. A long-lived key is a standing credential: it has to be stored, its storage makes the CI system a high-value target, it tends to be over-scoped, it survives in old logs and backups, and manual rotation is the first task dropped under delivery pressure. Federated identity inverts each of these properties. The same principle of separation applies inside the pipeline: build and deploy run as distinct identities, so that the ability to build an artifact is not the ability to release it, and a compromised build step cannot reach production.

Scale, culture and maturity

This paper uses three size bands as a convention rather than as fixed categories. A small organization has one or two teams and no dedicated security function. A medium organization has several teams, a platform or enablement team forming and some regulated change. A large organization has many teams, a platform organization and formal audit obligations. The intent of each control is the same in every band; what changes is how it is run.

What changes with scale

A small organization may rely on developers with occasional expert advice, a few key checks and informally time-boxed exceptions, producing pipeline logs on request. A large one pushes the same controls into golden paths enforced by policy as code, runs build and deploy under separate short-lived identities, and produces evidence continuously for auditors and for each of the three lines in the Institute of Internal Auditors' Three Lines Model: the management roles that own risk, the roles that provide expertise, monitoring and challenge, and internal audit. The direction of travel is from manual and informal toward automated, enforced and evidenced, taken one service at a time rather than all at once.

Evidence for auditors

Evidence is where DevSecOps repays its investment twice. A pipeline that records which checks ran and what they found, who reviewed and approved each change, which exceptions were granted and when they expire, the SBOM and provenance of each artifact, and the deployment that used it can answer most audit questions with a query. Mapping those records to the SSDF, or to whichever control framework applies, turns routine delivery into continuous assurance and replaces the periodic scramble for screenshots.

A staged maturity path

A maturity model gives teams a shared description of where they stand and what comes next. It runs from ad hoc practice, where security differs by team and checks are manual and late, to an evidenced stage where audit evidence is produced continuously.

The defined stage makes expectations explicit by naming an owner for each control; the automated stage turns those standards into defaults; the enforced stage makes the secure path the path of least resistance. Three rules apply throughout. Assess maturity per service and per team rather than as a single score for the organization. Move the most critical services first. And skip no stage, because enforcement without automation only creates friction that teams learn to bypass. Organizations that want an external yardstick can use OWASP SAMM, the Software Assurance Maturity Model, which assesses fifteen security practices grouped into five business functions (governance, design, implementation, verification and operations), each with three maturity levels.

Pitfalls and early-warning measures

A small set of measures gives early warning that controls are drifting from behavior into paperwork.

Where to start: the first 90 days

The first 90 days should produce working controls on one real service rather than a plan on a shelf. Choose a service that matters, with a team willing to pilot, and apply each step to it before widening.

1. Days 1 to 30: model and stop the leaks. Threat model the service and turn on secret scanning in pre-commit hooks and in its pipeline; revoke and rotate anything the scan finds.
2. Days 1 to 30: know what ships. Inventory the service's dependencies, pin them and generate a first SBOM in the pipeline, since knowing what is shipped is the basis for everything else.
3. Days 31 to 60: add analysis with sensible gates. Add static and composition analysis with severity-based gates, a baseline for existing findings and a documented exception path.
4. Days 31 to 60: remove standing credentials. Move the pipeline off long-lived cloud keys to short-lived federated identity, and separate the build and deploy identities.
5. Days 61 to 90: sign, verify and measure. Sign artifacts, verify signatures at deploy time, and baseline a small set of security measures so that progress is visible.

At the end of 90 days the pilot service should have a threat model, secret scanning, an SBOM, gated analysis, federated identity and signed, verified artifacts, together with the measures that show it. Packaged into a golden path, the same controls can then reach the next services at a fraction of the effort. Security is built into delivery and proven continuously, not added at the end.

Glossary

DevSecOps

An approach that builds security into the delivery pipeline, the platform and the culture so that controls run continuously and produce evidence.

Shift left

Acting on security as early as each risk can be caught, without abandoning controls at later stages.

Secure Software Development Framework (SSDF)

NIST SP 800-218, an outcome-based set of secure development practices organized into four groups.

Threat modeling

Analyzing representations of a system to highlight concerns about its security and privacy characteristics.

STRIDE

A threat modeling mnemonic for spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.

SAST

Static application security testing: analysis of source code for insecure patterns without running it.

DAST

Dynamic application security testing: testing a running application from the outside for exploitable flaws.

SCA

Software composition analysis: inventory of third-party components and detection of their known vulnerabilities and license issues.

Software bill of materials (SBOM)

A machine-readable inventory of the components, versions and relationships in a piece of software.

Provenance

Verifiable metadata describing how, where and from what an artifact was built.

Attestation

A signed statement about an artifact, such as its provenance or test results, that a consumer can verify.

SLSA

Supply-chain Levels for Software Artifacts, an OpenSSF framework of incremental levels of supply chain assurance.

Hermetic build

A build with access only to its declared inputs and no other network access.

Reproducible build

A build that produces identical output from the same inputs, so that independent rebuilds can detect tampering.

CVE

Common Vulnerabilities and Exposures, the shared naming system for publicly disclosed vulnerabilities.

CVSS

Common Vulnerability Scoring System, a standard for scoring the severity of vulnerabilities.

KEV catalog

CISA's Known Exploited Vulnerabilities catalog of vulnerabilities known to be exploited in the wild.

EPSS

Exploit Prediction Scoring System, an estimate of the probability that a published CVE will be exploited in the wild in the next 30 days.

OIDC federation

Exchanging a short-lived, signed identity token issued by a CI platform for temporary cloud credentials, without stored keys.

Security champion

A developer with additional security training who advises their team and connects it to the security function.

Admission control

A check at deployment time that admits only workloads that meet policy, such as signed and verified artifacts.