Security and Compliance in DevOps (DevSecOps)
What this domain tests
Security and Compliance in DevOps tests shift-left security, automated controls, supply-chain integrity, and compliance as code across the pipeline.
Core rules and concepts
- Shift left means integrating security checks into design, code review, build, and deploy, not adding a security gate at the end.
- SAST analyzes source for insecure patterns; DAST tests a running application; SCA checks dependencies for known vulnerabilities. Each has blind spots, so combine them.
- Secret scanning in commits and CI prevents credential leakage; a found secret must be rotated, not just deleted.
- Generate an SBOM such as SPDX or CycloneDX, pin dependencies, and scan container images after every rebuild, including base-image updates.
- Sign artifacts and images, for example with Sigstore cosign, and verify signatures at admission to reduce supply-chain risk.
- Policy as code, such as OPA Gatekeeper or admission policies, enforces rules like "no privileged containers" consistently.
- Compliance as code turns controls into automated evidence rather than annual screenshots.
Worked example
A critical CVE appears in the base image used by 40 services. Reasoning: patching running containers manually creates drift and is not repeatable. Rebuild each image from an updated base, run SCA and image scanning, redeploy through the normal pipeline, and verify the new digest. If a service cannot rebuild, record an exception with an owner and expiry. Rotating credentials is separate and still required if the CVE is exploitable.
Traps that cost marks
- Treating a one-time penetration test as continuous security.
- Ignoring transitive dependencies because direct ones are clean.
- Putting secrets in environment variables committed to manifests.
- Blocking every build on every low-severity finding, which trains teams to bypass controls.
- Scanning an image once and never rescanning after new advisories.