DevSecOps

DevSecOps is the practice of building security checks into every step of making and shipping software, rather than bolting a security review on at the end. Done well, it means you ship just as often, with far fewer nasty surprises on release day.

What DevSecOps means

DevOps brought development and operations together, so the people who write code and the people who run it share one pipeline and one goal: ship small changes often and safely. DevSecOps adds security to that partnership. Developers, security specialists and operations engineers all own security, and the checks they rely on run automatically, wherever the work happens.

The key word is 'every'. Security isn't a gate at the end of the process that a separate team guards. It is a set of small, automated checks spread across writing code, committing it, building it and deploying it. Each one is quick and focused, and each one catches a different kind of mistake.

Why security can't be the last step

In a traditional setup, code is written, tested and packaged, and only then handed to a security team for a review or a penetration test. That model has three problems.

• Late findings are expensive. A leaked password found weeks after it was committed has to be rotated, every copy of the repository is suspect, and the fix competes with a release deadline.
• Reviews become bottlenecks. When one team must sign off on everything, releases queue up behind it, and people start looking for ways around the review.
• Context is lost. By the time a finding arrives, the developer has moved on. Fixing a problem in code you wrote an hour ago is far easier than in code you wrote last month.

Moving checks earlier is often called shifting left, because if you draw the delivery process as a line from 'write code' on the left to 'running in production' on the right, the checks move towards the left-hand end.

Where the checks run

A DevSecOps pipeline layers several kinds of check, each at the point where it is cheapest to run.

While you write code

Editor plugins and pre-commit hooks run on your own machine. They are the fastest feedback there is: a secret scanner can stop you committing an API key before it ever leaves your laptop. Local hooks can be skipped, though, so they are a convenience, not the final safety net.

When you commit or open a pull request

This is where most of the automated work happens, in your continuous integration (CI) pipeline:

• Secret scanning looks for passwords, API keys, tokens and private keys in the code and its history.
• Dependency scanning (often called software composition analysis) compares the libraries you use against databases of known vulnerabilities, and flags outdated packages with published security fixes.
• Static analysis (SAST) reads your source code for risky patterns, such as building a SQL query by joining strings with user input.
• Configuration scanning checks infrastructure-as-code files, Dockerfiles and deployment settings for weak defaults: a storage bucket open to the public, a database port exposed to the internet, a container running as root.

A failing check blocks the merge, so problems are fixed while the change is still small and fresh.

When you build and deploy

The built artefact gets its own checks. A container image scan looks at every package inside the image, not just the ones you added, which is one reason small base images such as distroless images make scanning quieter and safer. Some teams also run dynamic testing (DAST) against a staging environment, probing the running application the way an attacker would.

Once it is running

Security doesn't stop at release. New vulnerabilities are published every day in libraries you shipped months ago, so good tools keep rescanning and alert you when something you already run becomes a risk. Operations teams feed what they see in production, such as suspicious traffic or failed logins, back into the next round of development.

A worked example

Imagine a small team building a Node.js web shop. A developer adds a payment feature and, while testing, pastes a real API key into a config file. They also add a new package that pulls in an old version of a library with a known vulnerability.

Here is what their pipeline does with it:

1. The pre-commit hook would have caught the key, but the developer skipped it to save time.
2. They open a pull request. The CI job's secret scan finds the key and fails the build, naming the file and line.
3. The dependency scan fails too, listing the vulnerable library, the version that fixes it and how severe the issue is.
4. The developer removes the key, rotates it with the payment provider (it is in the Git history now, so it must be treated as leaked), and updates the package.
5. The checks pass, a teammate reviews the change, and it merges. No one outside the team was involved, and the release goes out on schedule.

A minimal version of those checks can be a script that CI runs on every pull request. This one assumes the tools are already installed:

#!/usr/bin/env bash
set -euo pipefail
 
# Secrets committed by mistake
gitleaks detect --source . --no-banner
 
# Dependencies with known vulnerabilities
npm audit --audit-level=high
 
# Risky settings in config and IaC files
trivy config --exit-code 1 \
  --severity HIGH,CRITICAL .

And the CI job that runs it on each push, here in GitHub Actions:

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # full history
      - run: ./scripts/security-checks.sh

The full history matters for secret scanning: a key deleted in a later commit is still in the repository, and still leaked. Platforms such as Aikido, the tool named in the video, bundle these kinds of scans together and run them in the background, so you get one list of findings instead of wiring up each scanner yourself.

Common mistakes

• Turning everything on at once. A pipeline that fails on hundreds of low-severity findings on day one teaches everyone to ignore it. Start by blocking only high and critical issues, then tighten the rules as the backlog shrinks.
• Treating a green pipeline as 'secure'. Scanners find known patterns and known vulnerabilities. They don't understand your business logic, so threat modelling, code review and the occasional penetration test still matter.
• Deleting a leaked secret and moving on. Once a secret is committed, assume it has been seen. Rotate it first, then clean up.
• Leaving security to the security team. If only one team cares about the findings, they pile up. DevSecOps works when the developer who opened the pull request fixes the issue it raised.
• Ignoring the pipeline itself. Your CI system holds deployment keys and can push to production, so its own permissions, secrets and third-party actions need the same care as your application.

When to go further

For a side project, a secret scanner and automatic dependency alerts cover most of the risk for very little effort. As a team or product grows, add static analysis, configuration and container scanning, and clear rules about which severity levels block a merge. Regulated industries usually add formal reviews and audit trails on top, but the principle stays the same: find problems where they are cheapest to fix.

Key takeaways

• DevSecOps makes security part of every step of development and operations, not a final gate.
• Automated checks for secrets, dependencies and configuration run as you code, commit and deploy.
• Catching a leaked password or an outdated library early is far cheaper than finding it after release.
• A leaked secret must be rotated, not just deleted from the code.
• Scanners catch known problems; people and code review are still needed for the rest.