DevSecOps means treating security as an automated, continuous part of the delivery pipeline, the same way testing became a continuous part of it, rather than a manual review that happens once, late, right before a release or an audit. The core idea is often called “shift-left”: catching security problems as early as possible in the development process, ideally the moment a developer writes vulnerable code, rather than discovering it after it’s already deployed to production and potentially exploited.

This guide covers the specific automated checks that make up a real DevSecOps pipeline, static code analysis, dependency scanning, container image scanning, secrets detection, and infrastructure-as-code scanning, with working configuration for each, plus the identity and compliance practices that round out a genuinely secure delivery process. It also covers dynamic testing against a running application, the basics of threat modeling for catching design-level issues automated tools miss entirely, and how to roll all of this out to a team without overwhelming them with findings on day one.

None of this requires a dedicated security team to get started. Most of what’s covered here is open-source tooling that any DevOps engineer can wire into an existing pipeline directly, and the highest-value first steps are genuinely cheap to implement.

Where Security Checks Fit in the Pipeline

Static Code Analysis (SAST)

SAST tools scan your application’s source code looking for known vulnerable patterns, SQL injection risks, hardcoded credentials, insecure cryptographic functions, without ever running the application itself. Running this automatically on every pull request catches an entire category of vulnerability before a human reviewer even looks at the code.

# GitHub Actions step using Semgrep
- name: Run SAST scan
  uses: returntocorp/semgrep-action@v1
  with:
    config: p/security-audit

Semgrep is one of the more widely used open-source SAST tools, running fast enough to include in nearly every pipeline without meaningfully slowing it down, and covering common vulnerability patterns across most major languages out of the box using publicly maintained rule sets.

Dependency Scanning (SCA)

Most applications pull in far more third-party dependency code than code the team actually wrote themselves, and any one of those dependencies could carry a known vulnerability. Software Composition Analysis scans your dependency tree against public vulnerability databases and flags anything with a known issue, ideally before it merges, not months later when a security team happens to notice.

npm audit --audit-level=high
pip install safety && safety check
trivy fs .

Wiring one of these into CI, failing the build on a high or critical severity finding, is one of the highest-value, lowest-effort security additions any team can make; dependency vulnerabilities are a genuinely common real-world attack vector, and this category of check requires almost no ongoing maintenance once it’s set up.

Container Image Scanning

A container image, covered in depth in our Docker and containers guide, bundles an entire OS layer along with your application, and that base OS layer can carry its own known vulnerabilities independent of your application code. Trivy and Docker Scout are widely used open-source scanners that check a built image against vulnerability databases before it’s ever pushed to a registry or deployed.

# In CI, after building the image
- name: Scan image for vulnerabilities
  run: trivy image --exit-code 1 --severity CRITICAL,HIGH myregistry.io/my-app:${{ github.sha }}

--exit-code 1 fails the pipeline if any critical or high-severity vulnerability is found, preventing a vulnerable image from ever reaching the deployment stage. This is also a strong practical argument for the minimal base image practice covered in the Docker guide: fewer packages baked into an image means a genuinely smaller vulnerability surface to scan and patch in the first place.

Catching Secrets Before They’re Committed

Even with a well-maintained .gitignore, secrets accidentally end up committed to repositories constantly, a hardcoded API key pasted in for a quick local test and never removed. Secrets scanning tools like Gitleaks or TruffleHog check every commit for patterns matching known credential formats and can run as a pre-commit hook locally or as a CI check that blocks the merge entirely.

gitleaks detect --source . --verbose
gitleaks protect --staged

gitleaks protect --staged run as a pre-commit hook catches a secret before it’s even committed locally, which is meaningfully better than catching it in CI after it’s already been pushed and is potentially visible to anyone with repository access, even if the offending commit is later removed.

Scanning Infrastructure as Code

Misconfigurations in Terraform or CloudFormation, an S3 bucket accidentally left public, a security group open to the entire internet, are just as real a security risk as a vulnerability in application code, and just as scannable automatically. Tools like Checkov and tfsec check infrastructure-as-code files against known misconfiguration patterns before they’re ever applied to real cloud infrastructure.

checkov -d ./terraform --compact
tfsec ./terraform

Running this as a required check on every Terraform pull request catches an accidentally public S3 bucket or overly permissive security group, referenced in our Terraform guide and AWS guide, at review time rather than after it’s live in production and potentially already exposed.

