CASE STUDY · SOFTWARE SUPPLY CHAIN SECURITY (SBOM)
Generating and managing SBOMs across a client's entire codebase.
- 92%92% of priority repositories covered
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market B2B services company. Name withheld under confidentiality.
Automated SBOM generation in CI across 60 repositories. Each build now produces a machine-readable SBOM that is stored centrally and searchable by package name and version.
- 1The company had no inventory of its software dependencies.
- 2Sixty repositories, several languages and a mix of package managers had grown over the years.
- 3Different teams made different choices, and nobody had ever listed them side by side.
- 4When a new vulnerability made the news, someone had to ask each team by message and wait.
- 5Answers came back in days, and nobody trusted them to be complete.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01Early sboms for some services were thin
Dependencies installed in container build stages, or vendored into the repository, did not show up in the manifest-based scan. We found this by comparing one SBOM with what was actually running in the image.
- PROBLEM 02We added image-level scanning for container builds and a check that flags sboms with suspiciously few components
The fix delayed one batch by about a week, but it meant the inventory could be trusted. The lesson was to test an SBOM against reality early, not assume the tool is right.
- PROBLEM 03A second, smaller problem came from ownership
Several repositories had no active maintainer, so SBOM pipeline pull requests sat unreviewed. We did not want to merge changes into code nobody understood. Instead we listed those repositories with the client, agreed who would be the nominal owner for each, and archived two that were no longer used.
- PROBLEM 04That shortened the rollout list and gave every remaining repository a person to ask
03 · THE PROCESS
How we ran it.
We worked in three phases. First, a discovery sprint listed every repository, language and build system, and ranked repositories by customer impact. Second, we piloted on three repositories with different stacks and fixed the tooling gaps. Third, we rolled out in batches, starting with the priority repositories.
- 01Step 1
We met the client's engineering lead twice a week, kept a shared tracker of repositories by status, and held a short demo at the end of each batch.
- 02Step 2
Developers were asked to review only one thing: the pull request that added the pipeline step.
- 03Step 3
We did the rest.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Security answers advisory questions from the inventory, not by messaging teams.
- NOW 02
New repositories get the pipeline template on day one.
- NOW 03
Sales sends SBOMs to customers from a defined process, not a scramble.
- NOW 04
A weekly review looks at repositories with missing or stale SBOMs.
- 92%
92% of priority repositories covered
Time to answer "are we affected?" down from days to under an hour
05 · WHAT WE BUILT
How it works.
- Generation runs as a pipeline step using a suitable tool per ecosystem, producing CycloneDX output.
- A small shared pipeline template means teams add one include rather than writing their own steps.
- SBOMs are uploaded to a central store with metadata: repository, commit, build number and date.
- A query layer lets security search "which builds contain this package at this version" and see results across all repositories.
- Access is limited to engineering and security.
- Builds fail loudly if SBOM generation fails, so gaps cannot hide.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- The company had no inventory of its software dependencies. Sixty repositories, several languages and a mix of package managers had grown over the years. Different teams made different choices, and nobody had ever listed them side by side.
- What did Brandsmashers build?
- Automated SBOM generation in CI across 60 repositories. Each build now produces a machine-readable SBOM that is stored centrally and searchable by package name and version.
- How was the work run?
- We worked in three phases. First, a discovery sprint listed every repository, language and build system, and ranked repositories by customer impact. Second, we piloted on three repositories with different stacks and fixed the tooling gaps. Third, we rolled out in batches, starting with the priority repositories.
- What were the results?
- 92% of priority repositories covered; time to answer "are we affected?" down from days to under an hour.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
