Secure Open Source Practices
summary
Open source is not automatically safer: Log4j exposes remote code execution (9.8–10) and projects like it show why to check the CVE list (example: 19 CVEs for one package), inspect update frequency and popularity, and treat nested dependencies as attack surface. Use software composition analysis tools (Snyk, Sonatype/Nexus, WhiteSource/Black Duck, Veracode, Checkmarx) or free options (GitHub alerts, npm audit, Safe Log4j), have an emergency patch plan and accept that updates aren't optional.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 1:43Open Source Code
- 4:50Open Source Library
- 11:07Nested dependencies
- 11:53Updates
- 15:35Tools
- 20:10Licensing
- 20:52QA
related talks
37mIt’s Not Open Source, It’s You. Where Open Source Risk Comes From
24mHow to Find Secure Software in Open Source Repositories
18mIT Security – Don’t let Open Source Software become the next menace
25mOWASP Top 10 Risks for Open Source Software
35mOpen source security: Opportunity or oxymoron?
40mSecure Your Code from Open Source Vulnerabilities
30mDevSecOps: Understanding Open Source Software risk in your applications
33mLog4J, SpringShell and all that Jazz (or why bad things can happen to good software)