Planning for Retirement: How Can We Prepare for Software’s...
summary
Argues that the real step is shared definitions (proposes support = predictable effective response to a new security risk), then machine-readable transparency using existing formats (SBOM, VEX, CSAF) and a lightweight OASIS OpenEoX schema that can stand alone or integrate. Notes open-source complexity — maintainer churn, last-commit dates not scalable — cites endoflife.date cataloging ~340 products and a $1.5 trillion loss estimate, and says federated data, not one central DB, is the practical path.
AI-written summary · about
chapters (8)
- 0:00End-of-life software challenges
- 13:13End-of-life terms
- 17:09Open source lifecycle
- 21:45Open source security
- 28:12Open EoX initiative
- 32:53Data models for EoX
- 34:57Software identity in EoX
- 37:26Conclusion
related talks
41mPlanning for Retirement: How Can We Prepare for Software’s...
51mAll Good Things: End of Life and End of Support in Policy and Practice
44mNavigating Open Source and Open Standards for Better Cybersecurity
25mYour Software Supply Chain is Only as Secure as its Weakest Link
51mThe Opposite of Transparency
24mThe CRA Challenge: Can Open Source and IoT Stay Agile Under Regulation?
14mKeynote: The Next Steps in Software Supply Chain Security
48mCRA, NIS2, DORA: What Senior Java Engineers Must Deliver Before 2027