DevSecOps for Enterprise Applications

DevSecOps is one of the more abused terms in enterprise security. By 2023 it has come to cover everything from running a vulnerability scanner in a pipeline to a comprehensive security operating model. The breadth obscures what DevSecOps actually requires in regulated enterprise estates and where the leverage actually is.

This piece is a practitioner view of which security controls belong in the engineering pipeline, which belong at runtime, and which controls produce friction without value and should be removed.

The core idea, restated

DevSecOps as a phrase is unwieldy. The underlying idea is straightforward: security checks that used to happen late in the lifecycle (penetration tests before launch, security review boards, audit-driven gates) should happen continuously during engineering. Issues that used to surface during release week should surface during pull-request review.

The result, when done well, is a security posture that is stronger and a release process that is faster. The result, when done badly, is the worst of both worlds: late-stage gates remain, with additional pipeline gates added on top, producing pipelines that take hours to run for no security improvement.

The difference is in which controls genuinely move left versus which controls are added in addition to the existing late-stage controls.

Controls that belong in the pipeline

The controls where shift-left genuinely works:

Static application security testing (SAST). Pattern-matching against known vulnerability classes in source code. Tools like SonarQube, Checkmarx, Veracode, Snyk Code, and the security features of platform-native code scanners (GitHub Advanced Security, GitLab Ultimate) run at build time. False positive rates have improved significantly; modern SAST is useful in the pipeline rather than as a separate exercise.

Software composition analysis (SCA). Scanning dependencies for known vulnerabilities. Snyk, Dependabot, GitHub Dependabot, Renovate, and equivalents alert on vulnerable dependencies and propose updates. This is one of the highest-value pipeline controls because dependency vulnerabilities are the most common source of practical compromise.

Container image scanning. Trivy, Snyk Container, Anchore, Twistlock, and the cloud-provider equivalents scan container images for vulnerabilities at build time. Critical CVEs in base images become visible before the image is deployed.

Infrastructure as code scanning. Checkov, tfsec, Snyk IaC, and equivalents scan Terraform, Bicep, CloudFormation, and Kubernetes manifests for misconfigurations. The classic findings (S3 buckets with public access, security groups with 0.0.0.0/0 ingress, RBAC bindings to wildcard subjects) are caught in the pull-request rather than in production.

Secret detection. GitGuardian, TruffleHog, and platform-native secret scanners detect credentials accidentally committed to source. Critical for hygiene; pairs with secret rotation policies for credentials that did get exposed.

License compliance. FOSSA, Snyk License, and equivalents flag dependencies whose licences conflict with the organisation's policy. Useful for legal review continuity; less critical for security but often bundled.

These controls all share a property: they catch real issues, they have manageable false-positive rates, and they execute fast enough to fit in a pull-request workflow.

Controls that belong at runtime

Other controls do not benefit from shift-left and belong at runtime:

Dynamic application security testing (DAST). Running tests against a deployed application. DAST tools (OWASP ZAP, Burp Suite, Acunetix) discover runtime behaviour that static analysis cannot — authentication flow issues, session handling, real-world injection vulnerabilities. DAST belongs in a deployment pipeline against an ephemeral test environment, or in a periodic security testing schedule against staging.

Runtime application self-protection (RASP). Tools that monitor application behaviour at runtime and detect anomalous activity. Useful as defence-in-depth; not relevant to shift-left.

Runtime intrusion detection. Falco, Sysdig Secure, AWS GuardDuty, Azure Defender for Cloud, Google Security Command Center detect anomalous behaviour at the cluster or cloud level. Production controls, not pipeline controls.

Penetration testing. Adversarial assessment by skilled testers. Should be periodic, scoped, and skilled — not continuous and not pipeline-integrated. Pen testing is too expensive and too slow for every release; it belongs as a quarterly or major-release exercise.

The mistake is trying to shift everything left. Some controls work better at runtime; trying to force them into the pipeline produces worse outcomes than running them where they fit.

Controls that have outlived their purpose

Some controls in mature enterprise security programmes have become friction without value. Honesty about which controls to retire is part of DevSecOps discipline.

