Security response for open source ecosystems Fraser Tweedale @hackuador[@functional.cafe] 2025-03-22

CC-BY-NC 2.5 https://xkcd.com/2347/

Why open source security matters ▶ supply chain security ▶ ISO 27001 de-risking ▶ NIST SP 800-218 (SSDF) 1 + EO 14028 (procurement) 2 ▶ EU Cyber Resilience Act 3 4 1https://csrc.nist.gov/pubs/sp/800/218/final 2https://www.nist.gov/system/files/documents/2022/02/04/software-supply-chain-security-guidance-under-EO-14028-section-4e.pdf 3https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847&qid=1732732976975#art_24 4https://github.blog/open-source/maintainers/what-the-eus-new-software-legislation-means-for-developers/

Why open source security matters Open-source software stewards shall put in place. . . a cybersecurity policy to foster. . . effective handling of vulnerabilities. . . also foster the voluntary reporting of vulnerabilities. . . promote the sharing of information concerning discovered vulnerabilities — Cyber Resilience Act, Article 24 Obligations of open-source software stewards

Why open source security matters Supply chain security has always been important. But market participants and open source organisations care more now (because they’ve been forced to). Therefore, open source projects and ecosystems that lack an effective security apparatus will be left behind.

Who needs a security response apparatus? ▶ operating systems ▶ programming languages + library ecosystems ▶ frameworks ▶ applications + network servers ▶ other large projects

Haskell Security Response Team (SRT) ▶ Haskell Foundation tech proposal 5 ▶ Fraser was asked to recruit and lead the team 5https://github.com/haskellfoundation/tech-proposals/blob/main/proposals/accepted/037-advisory-db.md

How to build a security response team

Building a team - skills ▶ technical skills / knowledge of the language / project ▶ security know-how: AppSec, IR, GRC, pen testing, IAM, vuln research, . . . ▶ programming ability (for tool development) ▶ good communication skills

Building a team - how many? ▶ enough to cover the skills you want / need ▶ enough to tolerate absences ▶ not all the qualified people all at once ▶ diversity is good! ▶ Haskell: 5 → 6 people

Defining the scope of work ▶ triage security reports ▶ analyse reports and propose action ▶ coordinate with maintainers and stakeholders ▶ publish advisories ▶ oversee project infrastructure security ▶ developer tooling ▶ reports, guides, documentation, . . . You can’t do everything. Choose a scope and review it regularly.

Building a team - call for volunteers ▶ preamble ▶ team responsibilities ▶ desired skills / experience ▶ how to apply ▶ Haskell SRT example6 (feel free to copy!) 6https://github.com/haskell/security-advisories/blob/main/docs/call-for-volunteers-example.md

Processes and communication ▶ reporting and disclosure processes ▶ team chat / mailing list (private!) ▶ meetings (Haskell: every 2 weeks) ▶ activity reports (Haskell: quarterly) ▶ community engagement (conferences, discussions, office hours)

Security advisories and tooling

Advisory naming ▶ some ecosystems/projects use own namespace (e.g. HSEC-YYYY-NNNN) ▶ some are a CVE Numbering Authority (CNA) 7 ▶ suppress bogus CVEs 8 ▶ produce higher-quality CVE records ▶ some use existing CNAs 7https://github.com/ossf/wg-vulnerability-disclosures/blob/main/docs/guides/becoming-a-cna-as-an-open-source-org-or-project.md 8https://lwn.net/Articles/961978/

Advisory content ▶ description (give detail!) ▶ affected packages and versions ▶ CVSS, CWE ▶ aliases and related IDs ▶ references (reports, PoC, commits, . . . )

‘‘‘toml [advisory] id = "HSEC-2023-0001" cwe = [328, 400] keywords = ["json", "dos", "historical"] aliases = ["CVE-2022-3433"] [[affected]] package = "aeson" cvss = "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H" [[affected.versions]] introduced = "0.4.0.0" fixed = "2.0.1.0" ‘‘‘ # Hash flooding vulnerability in aeson *aeson* was vulnerable to hash flooding (a.k.a. hash DoS). The issue is a consequence of the HashMap implementation from *unordered-containers*. It results in a denial of service through CPU consumption. This technique has been used in real-world attacks against a variety of languages, libraries and frameworks over the years.

Advisory database - outputs ▶ OSV (ingested by osv.dev9) ▶ HTML index10 ▶ "snapshot" format (for downstream tooling) 9https://osv.dev/list?ecosystem=Hackage 10https://haskell.github.io/security-advisories/

