DevSecOps and Shift-Left Security

What it is

DevSecOps is the practice of integrating security work into the same development and deployment pipeline that engineering teams already use. Instead of security being a gate at the end of the process (a pen test before launch, a security review meeting two weeks before go-live), it becomes a continuous activity that runs alongside development.

Shift-left is the philosophy underneath it. The observation is simple: a security issue caught while a developer is writing code costs minutes to fix. The same issue caught in code review costs hours. In QA, days. In production, weeks or months and possibly customer impact. Moving the catch point earlier (left on the timeline) reduces cost and risk dramatically.

The reality of doing this well is more complicated than the slogan suggests. Most organisations that announce a DevSecOps programme end up generating large volumes of low-quality alerts that developers learn to ignore, and then wonder why the production posture has not improved. The patterns that actually work are about culture, signal quality, and integration, not just the tools.

Why it matters

The economics of fixing security issues are well documented. The famous IBM and NIST studies on defect cost show that issues caught at design or code time cost 10 to 100 times less to fix than the same issues caught in production. Security defects follow the same curve, often with steeper multipliers because production security issues can come with regulatory disclosure, customer notification, and reputational cost on top of the engineering work.

Beyond cost, there is the question of what gets shipped at all. In a model where security reviews happen at the end of the cycle, the choice at that point is to delay launch (rare) or to ship with known issues (common). Moving the review earlier means the issues get fixed before "are we launching?" is the question. Velocity goes up because the gates are smaller and earlier, not because the gates are removed.

The Log4Shell incident in late 2021 was a wake-up call for a lot of organisations on this front. The vulnerability itself was severe, but the bigger problem was that most organisations had no idea where Log4j was used in their stack. They could not answer the question "are we exposed?" without weeks of manual hunting. A mature DevSecOps programme with software composition analysis would have answered the question in minutes. The post-Log4Shell investment in SBOM tooling and dependency management came directly out of that experience.

The scanner alphabet soup

The four main categories of automated security scanning are easy to confuse and often misrepresented in vendor pitches. The distinction matters because each tool catches different classes of issue.

SAST (Static Application Security Testing)

SAST analyses source code without running it. The scanner reads the code, builds an AST or data flow graph, and looks for patterns that suggest vulnerabilities: SQL injection sinks reached from user input, hardcoded secrets, insecure deserialisation, and so on.

What it catches well: code-level vulnerabilities that follow recognisable patterns (injection, authentication flaws, path traversal, insecure cryptography use).

What it struggles with: framework-specific behaviour, runtime-only issues, and anything that depends on configuration. False positive rates can be high, especially for tools tuned for breadth rather than precision.

Examples: Semgrep, SonarQube, Checkmarx, Veracode, GitHub CodeQL, Snyk Code.

DAST (Dynamic Application Security Testing)

DAST tests a running application by sending HTTP requests to it. The scanner does not see the source code. It probes the application from the outside, looking for vulnerabilities by observing responses.

What it catches well: configuration issues, runtime authentication and authorisation flaws, some injection issues that are visible from the response, missing security headers.

What it struggles with: anything that requires understanding internal application logic, complex authenticated flows, anything in code paths the scanner does not reach.

Examples: OWASP ZAP, Burp Suite, Invicti, Acunetix.

SCA (Software Composition Analysis)

SCA analyses third-party dependencies. The scanner reads package manifests (package.json, requirements.txt, pom.xml, go.mod, Cargo.toml, etc.) and resolves the full dependency tree, then cross-references against vulnerability databases.

What it catches well: known vulnerabilities in dependencies. License compliance issues. Outdated packages with available updates.

What it struggles with: vulnerabilities in transitive dependencies that nobody has reported yet (zero-days), supply chain attacks where the package itself is compromised but not yet flagged, vulnerabilities that only manifest in specific code paths the application does not actually use.

Examples: Snyk, Dependabot, Renovate, Mend, Black Duck.

A note on transitive dependencies: most real applications pull in hundreds or thousands of indirect dependencies. The Log4Shell case was instructive because Log4j was almost always a transitive dependency, not a direct one. SCA tools that report only direct dependencies miss most of the surface.

IAST (Interactive Application Security Testing)

IAST instruments the running application from the inside, typically via an agent loaded into the runtime. As the application processes requests, the agent observes data flow and identifies vulnerabilities at the point they would be exploited.

What it catches well: vulnerabilities that depend on runtime context, like unsafe deserialisation that only triggers with specific input. Lower false positive rates than SAST because the agent sees real execution.

What it struggles with: only finds issues in code paths exercised during the test. Adoption has been slower than the other categories. Examples: Contrast Security, Hdiv, Seeker.

How shift-left works in practice

A working programme integrates these tools at multiple points in the development cycle.

In the IDE. Lightweight feedback while the developer is writing code. Linters that catch obvious issues, secret scanning that warns before a credential is committed. Fix cost at this point is essentially zero.

On commit / pull request. SAST scans on changed files only, SCA on the dependency manifest. Results posted as PR comments, blocking merge for high-severity issues.

On build. Container image scanning, IaC scanning, full SAST on changed modules. Build fails on critical findings.

On deploy to staging. DAST against the staging environment, runtime configuration checks, secret scanning across deployed config. Failures block promotion.

