It can, but the cost depends on what you scan. Reading a lockfile is quick, while unpacking a large container image takes longer. Measure each job on your own pipeline, set a time budget, and run the heavier scans on merge or release rather than on every commit.
Where the time goes
Generation time is not one number. Several things add up.
| Factor | Effect |
|---|---|
| Input type | Lockfile reading is light, image unpacking and file walks are heavier |
| Image size and layer count | More layers and files means more to index |
| Cold or warm cache | Tools that download metadata or databases on each run are slower |
| Network lookups | Latency and rate limits add delay and variance |
| Runner size | Small shared runners are slower and less predictable |
| Scan scope | Final stage only, or every build stage |
Docker's SBOM documentation shows an example of scope driving cost: by default the scan covers the final stage, and scanning additional stages or the build context needs extra arguments. More scope means more work.
How to measure
- Pick three representative jobs: a small service, a large monorepo, and a big container image.
- Run each build with and without SBOM generation, at least five times each, and record wall clock time.
- Take the median and the slowest run, not the average. The slowest run is what developers complain about.
- Run once with a cold cache and once with a warm one.
- Record the SBOM size in kilobytes or megabytes, since upload and storage add time.
- Repeat after any tool upgrade.
Report the difference as seconds and as a percentage of total pipeline time. A job that adds twelve seconds to a ten minute build is a different conversation from one that adds three minutes to a two minute build.
Ways to keep it cheap
- Generate from the lockfile in pull requests, and from the built image on merge. The first answers "what did this change add?" fast, and the second answers "what shipped?".
- Run in parallel. SBOM generation rarely depends on tests, so put it beside them.
- Cache metadata and databases between runs where your tool allows it.
- Avoid network lookups in the hot path, or mirror what you need.
- Skip unchanged inputs. If the lockfile and base image digest are identical to the last run, reuse the earlier result.
Decide what blocks a build
Time budgets and gate rules go together. A scan that takes a minute is fine if it is a gate on pull requests. A scan that takes ten should not block every push. Write the rule down: what must pass before a merge, what runs after, and what runs nightly. Developers tolerate a gate they understand and resent a slow one they cannot explain.
Try it yourself
Click through it at your own pace, or open it full screen. See where in a pull request flow a dependency check sits and what happens when it fails.
Where Safeguard fits
Safeguard offers policies and gates that can check dependencies in a pull request, plus dependency scanning and SBOM output. Test the timing on your own repository with the free scan at gold.safeguard.sh/scan and compare it with your budget.
Quick check
Should every commit generate an SBOM?
Not necessarily. Lockfile based checks on pull requests are cheap, and full image SBOMs can wait for merge or release.
Which timing number should I report?
The median and the slowest run. The slowest run is what developers feel.
Sources
Last reviewed: 19 October 2026.
