Implement ZeroTrust with Dedicated DevSecOps Pipeline
summary
Argues that a single CI/CD pipeline with SAST/DAST/SCA becomes an anti-pattern at scale and recommends a separate shadow DevSecOps pipeline plus a dedicated security team that owns security-as-code and policy-as-code. Cites tooling that avoids DIY errors (Buildpacks, Red Hat S2, Jib), alarming data points (99% of Helm charts have insecure config, 91% of public images show critical/high vulns, ~77 CVEs disclosed daily in 2023), and operational fixes: store SBOM+VEX, use EPSS/KEV for prioritization, and prefer a pull model to remove developer production access.
AI-written summary · about
chapters (8)
- 0:00Introduction and context
- 10:54DIY effect in DevSecOps
- 20:15CVE vs CWE and shift left risks
- 27:49Security-as-code vs policy-as-code
- 32:55Zero Trust Maturity Model 2.0
- 38:06Reducing false positives with VEX and EPSS
- 41:04Pull model for Zero Trust deployment
- 43:12Key takeaways and Q&A
related talks
25mDecoupling DevSecOps from CI/CD Pipelines
36mUnderstanding the Sec in DevSecOps: Beyond Just Shifting Left
43mThe art of secure software: Zero-trust delivery pipelines
30mHandling Security Objections to DevOps
31mDevOps: You Build It, You Secure It
31mWhy SecDevOps is the new way in Cybersecurity?
39mSecurity Tooling in Your DevOps Pipeline
23mTrue DevSecOps with People, Processes, and Technologies