In production. Continuous monitoring, vulnerability scanning of running infrastructure, runtime application self-protection (RASP) where appropriate.

Each gate has a clear purpose, a clear severity threshold, and a clear path for the developer to address findings without filing a ticket and waiting two days.

Secret scanning

Secrets in repositories are one of the most consistent sources of breach. A developer pastes an API key into a config file, commits it, and either an attacker scrapes it or it surfaces when the repo is later breached.

The tools are mature and free, in three categories:

• Pre-commit hooks. TruffleHog, GitLeaks, detect-secrets. They run before the commit is created and block it if a secret pattern is found.
• Server-side scanning. GitHub native, GitLab native, and Bitbucket equivalents. GitHub additionally has "push protection" which blocks the push if a secret is detected.
• Continuous scanning of repository history. Scanning an entire git history, including deleted branches. Important because removing a secret in a later commit does not remove it from history.

A working programme combines all three. When a secret is found, removing it from the repo is necessary but not sufficient. The secret must be considered compromised and rotated. By the time you find it, you cannot prove that nobody else found it first.

Container scanning

Container images are themselves a supply chain. A typical image starts from a base image, layers application code, and possibly includes additional tooling. Each layer can contain vulnerabilities.

Standard tools: Trivy (open source, fast), Grype (from Anchore), Snyk Container, Docker Scout. Scanning works best when integrated at build time (the image is scanned before it is pushed to the registry) and continuously against the registry (so newly disclosed vulnerabilities in already-deployed images are caught).

A common pitfall is scanning images built months or years ago. Older base images accumulate vulnerabilities. The fix is rebuild and redeploy, not just patch. Programmes that do not rebuild regularly accumulate a long tail of old, vulnerable images in production.

IaC scanning

Infrastructure as Code (Terraform, CloudFormation, Bicep, Kubernetes manifests, Helm charts) defines cloud and infrastructure configuration. The configuration itself can contain security issues: a publicly accessible S3 bucket, an over-permissive IAM policy, a database with no encryption at rest, a Kubernetes pod running as root.

Tools include Checkov (broad coverage), tfsec (Terraform-specific), KICS (cross-platform), Snyk IaC, and cloud-native equivalents at runtime (AWS Config, Azure Policy). IaC scanning is one of the highest-value early integrations because the cost of catching a misconfiguration in the PR is minimal and the cost of catching it after deployment can include data exposure.

Common pitfalls

The patterns that make DevSecOps programmes fail are consistent across organisations.

• Alert fatigue from low-quality scanners. A SAST tool with a 50 percent false positive rate trains developers to ignore everything it produces. Tuning matters more than coverage.
• Security as the team that says no. When security gates are seen as obstacles, developers route around them.
• Scanners that block the build but provide no fix path. "Critical: SQL injection in line 47" is half a finding. Tools that include fix suggestions or auto-PRs (Dependabot, Renovate) close the loop.
• Ignoring transitive dependencies. Most vulnerabilities in modern applications come from transitive dependencies. SCA tools that only flag direct dependencies miss most of the problem.
• No path to fix old issues. New code gets scanned, but the existing codebase has thousands of pre-existing findings. Without a triage and burn-down plan, those findings accumulate forever.
• Production drift from CI/CD assumptions. Runtime configuration, manual changes, and zero-day disclosures all create posture drift after deployment. The pipeline is necessary but not sufficient.
• Treating shift-left as shift-only. Catching everything earlier is good. Abandoning runtime monitoring is dangerous.

Paved roads and guardrails

Two patterns from mature DevSecOps programmes are worth knowing because they reframe the work.

A paved road is a curated, security-approved way of doing something common. The standard service template, the standard cloud account configuration, the standard CI/CD pipeline. Developers who follow the paved road get security-by-default with no extra work. They do not have to think about it.

A guardrail is an always-on enforcement that prevents the worst outcomes regardless of what the developer does. A policy that prevents creating a public S3 bucket. A network policy that blocks egress from production to the internet. An IAM policy that prevents a service account from gaining admin.

Paved roads make secure choices easy. Guardrails make insecure choices hard. The combination is much more effective than security review meetings, and it scales across thousands of services in a way human review cannot.

Best practices

• Tune scanners for low false positive rate before broad coverage. A tool developers trust beats a tool with more rules they ignore.
• Integrate at multiple points, not just one. IDE, commit, build, deploy, runtime. Each catches different classes of issue.
• Make findings actionable. Severity, fix guidance, and where possible auto-PRs.
• Build paved roads. The standard template should be the secure template.
• Add guardrails for the things that matter most. Public buckets, broad IAM, internet-facing databases, hardcoded secrets. Block at the policy level.
• Treat the SBOM as a first-class artefact. Generated on every build, queryable when a new vulnerability drops.
• Rotate any secret that ends up in a repo. Found and removed is not the same as not compromised.
• Rebuild containers regularly. A container that has not been rebuilt in six months is unlikely to be patched.
• Measure what matters. Time to remediate, paved-road adoption, false positive rate of each scanner.
• Invest in developer experience. A scanner that runs in three seconds is used. A scanner that runs in three minutes is bypassed.

The teams that get this right end up with security as an embedded part of how they ship software, rather than a separate activity that happens to or against them.