DevSecOps: How to Build Security into CI/CD

A model in which security comes at the very end - just before implementation, in the form of an audit that either blocks the release or is ignored - does not work. It’s too expensive, too slow and causes teams to split up. DevSecOps is a simple idea: move security to the left, weaving it into the daily software development pipeline so that vulnerabilities are detected automatically and early, when a fix costs minutes. Below is a practical picture of how to do this at the CI/CD level.

Rule: security as part of the pipeline, not a gateway at the end

Key thought change: security is not a separate stage that you “must go through”, but a set of automatic checks woven into the entire cycle - from commit, through build, to implementation. The developer receives information about the problem where he works (in a pull request), and not a week after implementation, in an e-mail from the auditor.

A well-designed DevSecOps pipeline has several layers of control, each cheap and fast, triggered at the right stage. Let’s go through them.

SCA: dependency vulnerabilities

The vast majority of code in a typical application is not your code, but dependencies - open source libraries and their transitive dependencies. This is the most common entry point for an attacker, as we show in the article about software supply chain attacks.

Software Composition Analysis (SCA) scans dependency manifests (package.json, requirements.txt, pom.xml) and compares versions with databases of known vulnerabilities. Practice:

• Run SCA on every pull request and cyclically on the main branch (new CVEs appear for code that has not changed).
• Generate SBOM (Software Bill of Materials) - a list of components, without which you will not be able to quickly answer the question “are we using a vulnerable version of X?”.
• Set thresholds: critical vulnerabilities block the merge, lower ones go to the backlog. Without thresholds, the team will be drowned in alerts.

Secrets scan: keys do not belong to the repository

A hardcoded API token, database password or private key in the history of Git is one of the most common and dangerous errors - once a secret is pushed out, it must be considered compromised, even after deletion, because the history of the repository remembers.

Weave the secret scan in two places:

1. Pre-commit hook - blocks the secret before it even reaches the repository (cheapest moment).
2. Pipeline CI - a safety net in case someone missed the hook, plus a scan of the entire history during implementation.

Secrets should live in a dedicated manager (vault) and be injected at runtime, not saved in the code or in variables visible in the logs.

SAST: analyzing your own code

Static Application Security Testing (SAST) analyzes source code for vulnerability patterns: SQL injections, XSS, unsafe deserialization, cryptography errors. It works without launching the application, so it fits into the early stages of the pipeline.

SAST can be noisy - it produces false positives. To avoid discouraging the team:

• Start with high confidence rules, gradually expand.
• Calibrate - mark false positives so that the tool learns.
• Integrate the results in a pull request, not in a separate dashboard that no one looks at.

DAST: test of a running application

Dynamic Application Security Testing (DAST) tests a running application from the outside as an attacker would - sending requests and observing responses. It catches what SAST doesn’t see: environment configuration errors, authentication problems, missing security headers.

DAST is slower, so it is usually run not on every commit, but in a staging environment - in a nightly build or before deployment. A light, passive version of such a check can be automated even with our configuration scanner ](/en/scan/), connecting it to the pipeline as a quick smoke test of headers, HTTPS and exposure.

Security for images and infrastructure as code

If you deploy containers, there are two layers:

• Image scan - the base image has its own dependencies and vulnerabilities. Scan images in the registry and build on minimal databases (distroless, alpine) to reduce the attack surface. More about hardening in Kubernetes and container security.
• IaC scanning - Terraform, Helm or Kubernetes manifests are also code that may contain errors: public bucket, too broad IAM permissions, lack of encryption. Scan infrastructure configuration just like application code.

Harden the pipeline itself

It’s easy to forget that the CI/CD pipeline is itself a target - it has access to code, secrets, and production environments. Hijacking the pipeline is often a simpler path to production than attacking the application itself. Basics:

• Minimum privilege policy for runners and tokens - separate, narrowly scoped credentials instead of one all-powerful key.
• Pinning versions of actions/plugins (pinning to a specific commit) so that an update from the supplier does not inject malicious code.
• Main branch protection: reviews required, commit signing, no pushing without review.
• Environment isolation - build should not have access to production secrets if it does not need them.

The key to success: don’t kill the momentum

The biggest threat to DevSecOps is not technical, but team frustration. If every commit is blocked by a hundred low-priority alerts, developers will learn to ignore them or bypass controls. Therefore:

• Calibrate thresholds - block only what is truly critical; report the rest without blocking.
• Give context, not just an alert - good integration shows where the problem is and how to fix it.
• Introduce layers gradually - first secret scan and SCA (high value, low noise), then SAST, then DAST and IaC.
• Measure and show the effect - a decrease in the number of vulnerabilities entering production is the best argument for maintaining the process.

Summary

DevSecOps is not about purchasing a tool, but about shifting security to the left and weaving automatic, low-cost controls into the entire development cycle. Sensible deployment order: secrets scan and SCA, then SAST, then images/IaC scan, then DAST - with thresholds chosen to protect the team’s pace. Automation captures what is repetitive; difficult, contextual vulnerabilities still require a human.

If you want to design a secure CI/CD pipeline or verify an existing one against real threats, contact . We support development teams as part of consultation and security advisory.

Frequently asked questions (FAQ)

Where to start implementing DevSecOps if we have nothing? From two things with the best value-to-effort ratio: secrets scanning (pre-commit + pipeline) and SCA on dependencies. They provide a large risk reduction with minimal noise and do not require changing the way the team works. Only add subsequent layers when these two work smoothly.

Does DevSecOps replace penetration testing? No. Automatic checks in CI/CD catch what is repeatable and known - vulnerable dependencies, patterns in the code, configuration errors. They won’t understand the business logic or string together a few small bugs into an attack chain. This is still a task for manual pentest, which complements, not replaces, automation.

Will pipeline security scanners slow down deployments? With a good configuration, no. Fast checks (secrets, SCA, light SAST) are run on each commit, and slower checks (full DAST, deep image scan) in the staging environment or in nightly builds. The key is to choose blocking thresholds only for really critical things.

What is SBOM and do we really need it? SBOM is a list of all software components and versions. Its value can be seen in a crisis: when a critical CVE is released in a popular library, with SBOM you can check in a minute whether and where you are using it. Without it, it’s hours of manual searching. It is also increasingly required by contractors and regulations.