Software Security
summary
Panelists argue that C++ remains powerful but not safe by default, and most real fixes are procedural: set up a security hotline, use continuous deployment and CI, run sanitizers and OSS‑Fuzz continuous fuzzing, and map dependency versions to vulnerability DBs. A concrete claim: about 75% memory‑safety bugs account for patched vulnerabilities at scale. Practical tools named include sanitizers, BinSkim, dependency scanners, CVE reporting, regression wrappers around third‑party libs, and hardware memory‑tagging as a promising defense.
AI-written summary · about
chapters (13)
- 0:00Introduction and panelist intros
- 2:07Interest in software security
- 4:36Is C++ a safe language?
- 10:53Fast response strategies for vulnerabilities
- 19:29Evaluating third-party library security
- 29:06Security concerns for games and desktop apps
- 31:11Language blame and component security
- 36:33PKI trust and aging security techniques
- 42:54Uninitialized memory and security defaults
- 45:43Github badges for security maturity
- 49:55Learning security-focused code reviews
- 55:12Vulnerability disclosure best practices
- 1:00:37CVE assignment and industry pressure
related talks
23mSecure Code, Safe Future: Mastering Security in Critical Software Development
01h 06mSecurity Beyond Memory Safety - Using Modern C++ to Avoid Vulnerabilities by Design
01h 26mVulnerable C++
14mEmbedded C and C++: A Security Perspective
50mSecure development with C++ - Lessons and techniques
49mPragmatic Approaches To Building Secure Software
43mC++ and Security: Can We Do Better?
01h 35mSafety and Security for C++: Panel Discussion