DevSecOps pipeline: security checks for every CI/CD stage.

Checks by pipeline stage

• Commit: secret scanning, so passwords and keys never reach the repository
• Build: dependency scanning for known vulnerabilities, and static analysis of your own code
• Container image: image scanning, minimal base images and image signing
• Infrastructure: scanning of infrastructure-as-code and Kubernetes manifests for risky settings
• Deploy: policy as code in the cluster, so only signed and compliant workloads are admitted
• Run: monitoring, alerting and a patching process for what is already in production

How to introduce it without blocking teams

Turning on every scanner as a hard gate on day one produces hundreds of findings and a team that learns to bypass the pipeline. Start in report-only mode. Fix the critical findings. Then block only on new critical issues, and tighten the threshold over time.

Every blocking rule needs an owner and an exception process with an expiry date. A rule nobody can explain will be worked around.

What to measure

• Time from a vulnerability being found to it being fixed
• Share of pipelines with security gates switched on
• Number of open critical findings, and their age
• How often gates are bypassed, and why

Common mistakes

• Scanning without anyone responsible for acting on the results
• Secrets stored in pipeline variables that every project can read
• Base images that are never rebuilt, so old vulnerabilities stay forever
• Security checks that take so long that developers skip them
• Treating a passed scan as proof that the system is secure

Where compliance fits

Standards such as ISO 27001 ask for evidence that changes are controlled and vulnerabilities are managed. A pipeline that enforces reviews, records every deployment and tracks findings produces that evidence as a side effect of normal work.