DevOps Security Basics

What is DevSecOps?

DevSecOps means building security checks into the normal development and delivery pipeline instead of running them as a separate review at the end. The same commit that triggers a build also triggers the scans, so problems surface while the code is still fresh in someone’s head.

The word gets used as if it were a product you can buy. It is not. It is a handful of extra pipeline stages plus a decision about which findings are allowed to fail a build.

Why is security important in DevOps?

Because the speed that makes DevOps valuable also multiplies mistakes. A team shipping twenty times a week and reviewing security once a quarter has roughly 250 unreviewed releases sitting in between those reviews. Automating the checks is the only way the review keeps pace with the delivery.

There is also a plain cost argument. A vulnerable dependency caught by a scanner during the build is a version bump. The same dependency found after a breach is an incident, a customer notification and a regulator conversation.

Where do security checks sit in a CI/CD pipeline?

Four main places, in the order a change moves through them:

• At commit — secret scanning and linting, so credentials never reach the remote in the first place
• During the build — static analysis on your own code, dependency scanning on everything you pulled in
• After the image is built — container image scanning, which catches vulnerable OS packages in the base image that have nothing to do with your code
• At and after deploy — configuration checks and runtime scanning against the live service

Most teams start with the middle two, because they are the easiest to add and they catch the most.

What tools are used in DevSecOps?

Group them by what they look at rather than memorising names:

• SonarQube — static analysis of your own source, plus code quality
• Snyk, OWASP Dependency-Check — third-party libraries with known vulnerable versions
• Trivy — container images and filesystems; the usual first scanner a team adds
• Gitleaks, TruffleHog — credentials committed to Git history
• OWASP ZAP — testing a running application from the outside

What is the difference between SAST, SCA and DAST?

SAST reads your own source code for insecure patterns. SCA looks at the third-party libraries you pulled in and flags known vulnerable versions. DAST attacks the running application from outside, the way a real attacker would.

They find different classes of problem, which is why teams run more than one. SAST will never notice that your TLS is misconfigured; DAST will never tell you that a utility function builds SQL by string concatenation.

What happens if a secret is committed to Git?

Deleting it in a later commit does not remove it. The old commit is still in the history, and anyone who cloned the repository already has a copy. Public repositories get scraped for exactly this within minutes.

So the order matters: treat the credential as compromised and rotate it first. Cleaning the history is worth doing afterwards, but it is not the fix, and doing only that is how teams end up with a live key they believe is dead.

Where DevSecOps usually goes wrong

The common failure is not having no scanners. It is having scanners nobody reads. A team switches on image scanning, the first run reports 180 findings across the base image, the build turns red, and within a week someone has added a flag to ignore everything.

Teams that make it work tend to fail the build only on high and critical findings in the parts they control, track the rest without blocking, and fix the base image once rather than arguing about it every build.

How much DevSecOps does a fresher need to know?

Enough to add a scanning step to a pipeline, read the report it produces, and explain the difference between a vulnerability in your code and one in a dependency. Nobody expects a fresher to run a security programme, but being unable to interpret a Trivy report does get noticed.

If you want the practice-level detail — policies, gating rules and what mature teams actually enforce — that is covered in DevOps security best practices. This page is the groundwork underneath it.