Explosive overflow: Lessons from rocket science
summary
A concrete failure narrative: the 1996 inaugural flight of the Ariane 5 self‑destructs Thirty nine seconds after launch because an integer overflow in a reused inertial reference module causes the redundant inertial reference unit to fail in lockstep and the flight computer to command a 90° tilt. Static analysis had flagged issues but three risky assumptions remain; formal verification of a small TLS component takes months of focused work, showing the practical cost of proving correctness.
AI-written summary · about
chapters (17)
- 0:00Rocket science and software security
- 1:44Bug finding to secure systems
- 3:54Security engineering beyond static analysis
- 6:01Formal verification limits
- 7:49Memory safe languages and White House recommendations
- 8:11Ariane 5 rocket explosion 1996
- 10:37Integer overflow in rocket software
- 12:28Why Ada couldn't prevent disaster
- 13:30Redundancy and error handling failure
- 15:36Static analysis limitations
- 17:20Bug constraints and assumptions
- 18:49Testing gaps and design flaws
- 20:55Postmortem lessons and corrections
- 22:00Software correctness and halting problem
- 23:24Root causes and lessons learned
- 25:32Design assumptions vs tools
- 26:14Language wars and enterprise reality
related talks
22mFailure is not an option...
40mHouston, We Have a Problem: Analyzing the Security of Low Earth Orbit Satellites
42mCode as Risk
32mEscalating complexity: DevOps learnings from Air France 447
21mThe Butterfly Effect
16mTaking Flight – 3 Experts Discuss Aerospace Cybersecurity
20mSolidity's most common security pitfalls and its best safeguards
40mThe History Of Fire Escapes: How To Fail (Keynote)