Shifting Open Source Compliance Activities Left
summary
Argues that moving compliance work into early development reduces last‑minute delays and shows exactly what to start: build an inventory and continuous SBOMs, run dependency scans (expect low tool fidelity—about 30% accuracy off the initial pass), standardize inputs/outputs, and automate routine license checks so analysts handle only edge cases. Emphasizes concrete responsibilities for OSPO/legal versus development teams, risk‑tolerance framing, and that tooling plus human review together actually works.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 1:12Why shifting left matters
- 3:01Key stakeholders
- 5:28Open Source Program Office
- 7:56Developer responsibilities
- 10:21Sustaining compliance
- 12:27Risk versus business
- 13:51Final advice & Q&A
related talks
25mOpen Source Compliance
52mRisk management: best practices for people with legal compliance to ship open source
28mGoverning Open Source in the Enterprise: OSPO Strategies for Innovation and Compliance
40mThree Cs to an Open Source Program Office
21mScaling Internal Collaboration with Open Source Operating Models
31mOperationalizing Open Source Projects: When the Rubber Meets the Road
29mOpen Source and IP Departments: Risk Containment and Portfolio Management
18mExploration of Compliance Governance Based on Operating Systems