CASE STUDY · SOFTWARE SUPPLY CHAIN SECURITY (SBOM)
Catching a vulnerable dependency before it reached production.
- 1 dayRelease blocked and package updated within 1 day
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market B2B services company. Name withheld under confidentiality.
Dependency scanning that covers the full tree, a remediation workflow and release gates that stop a build when a serious known flaw is present.
- 1A vulnerable package was sitting three dependency levels deep.
- 2No developer had chosen it.
- 3It came in through a library the team used for something unrelated.
- 4The application manifest looked clean, which is exactly why nobody saw it.
- 5The company had scanning on direct dependencies only, and release approval was a manual checklist that did not mention transitive packages.
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 01The first version of the gate was too strict
It flagged issues in packages used only in tests and build tooling, and developers started to see it as an obstacle.
- PROBLEM 02We split findings by whether the package reaches production, tuned the policy, and added a plain explanation to each failure message: what was found, where it came from, and the likely fix
After that the number of disputed blocks dropped and the team stopped asking to switch the gate off.
- PROBLEM 03We also found that the scan results were noisy for one older service, which had a long list of old findings nobody had triaged
Turning the gate on would have blocked every release. We agreed a baseline: existing findings were recorded with an owner and a due date, and the gate blocked only new serious findings. The team then worked down the old list over several weeks without holding up delivery.
- PROBLEM 04The team then worked down the old list over several weeks without holding up delivery
03 · THE PROCESS
How we ran it.
The work ran in short cycles. In the first week we mapped how builds and releases worked and chose where gates should sit. In the second we wired scanning into the pipeline in report-only mode and reviewed findings with the team. In the third we agreed a policy on severity and turned the gate on for release branches.
- 01Step 1
We held a short daily check-in during the roll-out and a weekly review with the engineering manager for the first month.
- 02Step 2
Remediation ran as normal tickets in the team's own board, so nobody had to learn a new tool.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Developers see transitive dependencies in pull requests, not after release.
- NOW 02
A failed gate comes with a suggested upgrade path.
- NOW 03
Exceptions are rare, written down and time-limited.
- NOW 04
Lockfiles are mandatory in every service.
- 1 day
Release blocked and package updated within 1 day
No vulnerable version shipped
05 · WHAT WE BUILT
How it works.
- The scan resolves the full dependency graph from lockfiles, including transitive packages, and compares it against public vulnerability advisories.
- Findings are deduplicated and attached to the owning service.
- The release gate checks the scan result for the exact commit being released.
- A written exception path allows a release with a known issue only with a named approver and an expiry date.
- Lockfiles are required, so builds are reproducible and the scan looks at what ships.
- Scan results are kept with the build record for later audit.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- A vulnerable package was sitting three dependency levels deep. No developer had chosen it. It came in through a library the team used for something unrelated. The application manifest looked clean, which is exactly why nobody saw it.
- What did Brandsmashers build?
- Dependency scanning that covers the full tree, a remediation workflow and release gates that stop a build when a serious known flaw is present.
- How was the work run?
- The work ran in short cycles. In the first week we mapped how builds and releases worked and chose where gates should sit. In the second we wired scanning into the pipeline in report-only mode and reviewed findings with the team. In the third we agreed a policy on severity and turned the gate on for release branches.
- What were the results?
- Release blocked and package updated within 1 day; no vulnerable version shipped.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
