Zero Day Bugs and the Business Risk of a Long Deploy Cycle
summary
A nine‑year old log4j bug (string interpolation + JNDI) lets an attacker fetch and run remote code; fixing required upgrading to 2.15. Teams with dependabot auto-merge and CI/CD roll a safe patch in ~3 minutes, a one‑month release cadence takes about half a day to patch, chasing transitive upgrades (struts) costs ~a week, and a core service with 13 months without deploy spends ~a month blocking traffic to survive by implementing block outbound calls. Months later ~30% still vulnerable.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:03Programming assumptions
- 2:28Log4j bug from 2013
- 11:47Patch time for critical vuln
- 12:31Team one: Auto zero-day fix
- 17:05Team two: Manual one-month sprints
- 22:03Team three: Dependency upgrades
- 28:02Team four: 13 months no deploy
- 34:26Redeploying vs zero-day bugs
- 36:11Old servers liability
- 38:23Actionable risk reduction
related talks
40mEmbracing Security - A Changing DevOps Landscape
46mThe Supply Chain Conundrum: Why Traditional Application Security Is...
39mCVE 101: The Unfolding Of A Zero Day Attack
32mBuilding a secure future using DEVSECOPS practices and technologies
50mStranger Danger: Your Java Attack Surface Just Got Bigger
56mZero Days, Thousands of Nights: The Life & Times of Zero-Day Vulns and Their Exploits
39mWe Are All Equifax: The Data Behind DevSecOps
33mWhy have we not fixed all the vulnerabilities yet? Different perspectives...