Yes, if you stored an SBOM for each release. Diff the SBOM of the last good release against the first bad one, list the added, removed and upgraded components, and test them in halves until one change reproduces the problem. It works best when your application code did not change much.
When this helps
Some regressions have no matching code change. The application diff is tiny, but behaviour shifted: a date format, a timeout, a serialised field. A transitive dependency moved because a range allowed it. Nobody reviewed it, because nobody chose it.
An SBOM per release is a record of what each build contained. Comparing two of them is far faster than reading lockfile diffs by eye, and it covers OS packages in images too.
Steps
- Pick the boundaries. The last known good release and the first known bad one.
- Retrieve both SBOMs. If you keep only the latest, you cannot do this. See keeping SBOM history.
- Diff them. List components added, removed, and changed in version. Our guide to diffing two SBOMs covers what to compare.
- Rank suspects. Start with components that touch the failing behaviour: serialisation, HTTP clients, date and time, database drivers.
- Bisect. Revert half of the changed versions in a test branch, build, and run the failing case. Narrow down until one change reproduces it.
- Confirm and pin. Pin the good version, or fix forward. Add a test that would have caught it.
An example log
| Step | Components reverted | Result |
|---|---|---|
| 1 | Half of the changed list | Still fails |
| 2 | Other half | Passes |
| 3 | Half of that half | Passes |
| 4 | One component | Fails, culprit found |
With ten changed components you need roughly four builds, which beats trying all ten.
Pitfalls
- Different build environments. If the base image changed, the diff includes OS packages. That is useful, but it widens the suspect list.
- Unstable SBOM output. If the same source gives different SBOMs, the diff is noisy. Check that generation is repeatable.
- Interaction effects. Two changes may fail only together. If bisecting contradicts itself, test pairs.
- No SBOM for the bad build. Rebuild from the commit with the same settings, then generate one.
What to keep afterwards
Write the finding into the release notes or incident record: the component, the version change, and why it broke. That turns a one off scramble into guidance. For example, you might decide to pin a library that has a history of behaviour changes in minor releases. Read write release notes from an SBOM diff for a way to publish the changes.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a change to dependencies is surfaced during review, before it ships.
Safeguard's SBOM and dependency scanning, plus pull request gates, help surface dependency changes at review time. You can try the free scan.
Quick check
What if I only kept the latest SBOM?
Rebuild the older commit with the same settings and generate a fresh one, then keep one per release from now on.
Does this replace normal debugging?
No. It narrows the suspects when the code diff does not explain the change.
Last reviewed: 19 October 2026.
