What does "make open source ecosystem secure one audit at time" mean? (version 2.0)

Curious about what keeps your favorite open-source projects secure? A security engineer pulls back the curtain on the world of code audits, vulnerability hunting, and making open source less "Oops!" and more "Awesome!".

We'll dive into:

* What really goes into a software audit.
* The thrill (and occasional horror) of vulnerability research.
* Why this matters to you, even if you don't write code.
* How we can all contribute to making open source safer.

Join me for war stories from the front lines and let's discuss how we can make the open-source ecosystem more secure, one audit at a time. For you, for me, for everyone!

Transcript

1. What does "make open source ecosystem secure one audit at time" mean? (for you and for me) Paolo Perego - thesp0nge@opensuse.org
2. $ whoami I find vulnerabilities in software for living Security Engineer @ SUSE && Open source enthusiast Almost thesp0nge everywhere on the Internet Wannabe 🏒 player | 󰔡 | Chaotic Neutral Eilistraee Cleric in Forgotten Realms
3. The common misconception • 86% of audited applications contained open-source vulnerabilities in the 2025 Synopsys Open Source Security and Risk Analysis (OSSRA) report. (Source: Synopsys OSSRA 2025, Black Duck blog) • 81% of these applications contained high- or critical-risk open-source vulnerabilities. (Source: Synopsys OSSRA 2025) • The 2024 OSSRA report found 84% of codebases (with risk assessments) contained at least one known open-source vulnerability, with 74% containing high-risk vulnerabilities. (Source: Synopsys OSSRA 2024 PDF) • A 2023 report by Lineaje stated that 82% of open-source software components are "inherently risky." (Source: OpenSSF.org)
4. The truth "The reality of OSS is that the majority of it is written and maintained by single contributors. The percentage of open source software that passes the qualifier of 'enough eyeballs' is miniscule." (Source: How is Open Source Software Security Managed in the Software Supply Chain? - Anchore - https://tinyurl.com/4k48u4ua ) Comprehensive security audits can be expensive and time-consuming. Many open-source projects, particularly those maintained by volunteers or small teams, may not have the financial resources to commission professional third-party security audits regularly. (Source: Technical Initiative Funding - Open Source Security Foundation - https://tinyurl.com/43mydhtm ) (Source: What is the role of funding in open-source development? - Milvus - https://tinyurl.com/mrcr7shz )
5. The truth… applied
6. So…
7. The challenge
8. The process • Choose a package • Understand the code and its context • Audit it • Follow a responsible disclosure process
9. Choosing wisely
10. Context is the king
11. Audit it
12. My audit routine…
13. My personal checklist • Authentication / Authorization layer • Secrets • Public APIs for the attack surface • Low hanging fruits (XSS, Sql injections, CSRF, …) • Analyze SAST tools output ◦ False positives ◦ Interesting area to explore
14. How I choose the package • Main security engineer for UYUNI project (https://github.com/uyuni-project) • Other stuff with web layer • Software I personally maintain • Free to decide
15. My personal and portable testing lab • KVM based setup • Master openSUSE Tumbleweed machine with keys and dotfiles. ◦ Updated every 6 months ◦ ssh access to work from command line ◦ Some tools installed (semgrep, dawnscanner, nightcrawler proxy, personal scripts) • Every application has its own testing machine cloned by the master
16. Tools • Open source tools • Some custom scripts I will release someday • AI • VIM ◦ Neovim + Lazyvim ◦ Most of the audit time is spent reviewing tools finding and exploring the actual source code
17. How do I take notes • Markdown based setup • Template document copied for every package I have to audit • Internal gitlab stored • Tracking ◦ Audit history ◦ Bugzilla items • Audit conclusions are also in the audit bugzilla ticket made public when activity is over
18. How do I report issues • Bugzilla as a point of contact with upstream • Responsible disclosure process • Vulnerability is under EMBARGO for a period agreed with upstream (no longer than 90 days) • After the fix is released, EMBARGO is lift • Disclosing the issue (oss security ml, blog post on security.opensuse.org, social media, …)
19. How do I report issues (cont.) • What to do if… ◦ Maintainer doesn’t answer to our emails ◦ EMBARGO expires with no fix • Let’s discuss…
20. Wrapping up (as a developer) • Your software security is your responsibility • Create a SECURITY.md file • Configure and activate dependabot on your repositories • Be open to security issues reported by researchers • Answer this talk “call to army”. Start doing security audit on open source projects do you love most
21. Wrapping up (as a security researcher) • Give back to the community • Do code audit • Open issues and pull requests • Write patches and have fun
22. Q & A
23. Thank you! paoloperego