Pre-release security questionnaires that are filled in by reading the architecture diagram. These were useful when security teams were external to engineering. They are theatre when engineering and security collaborate continuously.

Vulnerability scanning programmes that produce reports nobody reads. Quarterly Nessus reports of thousands of findings, sorted by severity, with no remediation pipeline. The reports exist; the security posture does not improve.

Annual penetration tests against systems that change weekly. The findings are stale by the time they are reported. Quarterly pen tests against major surfaces, with focused tests after meaningful architecture changes, beat annual pen tests against the whole estate.

Manual security gates after CI/CD has automated upstream controls. If SAST, SCA, IaC scanning, secret detection, and license compliance all pass automatically, an additional manual security review at the gate is rarely catching net-new issues.

Retiring these controls is unpopular because they look like risk reduction on paper. Honest assessment of what the controls actually catch versus what they cost separates security programmes that mature from programmes that accumulate ceremony.

The supply chain dimension

A development in the last few years that matters: software supply chain security has moved from theoretical concern to operational necessity. The SolarWinds breach, Log4j, and similar incidents have made supply chain attacks an enterprise-board topic.

The controls that matter:

• Software Bill of Materials (SBOM) generation in the build pipeline. SPDX or CycloneDX format. Stored alongside the build artefact. Available for audit and incident response.
• Signed builds. Build artefacts signed with the build pipeline's identity. Sigstore (cosign), in-toto, and equivalents make this practical.
• Verified provenance. Build provenance attesting that a given artefact came from a specific source, built by a specific pipeline. SLSA (Supply-chain Levels for Software Artifacts) is the framework most widely adopted.
• Dependency review at addition. New dependencies are reviewed for licence, maintainer reputation, and recent vulnerability history before being added. Not all dependencies; specifically the ones being newly introduced.
• Pinned versions in production. No "latest" or floating versions. Every production artefact is reproducible from its inputs.

The supply chain controls are unglamorous and operationally heavy. They are also where the most consequential attacks have landed in the last three years. Skipping them is increasingly indefensible in regulated industries.

The operating model

The technical controls above are necessary; the operating model is what makes them work.

Security as a partner, not as a gate. Security engineers embedded in engineering teams, not in a separate organisation that reviews and approves. The embedding pattern produces faster feedback and better outcomes.

Findings backlog as a real backlog. Vulnerabilities found by tools get tracked, prioritised, and worked alongside feature work. A backlog of 10,000 findings with no remediation cadence is not a security control; it is a list.

SLA on remediation. Critical findings remediated within X days, high within Y, medium within Z. Published, measured, reported. The SLA discipline turns the tool output into operational reality.

Incident response practice. When something does go wrong, the response is rehearsed. Tabletop exercises, runbooks, defined escalation paths. The incident is not the place to invent the response.

Periodic audit by a fresh pair of eyes. Internal security teams develop blind spots. Periodic external assessment — penetration testing, architecture review, red team exercises — catches what the internal team misses.

What we recommend

For an enterprise estate adopting DevSecOps:

1. Implement the five shift-left controls (SAST, SCA, container scanning, IaC scanning, secret detection) in the pipeline. These produce the largest single delta in security posture.
2. Set up SBOM generation and signed builds. Supply chain attacks are increasingly common; the controls are now operationally feasible.
3. Define the remediation SLA. Without an SLA, findings accumulate without being addressed.
4. Embed security engineers in engineering teams. The partner model produces better outcomes than the gate model.
5. Audit the existing security controls. Which are catching real issues? Which have become ceremony? Retire the ceremony.

For an existing DevSecOps programme that has accumulated friction:

1. Measure the pipeline runtime and the false-positive rate. Both are usually higher than the team thinks.
2. Tune the tools. Most SAST and SCA tools have aggressive default settings that produce high false-positive rates. Tuning improves signal-to-noise dramatically.
3. Retire controls that produce findings nobody addresses. They are friction without value.
4. Strengthen the supply chain controls. Most enterprise pipelines we audit are weak here.

DevSecOps done well looks like a faster release cadence with stronger security posture. DevSecOps done badly looks like a slower release cadence with the same security posture as before, plus more dashboards. The difference is in which controls are deployed, where they execute, and whether the operating model actually addresses what they find.