I’ve been thinking about continuous SBOM diffing for a while, but the subject appears to be even more important than I initially thought.

Yesterday (November 11, 2025) I attended SBOMit workshop which was a part of KubeCon NA 2025. SBOMit is an OpenSSF project which deals with SBOM correctness, validity and verification.

Specifically, the demo shown during the workshop highlighted hidden dependencies, files and network traffic that may be missed when running traditional SBOM generation tools without additional supervision – done via Witness in the demo.

I must say that at the moment the practical implementation of this approach looks complex. That being said it is very encouraging to see the research that should eventually make SBOM generation significantly more accurate than what we currently have.

At the same time, with the improved generation we are likely to see more dependencies and more datapoints in SBOMs, including raw files, and I’m not aware of good tooling that can parse those. This and some unrelated conversations on SBOM quality led me to think what such tooling might look like and brought me back to the subject of SBOM diffing.

I believe that the primary modus operandi for the end-to-end process should be SBOM diffing done at scale. The idea goes as follows:

• You make initial SBOM for a component as a part of CI for every build / release and ensure that this SBOM is as accurate as it can be with available tooling.
• This SBOM becomes sort of a gold standard. The security team needs to inspect both SBOM and the build to make sure that the security posture is acceptable. Of course a lot of this process can and should be automated, but we may inspect deeper checks here than on a regular build.
• From there, every functional release (that changes code but not dependencies) must essentially match the gold standard SBOM.
• If the diff shows changes, the security team must be alerted and investigate whether the change is warranted or not, i.e. whether a security incident is suspected.
• On the other hand, security changes – such as dependency updates – would predictably modify the SBOM and create a new *gold standard *version. If that happens, the cycle repeats based off the new gold standard.

I believe if we approach the problem via SBOM diffing as mentioned above, this should establish otherwise non-actionable artifacts – such as files – as meaningful.

As always, tooling for the above implementation is lacking, however we already have notifications about SBOM level changes in ReARM. What we’re going to add next is inclusion of such changes in the Changelog functionality and tying in ReARM Pro approvals with the presence of such changes. This should close the loop and make it more actionable.

I believe that if done correctly, this creates a continuous integrity loop which catches deviations from expected supply chain posture. The big step forward is that it can catch malware, which is unlikely to happen with existing approaches in supply chain security.

Taking this a step further, it should also be possible to block the build on the CI if a deviation from the gold standard is detected and the build is not known to be modifying supply chain dependencies.

Post navigation