Identity, Access, and Least Privilege

Automated scanning catches vulnerabilities in code and configuration, but a huge share of real breaches come from over-permissioned access rather than a clever exploit. The IAM least-privilege principle covered in our AWS for DevOps guide and the segregation-of-duties patterns from our Git and GitHub guide are both core DevSecOps practices, not separate concerns: limiting what any single compromised credential or account can actually do is often more impactful than any individual scanning tool.

Compliance as Code

For regulated industries, covered in our healthcare and banking industry guides, the same scanning tools that catch security issues also generate the evidence auditors need: a CI pipeline log showing every commit passed SAST, dependency, and IaC scanning is far stronger audit evidence than a manual attestation that “we reviewed the code,” since it’s an automatically generated, timestamped record rather than a claim.

Dynamic Testing: Checking the Running Application

Static analysis and dependency scanning check code before it runs; Dynamic Application Security Testing (DAST) checks a running application from the outside, the way a real attacker would, probing for issues like injection vulnerabilities or misconfigured authentication that only manifest at runtime and wouldn’t show up in a static code scan. DAST tools typically run against a staging environment as part of a scheduled or pre-release pipeline stage, rather than on every single commit, since they take meaningfully longer to run than the static checks covered above.

# OWASP ZAP baseline scan against a staging environment
docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t https://staging.example.com -r zap-report.html

OWASP ZAP is a widely used open-source DAST tool, and running a baseline scan like this against staging before every production release adds a meaningful additional layer of coverage beyond what static analysis alone can catch, since it’s testing actual runtime behavior rather than inferring risk from source code alone.

Threat Modeling: Thinking Like an Attacker Early

Automated scanning catches known vulnerability patterns, but it can’t catch a design flaw, like an API endpoint that leaks another user’s data because of a missing authorization check specific to your application’s business logic. Threat modeling is the practice of deliberately thinking through how a new feature could be abused before it’s built, not after: who might want to misuse this feature, what’s the worst outcome if they succeeded, and what would actually stop them.

This doesn’t need to be a heavyweight formal process for most teams. A short structured conversation during design review for any feature touching sensitive data, payments, authentication, user permissions, asking “how could this be abused” out loud before writing code, catches an entire category of design-level security issue that no automated tool downstream will ever find, because the tools are checking implementation, not intent.

Building a Security Champions Culture

A common structural pattern in mature DevSecOps practices: rather than routing every security question through a small, centralized security team that becomes a bottleneck, designate a “security champion” on each engineering team, an engineer with extra security training and a direct line to the central security function, who helps triage findings and answer day-to-day questions locally. This distributes security knowledge across the organization instead of concentrating it in one team that can’t scale with the number of engineers actually shipping code, echoing the same platform-team scaling problem covered in our enterprise SaaS guide.

How This Connects to the Rest of DevOps

DevSecOps isn’t a separate discipline from the rest of this curriculum, it’s the security layer applied across every other topic: scanning runs as steps inside the CI/CD pipeline, secrets management extends the practices from Git and GitHub and Ansible, and IAM least privilege extends directly from the AWS fundamentals. Treating security as a bolt-on afterthought rather than an integrated part of these existing workflows is exactly the pattern DevSecOps exists to fix.

Frequently Asked Questions

Starting Small Without Getting Overwhelmed

Teams new to DevSecOps often try to adopt every category of scanning covered above simultaneously, which tends to produce an overwhelming wave of findings that stalls the entire initiative before anyone fixes anything. A better sequence: add one scanning category at a time, starting with dependency and secrets scanning since they’re cheap and catch genuinely common issues, get the team comfortable triaging and fixing what it surfaces, then layer in SAST, container scanning, and infrastructure-as-code scanning over subsequent weeks rather than all at once.

This staged rollout also matters for team buy-in. Security tooling that blocks every pull request with dozens of unaddressed findings on day one earns resentment and workarounds (developers disabling checks to unblock themselves) rather than genuine adoption. Introducing checks gradually, starting in a non-blocking “report only” mode before making them required, gives the team time to build the triage habits DevSecOps actually depends on for long-term success.

Related reading: continue to Monitoring and observability, review our DevOps security best practices guide, or explore the compliance guide for regulated-industry specifics.