This follows my recent posts on SBOM tooling and SBOM updates. I keep reading that publishers should strive for something called “Dynamic SBOM” where a tool continuously updates an SBOM per Product or Component that they produce. However, that is not how the transparency system should work. SBOMs should be scoped to a specific release… Continue reading Why “Dynamic SBOM” is a Misconception
Month: May 2025
ReARM Now Supports Transparency Exchange API
Reliza just announced ReARM support for Transparency Exchange API (TEA) Beta 1. Read details here. I believe this is world first implementation. This is a big milestone for me as I was involved in TEA creation for the past year almost since its inception. The TEA is an effort to create common approach of how… Continue reading ReARM Now Supports Transparency Exchange API
Why New Generation of SBOM Tools Matters
As a preface for what I mean by old generation tooling, here is a screenshot from Semgrep documentation: Essentially, this asks developers to centre their SBOM generation efforts around the main branch of a repository. To expand on this, legacy generation of tooling simply slaps an SBOM to a security scan, resulting in a single… Continue reading Why New Generation of SBOM Tools Matters
SBOM – Not So Static After All
For a long time I was preaching the idea that an SBOM can and should essentially be split into 2 parts. The first part is static – that is the actual list of all software components with their fixed metadata (version, purl, hashes, etc). The second part is dynamic – that is things related to… Continue reading SBOM – Not So Static After All