How Do You Know You're Done - After a Security Fix?
summary
Claim: extending SBOMs across the lifecycle plus SPDX relationships and build metadata lets teams automate impact analysis and prove a security patch hasn’t broken safety requirements. Uses: SPDX SBOMs, build SBOMs (Zephyr/Yocto build metadata and CI/CD outputs), and test harness logs as evidence. Concrete results: about 70% of codebases include open source so scale matters; automated traceability from requirement → source → build → test lets a deployer retest changed modules, regenerate evidence, and assert “done” or identify required architecture/requirement changes.
AI-written summary · about
chapters (7)
- 0:00Start
- 3:45Requirements Quality
- 8:22Requirements Validation
- 11:06System Analysis
- 14:14Architecture Verification
- 17:07Impact Analysis
- 29:38Requirement to Code to Tests to Evidence Traceability
related talks
30mContinuous Compliance in Open Source: Safety Assurance Through S...
29mMaking Software Bill of Materials (SBOMs) Actionable
42mPractical SBOM Management with Zephyr and SPDX
51mThe Opposite of Transparency
27mSBOM: The Rest Of the Story
26mApplication of the Upcoming SPDX Safety Profile
40mStrengthening Software Supply Chains: Harmonizing SLSA Provenance and SPDX SBOM for Better Adoption
41mThe State of SBoMs in Embedded