Home / Cloud and DevOps / DevSecOps
DevSecOps
Intermediate
v1.2.0
Build security into the pipeline instead of bolting it on.
DevSecOps integrates security practice into the DevOps process. It puts shared responsibility for security across the whole software lifecycle, from design through integration, testing, deployment and delivery. This map walks the foundations first, then the tooling and the practices that make it work in a real pipeline.
Your progress
0 / 29 topics
0 %
Saved in this browser. Clearing site data will reset it.
Topics in this roadmap
The interactive map needs JavaScript. Here is the full list.
Firewalls
A firewall decides which packets are allowed through, based on rules. Understand the difference between a stateless packet filter, a stateful firewall that tracks connections, and a web application firewall that inspects HTTP.
A WAF is useful. It is not a substitute for fixing the application behind it.
OWASP Web Application Firewall
VLANs
Virtual LANs split one physical network into separate broadcast domains. Segmentation limits how far an attacker can move after gaining a foothold.
ACLs
Access control lists filter traffic at a network device. Useful as a coarse boundary, easy to get subtly wrong, and worth reviewing whenever a rule is added.
DNS
Name resolution underpins almost everything. Learn the resolution path, record types, and why DNS is both an availability dependency and a useful signal during an investigation.
How DNS works, illustrated
HTTP
Request and response structure, methods, status codes, headers and cookies. Almost every application vulnerability shows up here first, so being able to read a raw exchange matters.
MDN HTTP reference
TLS
How a secure channel is negotiated, what a certificate chain proves, and what it does not. Know how to read a certificate and how to spot a broken trust chain.
How HTTPS works, illustrated
PowerShell
The equivalent on Windows estates, and object based rather than text based, which changes how you chain commands.
Vim, Nano or Emacs
You will end up on a machine with no graphical editor. Knowing enough of one terminal editor to open a config, change a line and save it is a small skill with a large payoff.
Go
Compiles to a single static binary, which makes it a favourite for CLI tools and agents that have to run anywhere.
A Tour of Go
Rust
Memory safety enforced at compile time. A steeper start, but it removes a whole class of vulnerability by construction.
JavaScript
Unavoidable if you touch anything in the browser, and increasingly present on the server through Node.
SAST
Static application security testing reads the source without running it. Fast, runs on every commit, and catches whole categories of bug early.
It is also noisy. Budget time for tuning the ruleset, and treat an unreviewed backlog of findings as worse than no scanner at all.
Semgrep
OWASP source code analysis tools
DAST
Dynamic testing attacks a running application from the outside. It finds problems that only exist at runtime, such as misconfiguration and authentication flaws.
Slower than SAST and needs a deployed environment, so it usually runs against staging rather than on every commit.
OWASP ZAP
Dependency Scanning
Software composition analysis inventories your dependencies and flags known vulnerable versions.
The hard part is not finding them. It is deciding which ones are actually reachable in your code, so the team does not learn to ignore the report.
OWASP Dependency-Check
Trivy
Secret Scanning
Catches credentials committed to the repository. Run it as a pre-commit hook and again in CI, because the hook can be skipped.
When a secret does leak, rotate it. Deleting the commit does not help, it is already in someone's clone.
Gitleaks
TruffleHog
Introduction
DevSecOps is an approach to software development that integrates security practices within the DevOps process. It emphasises shared responsibility for security throughout the entire software lifecycle, from initial design to integration, testing, deployment and delivery.
The goal is to build security into the development pipeline rather than adding it as an afterthought, which enables faster and more secure software releases.
Why it matters
In a traditional model security reviews happen at the end, when changing anything is expensive. By then the architecture is fixed, the deadline is close, and findings get deferred. Moving those checks left, into the pipeline itself, turns security into something that runs on every commit instead of once a quarter.
What changes in practice
Security tests run in CI, alongside unit tests Developers see findings in the pull request, not in a PDF weeks later Infrastructure is described in code, so it can be reviewed and scanned Secrets live in a secret manager, never in the repository DevSecOps explained
What is DevSecOps
OWASP DevSecOps Guideline
DevSecOps vs DevOps
DevOps is about the speed and reliability of delivery. DevSecOps keeps those goals and adds a third: that what you deliver is defensible.
DevOps DevSecOps Primary goal Fast, reliable delivery Fast, reliable, secure delivery Security testing A separate gate, often late Inside the pipeline, on every commit Who owns security A security team Everyone who touches the pipeline Failure mode Ship a bug Ship a vulnerability
The practical difference is when security work happens, not whether it happens.
DevOps vs DevSecOps
Learn a Programming Language
You cannot secure a pipeline you cannot read. Pick one language and get properly comfortable before spreading yourself across several.
Any of the common choices work. What matters is that you can read someone else's code, write a small tool, and understand what a dependency is actually doing.
What to aim for
Read an unfamiliar codebase and follow the control flow Write a script that talks to an HTTP API and handles errors Understand how packages are resolved and installed Know how your language handles user input, encoding and serialisation, because that is where most bugs live
Scripting Knowledge
Most pipeline work is glue. A job fails, you need to read a log, transform some output and feed it into the next step. That is scripting.
Core skills
Shell fundamentals: pipes, redirection, exit codes, set -euo pipefail Text processing with grep, sed, awk and jq Writing a script that is safe to re-run Knowing when a shell script has outgrown itself and should become a program
CIA Triad
Confidentiality, integrity and availability. Three words that give you a vocabulary for describing what a control protects and what an attack costs.
Confidentiality keeps information away from those who should not have it. Encryption, access control, data classification.Integrity keeps information correct and unaltered. Hashing, signing, change control, audit logs.Availability keeps the system usable. Redundancy, capacity planning, DDoS protection, backups.Most real trade-offs are between these three. Locking a system down harder usually costs availability. Getting comfortable naming that trade-off out loud is most of the value.
The CIA triad explained
Authentication
Authentication answers one question: who is this?
What to understand
Password storage: why bcrypt, scrypt or Argon2, and never a plain hash Multi factor authentication, and why TOTP beats SMS Session management: how a session is created, transported and destroyed Token based auth: JWT, what it does and does not guarantee Single sign on with OAuth 2.0 and OIDC, and the difference between the two Authentication tells you who someone is. It says nothing about what they are allowed to do. That is the next box.
OWASP Authentication Cheat Sheet
OWASP Password Storage Cheat Sheet
Authorization
Authorization answers the second question: is this person allowed to do this, to this specific object?
Models worth knowing
Role based access control, the common default Attribute based access control, when roles stop scaling Least privilege as a habit rather than a policy document The bug to internalise
Broken object level authorization. The application checks that you are logged in, then trusts an ID from the request without checking that the object belongs to you. It is the single most common serious flaw in modern APIs, and no scanner finds it reliably.
OWASP Authorization Cheat Sheet
API1:2023 Broken Object Level Authorization
Cryptography Basics
You do not need to implement cryptography. You need to know which primitive fits which job, and to recognise misuse in review.
Job Use Do not use Store a password Argon2, bcrypt SHA-256, MD5 Verify a file has not changed SHA-256 MD5, SHA-1 Encrypt data at rest AES-GCM AES-ECB Prove a message came from you HMAC, digital signature Plain hash
The rules
Never write your own primitive Never reuse a nonce or IV Compare secrets with a constant time function Rotate keys, and know where they live before you need to OWASP Cryptographic Storage Cheat Sheet
Crypto 101
CI/CD Security
Your pipeline can deploy to production. That makes it one of the most valuable targets in the organisation, and it is often the least defended.
What to lock down
Secrets: use a secret manager, scope tokens tightly, rotate them Runners: isolate them, do not let untrusted pull requests run privileged jobs Dependencies: pin versions and verify checksums Artifacts: sign what you build so you can prove what you deployed Permissions: a build job rarely needs write access to everything If an attacker owns your CI, they do not need to attack production. The pipeline will deploy their code for them.
OWASP Top 10 CI/CD Security Risks
SLSA supply chain framework
Container Security
Containers are a packaging and isolation mechanism, not a security boundary by default.
Where to focus
Base images: small, current, from a source you trust Run as a non root user, and drop capabilities you do not need Scan images in the pipeline, and again in the registry over time, because new CVEs land after you build Never bake secrets into a layer, they persist in the image history Understand what namespaces and cgroups actually isolate, and what they do not Docker security documentation
CIS Docker Benchmark
Infrastructure as Code Security
When infrastructure is code, misconfiguration becomes a code review problem, which is a large improvement.
Scan Terraform, CloudFormation or Kubernetes manifests before they apply Keep state files private, they often contain secrets Use modules so a hardened pattern is reused rather than retyped Review the plan output, not just the source Checkov
tfsec
Monitoring and Logging
You cannot respond to what you cannot see. Logging is the difference between an incident you can reconstruct and one you can only guess at.
Practical minimum
Centralise logs, and make sure they survive the host that produced them Log authentication events, authorisation failures and configuration changes Never log secrets, tokens or full request bodies without redaction Set retention deliberately, and know what your regulator expects Alert on a small number of high quality signals rather than everything OWASP Logging Cheat Sheet
