DevSecOps is one of those words that arrives in a slide before it arrives in a repository. It is worth defining narrowly, because the broad definition is agreeable and useless.
The narrow version: DevSecOps means the checks that decide whether code is safe to release run inside the delivery pipeline, automatically, on every change, and can stop a release. Security is a gate the pipeline enforces rather than a review the pipeline waits for.
NIST puts the same idea in SP 800-218, which recommends a core set of high-level secure software development practices that can be integrated into each SDLC implementation. The phrase to notice is integrated into. Not appended to, not scheduled alongside.
Why Drupal makes this concrete
Drupal is a good place to see what the abstraction actually means, because a Drupal application has an unusually visible dependency surface and an unusually well defined deployment sequence.
A production Drupal site is Drupal core, some number of contributed modules, some number of custom modules, a theme, a set of PHP libraries underneath all of it, and a configuration state that decides what the software actually does. Composer, which describes itself as a tool for dependency management in PHP, resolves most of that tree. It is also careful to say that Composer is not a package manager in the same sense as Yum or Apt are: it manages libraries per project rather than software per machine.
That distinction matters here. The dependency tree belongs to the project, travels with the repository, and is therefore something a pipeline can inspect on every commit.
What the checks actually are
A Drupal DevSecOps pipeline is not exotic. It is a conventional pipeline with specific gates in specific places.
- Dependency validation. Confirm the lock file and the manifest agree, and that the build resolves the same tree every time. A build that resolves differently on Tuesday is not reproducible, and nothing downstream of it can be trusted.
- Static analysis and coding standards. Run on the pull request, where a finding costs a comment rather than a release.
- Software composition analysis. Scan the dependency tree against published vulnerability data. OWASP describes Dependency-Check as a Software Composition Analysis tool suite that identifies project dependencies and checks whether any have known, publicly disclosed vulnerabilities. This is the single highest value check on a Drupal codebase, because most of the code in a Drupal site was written by somebody else.
- A software bill of materials. A machine readable inventory of what actually shipped. CycloneDX describes itself as a modular and extensible framework designed to represent a broad range of supply chain information. An SBOM is what lets you answer, later and quickly, whether you are affected by a newly disclosed vulnerability.
- Build provenance. Evidence of how the artifact was produced. SLSA is organized into a series of levels that provide increasing supply chain security guarantees, and its first build level is simply that provenance exists.
- Dynamic testing. Exercise the running application in a staging environment before promotion.
- An approval gate. A human decision, recorded, before production.
The implementation detail, including where each of these sits in a real pipeline, is in building a Drupal DevSecOps pipeline in Azure DevOps.
The part people skip: the artifact
The check that quietly makes the others meaningful is building once and promoting the same artifact.
If staging builds its own copy of the dependency tree and production builds another, then the thing you scanned is not the thing you shipped. Every gate upstream becomes a statement about a build that no longer exists. Scanning a build you then discard is a form of theater, and it is common.
An immutable artifact, built once and promoted unchanged through every environment, is what turns the pipeline's findings into facts about production.
What is different about a Drupal deploy
Generic DevSecOps advice tends to assume the artifact is the whole story: build it, scan it, ship it. A Drupal release is not finished when the files land, and a pipeline that treats it as though it were will produce a site that is briefly and confusingly wrong.
Drush documents the sequence its deploy command performs after the codebase is in place: database updates, then configuration import, then a cache rebuild, then deployment hooks. The order is not incidental. Configuration import expects the schema the database updates just created, and the cache rebuild expects the configuration that import just applied.
Three consequences follow for anyone designing the pipeline.
- There is a window where the code is new and the database is not. On a busy site that window is visible to users. It is the reason maintenance strategy is a design decision rather than an afterthought, and why a release process that cannot be paused is a liability.
- Configuration is part of the release and belongs under the same gates as code. A configuration change can disable a security module, change a permission, or expose a form. If configuration is imported on deploy but reviewed nowhere, the pipeline is scanning half the change.
- Rollback is not just redeploying the previous artifact. Database updates are frequently not reversible. That is why the rollback plan has to be designed rather than assumed, and why it is treated separately in Drupal cutover and rollback strategy.
None of this is a reason to avoid automating a Drupal deployment. It is a reason to automate the whole sequence, deliberately, rather than the file copy. That is the subject of Drupal lifecycle automation.
What DevSecOps is not
Three honest limits, because a term this popular attracts claims it cannot support.
It is not a substitute for runtime security. A pipeline that scans dependencies perfectly says nothing about whether the web application firewall is configured, whether administrative accounts use multi-factor authentication, or whether secrets are in an environment variable somebody pasted into a wiki. That is a separate and equally necessary body of work, covered in Drupal cloud security architecture.
It is not compliance. Aligning a pipeline with the practices in SP 800-218 is useful and is not the same as being assessed against anything. No tool in this list certifies an organization, and no vendor can sell a certification for a framework that does not issue one.
It is not a guarantee about unknown vulnerabilities. Software composition analysis compares your dependency tree against publicly disclosed vulnerabilities. It is excellent at the known and silent about the rest. Its value is that it removes the excuse of not knowing, which is the category most incidents actually fall into.
Where the effort goes
In practice the work divides unevenly, and the split surprises people who expect the tooling to be the hard part.
- Making the build reproducible. Usually the largest single piece of work on an existing estate, and the prerequisite for everything else.
- Deciding what breaks the build. A scanner that reports and never blocks trains everyone to ignore it. A scanner that blocks on every advisory stops all delivery within a week. The threshold is a policy decision, and it has to be made by somebody with the authority to defend it.
- Wiring the gates. Genuinely the easy part, once the first two are settled.
- Handling the findings. The steady state. A pipeline that produces findings nobody triages has moved the problem rather than solved it.
Point two is where most programs go wrong. The useful framing is that the pipeline's job is to make risk visible at the moment it is cheapest to act on, not to make risk impossible.
Why a migration is the right moment
Retrofitting security gates into an established pipeline means renegotiating a process every delivery team already depends on. Building them into a new one means they were simply always there.
That is the practical argument for doing this work during a platform move rather than after it. A modernization program is already changing how code reaches production; adding the gates while that is in flight costs a fraction of what it costs later. It is one of the reasons Drupal cloud modernization and DevSecOps are treated as one capability here rather than two.
If the estate is also moving off a proprietary platform, the sequence in migrating Drupal off a proprietary hosting platform assumes the pipeline is built before volume arrives, for exactly this reason.
A short test
If you want to know whether an organization is doing DevSecOps or describing it, four questions settle it quickly.
- Can a dependency vulnerability stop a release without a person deciding to stop it?
- Is the artifact that reached production the artifact that was scanned?
- Can you produce, today, a list of every component in the current production release?
- When a new advisory lands, how long does it take to know whether you are affected?
The fourth question is the one that tends to change the conversation, because the answer is usually measured in days and everyone in the room expects it to be minutes.
If you are working through those answers for a Drupal estate, the estate itself is the right place to start.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.