A two-week SBOM proof of concept works when it has a narrow scope, written success criteria and an end date. Week one covers setup and generation on real repositories. Week two covers integration, change over time and a decision meeting. Without that structure, trials drift into a month of poking around.
Before day one
Name one owner and one decision date. Choose three to five repositories, a mix of typical and awkward. Write down the three questions the trial must answer, such as: can we produce valid SBOMs for everything we ship, can the tool find affected products when a new advisory lands, and can we share an SBOM with a customer. Agree who signs off. If security wants one thing and engineering wants another, resolve that now, because a trial cannot satisfy both after the fact.
Week one: generate and inspect
Days one and two: connect the repositories and generate SBOMs. Record setup time, because that is real cost. Days three and four: inspect output against lockfiles and validate formats. Day five: add one container image or build artifact if you ship them, and compare the source SBOM with the image SBOM. Differences are normal and worth understanding. Keep every output file in a shared folder so the comparison does not rely on memory.
Week two: integrate and watch change
Days six and seven: wire the tool into one CI pipeline and make a deliberate change, such as bumping a library, to see what the diff looks like. Day eight: simulate an advisory. Pick a real dependency you use and ask the tool which products contain it, how long that took, and whether an engineer could do it without help. Day nine: produce an SBOM you would actually hand to a customer and ask someone outside the team to read it. Day ten: score and decide.
What to skip
Skip dashboards with fake data, vendor slide reviews and any feature you cannot connect to a question you wrote on day one. If a capability matters, it will show up in a question. If you find yourself inventing a question to justify a feature, that is a sign to drop the feature from the evaluation.
If two weeks feels short, resist extending. A longer trial rarely adds information, and it gives the loudest preferences more time to settle in. If a question is still open on day ten, write it down as a contract condition or a follow up test, and decide anyway. A decision with named open risks is better than another week of exploring. Finally, thank the engineers who helped, and share the result, so the next evaluation starts with goodwill.
Try it yourself
Click through the demo and watch how the results change as you move through each step.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard runs SBOM and dependency scanning with reachability analysis, and you can try it on a repository with the free scan.
Quick check
How many repositories is enough for an SBOM trial?
Three to five that differ from each other. More adds effort without much new information.
Last reviewed: 19 October 2026.
