Regulated and Sovereign : Impact to the Open Source Developer
summary
Open-source projects must start producing provable evidence: SBOMs and provenance, continuous CVE triage (example given: 16,582 reported, 16,581 not applicable), and multi-year maintenance commitments (Germany’s product liability precedent, EU Cyber Resilience Act implies ~4 years of patching). Regulators and banks push specs like NIST SP 800-53 and DORA with evacuation/continuity rules and heavy penalties; tooling stacks emerge—OSCAL profiles (JSON/XML), Trussle for conversion, and policy enforcement in clusters (cluster policy enforce TLS on ingress validation)—while cloud vendors already export OSCAL outputs.
AI-written summary · about
chapters (13)
- 0:00Regulation and open source intro
- 3:19Open source enablement expectations
- 7:28Understanding regulation formalization
- 11:02Regulation vs compliance vs security
- 17:25Regulation evolution and types
- 20:59DORA and open standards
- 23:27NIST 853 and OSCAL automation
- 30:37EU Cyber Resilience Act
- 32:47Digital Services Act and NIS2
- 34:10EU Solidarity Act impact
- 36:15License compliance and vulnerability management
- 38:42Key takeaways and open source role
- 39:48Q&A on EU regulations
related talks
34mCan Open Source be Secure by Design?
44mNavigating Open Source and Open Standards for Better Cybersecurity
18mThe Current State of Open Source Security Compliance Tooling Is … Well, Sad.
29mNavigating the Open Source Policy Labyrinth: Unraveling Global Policy Efforts for a Secure Future
36mOur dependency on Open Source is scary. SLSA, SBOM and Sigstore to the rescue
05mKeynote: Evolution of Open Source for Safe Usage in Critical Systems
16mOpen Source Consumption/ Adoption Manifesto
24mThe CRA Challenge: Can Open Source and IoT Stay Agile Under Regulation?