osv.dev ▶ https://osv.dev/ ▶ aggregates many advisory databases ▶ JSON schema11 ▶ to integrate your advisories: ▶ publish your osv json somewhere ▶ ask osv.dev to ingest it (GitHub issue) ▶ they might need a bit of info or help 11https://github.com/ossf/osv-schema

Package repositories ▶ e.g. PyPI, npm, Maven, . . . ▶ integrate advisory info in package pages ▶ link to advisories ▶ reporting mechanism / info

Audit tooling ▶ check build plans or lock files for vulnerable dependencies ▶ call analysis (advanced; not always feasible) ▶ osv-scanner12 is a good starting point 12https://google.github.io/osv-scanner/

Exploitability information ▶ suppress false positives ▶ VEX - Vulnerability Exploitability eXchange13 ▶ statements that dependency issue is(n’t) exploitable ▶ data model by CISA.gov, several implementations ▶ produce, collect, distribute ▶ advisory DB as a VEX clearing-house? 13https://www.cisa.gov/resources-tools/resources/minimum-requirements-vulnerability-exploitability-exchange-vex

Advisory data in aggregate ▶ what kinds of issues commonly arise in your ecosystem? ▶ improve developer practices ▶ improve detection mechanisms ▶ identify problematic packages / authors / abandonware ▶ make tribal knowledge explicit ▶ can policy or technical controls help? (nuance!) ▶ corollary: historical advisories are important

Embargoed advisories ▶ what threshold for embargo? (you decide) ▶ notifying downstream redistributors (e.g. Linux distros) ▶ multi-ecosystem vulnerabilities ▶ Vulnerability Information and Coordination Environment (VINCE)14 ▶ enable secure reporting and cross-vendor collab ▶ register your project / ecosystem! 14https://kb.cert.org/vince/

Bug bounties and audits ▶ if you can fund them, great ▶ fund security response capacity first!

Sustainability

A not good scenario ▶ critical issue disclosed ▶ requires significant effort and coordination ▶ everyone is busy with their day job and life ▶ issue remains unfixed. . .

Bottom line Open source ecosystems need personnel with capacity and authority to respond immediately to security incidents.

Things that don’t work ▶ empty words of support ▶ burying your head in the sand ▶ a few thousand dollaridoos here and there ▶ thoughts and prayers

Models I have observed ▶ company employees doing security work (full- or part-time) ▶ foundation-funded security officer role ▶ foundation-funded ad-hoc projects (e.g. audits, tooling) ▶ grants for bounties or ad-hoc projects (e.g. EU-FOSSA15, GitHub16, Sovereign Tech Fund17) ▶ all-volunteer effort (← Haskell is here) 15https://commission.europa.eu/about/departments-and-executive-agencies/digital-services/eu-fossa-2-free-and-open-source-software- auditing_en 16GitHub Secure Open Source Fund: https://resources.github.com/github-secure-open-source-fund/ 17https://nkcs.bund.de/en/news/renewed-general-financing-sovereign-tech-fund

Things that might work? ▶ volunteer team with paid lead (awkard?) ▶ paid worker with diverse assignments including IR (which has priority)

How to get money ▶ grants ▶ foundation funding ▶ big enough for a foundation → fund security work ▶ subscription program ▶ commercial users directly fund security work; in return you get. . . ▶ a heads-up on active issues ▶ a say in priorities, tooling ▶ access to team for advice/consulting

Moral obligations of F/OSS users We estimate the supply-side value of widely-used OSS is $4.15 billion, but that the demand-side value is much larger at $8.8 trillion. We find that firms would need to spend 3.5 times more on software than they currently do if OSS did not exist. — The Value of Open Source Software, Harvard Business School 202418 18https://www.hbs.edu/faculty/Pages/item.aspx?num=65230

Moral obligations of F/OSS users If you depend on F/OSS ecosystems, you SHOULD contribute to the security of those ecosystems. If you are impacted by security issues in F/OSS ecosystems, but did not contribute to the security of those ecosystems, you SHALL NOT complain. If you are the government, funding F/OSS security work through grants is RECOMMENDED.

Moral obligations of F/OSS authors Reasonable effort not to deliver insecure code, and reasonable effort to fix discovered issues. What is reasonable depends on the level of financial or in-kind support the developers receive in respect of the affected component.

Conclusion

What we discussed ▶ why open source security response matters ▶ how to bootstrap and run a security team ▶ advisories and related tooling ▶ sustainability and funding

Thank you This slide deck: © 2025 Fraser Tweedale Except where otherwise noted this work is licensed under http://creativecommons.org/licenses/by/4.0/ Socials @hackuador[@functional.cafe] Haskell SRT https://www.haskell.org/security/