Happy New Year 2026! Following my previous post about SBOM developments for July 2025, this is another one about things that happened in the community since. Again, this is mostly for myself as a reference storage but I’m happy if other people find this useful too.
1. ENISA SBOM Landscape Analysis December 2025 – important points:
- 1.1. Includes definitions for Product and Component on page 8, which shows wider acceptance of Product-Component model I was talking about for the last 6 years and which is a part of TEA now and a basis of ReARM.
- 1.2. Includes a list of minimum SBOM elements on page 16. I find presence of Component HASH to be problematic (same as with CISA draft).
- 1.3. Significant – in size – section on validation and signing – pages 20-23.
- 1.4. Build-time SBOM generation is officially recommended approach – page 28 – again, I’ve been talking about this for a while, and this is what Reliza’s SBOM workflow implementation in ReARM is built around.
- 1.5. Section on SBOM quality – page 34 – in the industry there is no consensus how to get this right (see also OpenChain guide being developed here, also Nokia released SBOM evaluation recently here), but requirements on the coverage being less than 100% are a welcome sign.
- 1.6. A lot of text dedicated to SBOM storage with many requirements but without naming a single tool which can actually store SBOMs (spoiler from me: just use ReARM 🙂 .
2. While not directly related to SBOMs, CVE at a Crossroads paper by IST is very noticeable in the community. The authors are calling for the creation of the Global Vulnerability Catalog (GVC).
As far as I know, there exist several projects working on this task, but personally I remain very skeptical based on the current state of the world. Yet, the paper presents a good highlight of the critical program. While there is a lot of criticism towards the current state of the CVE program, I believe things would be much more messier without it (and using GHSA as a replacement comes with its own set of seriour challenges).
3. CLE and PURL have officially become ECMA standards (hopefully, TEA will be next in 2026).
5. Red Hat announced they are now including SBOM in their containers here. I would say this is a great development, however the way this really should be implemented is a deliverable (or distribution) must only contain identifier (such as TEI or PURL), and then SBOM itself must be managed elsewhere based on this identifier. That is because SBOMs are not static after all.
6. Also from EU – Draft standard on vulnerability handling for products with digital elements in relation to CRA.
7. CSO published a piece on Malicious packages here about bad actors linking malicious code via URLs which gets undetected by scanners. This brings me again to the point about vulnerable vs malicious and using SBOM diffing as one of techniques to mitigate that. I will elaborate on this more in the future. Another interesting post on the problem of detecting malicious injections here. And a related talk by Paul McCarty at DefCon.
8. Interesting analysis of the Rust ecosystem by Frank Denis here.
9. A paper on analysing SBOM ecosystem for container images with focus on compliance.