It can, but you control how much. Checks that scan the whole repository on every commit add time. Checks that look only at changed manifests, reuse cached results, and run in parallel add very little. Measure the added time on your own pipeline before deciding, and set a budget.
Where the time goes
Four steps add time to a pipeline. Generating the dependency inventory, matching it against vulnerability data, running deeper analysis such as reachability, and waiting on a network call to the platform. Each can be reduced separately.
Ways to keep it fast
| Technique | Effect |
|---|---|
| Scan only changed manifests and lockfiles | Skips work when nothing changed |
| Cache the inventory per lockfile hash | Repeat builds cost almost nothing |
| Run in parallel with tests | Hides most of the delay |
| Move deep analysis off the critical path | Quick check blocks, deep check reports later |
| Use a local database snapshot | Avoids a slow network round trip |
The lockfile is the key. The npm documentation says that, as of npm v7, lockfiles include enough information to gain a complete picture of the package tree. That means a tool can often build the inventory from the lockfile alone, which is much faster than resolving or building the project.
Split fast and slow checks
Use two tiers.
- Fast tier on the pull request. Inventory diff, known exploited check, license and source rules. Target a small, fixed time budget that your team agrees on.
- Slow tier after merge or nightly. Full reachability analysis, image scans, full history comparison.
Blocking decisions come from the fast tier. The slow tier produces findings that enter the normal triage flow.
How to measure
- Record median and 95th percentile pipeline time for two weeks before the change.
- Enable the check in advise mode on a few repositories.
- Record the same numbers for two more weeks.
- Compare the difference, not the absolute values.
- Set a budget, such as no more than a small percentage of existing pipeline time, and hold the platform to it.
Look at the tail too. A rare slow run annoys people more than a steady small delay.
What to do when the platform is slow or down
Decide the failure mode in advance. Fail open with an alert keeps developers moving. Fail closed protects but can halt a release. Whichever you pick, tell people, and test it once.
Avoid hidden costs
Large monorepos can trigger many scans for one change. Scope checks per package path. Also watch for repeated downloads of the same vulnerability data in each job, which a shared cache removes.
A worked example
Take a hypothetical pipeline whose median pull request build takes twelve minutes. The team adds the platform check in advise mode to five repositories and measures. These numbers are invented for illustration.
In the first configuration, the check runs after the tests and scans everything, adding a few minutes. Developers notice. The team changes three things. They scan only changed manifests, which skips the step when no dependency file changed. They cache the inventory keyed on the lockfile hash, so repeated builds reuse it. They run the check in parallel with the tests instead of after them.
In the second configuration the added time is rarely noticeable. The team also moves full reachability analysis to a nightly job, with results delivered as findings the next morning, and keeps only the quick checks on the pull request. The build time distribution looks about the same as before, with a slightly longer tail on pull requests that change manifests.
They write a budget: the check may add no more than a small, agreed share of median build time, and the tail must not exceed an agreed limit. They record the budget and review it quarterly.
Measurement sheet
| Metric | Before | After, advise mode | After tuning |
|---|---|---|---|
| Median build time | |||
| 95th percentile | |||
| Runs where check was skipped | |||
| Cache hit rate | |||
| Failures caused by the check service |
Collect at least two weeks per column so weekly patterns do not distort results.
Choosing where each check runs
| Check | Where | Blocking |
|---|---|---|
| Inventory diff | Pull request | Informational |
| Known exploited rule | Pull request | Yes |
| License and source rules | Pull request | Yes |
| Full reachability | Nightly or after merge | No |
| Image scan | After image build | Depends on rule |
| Rescan of old releases | Scheduled | No |
The principle is simple: block on what is fast and high confidence, and report on what is slow or uncertain.
Reliability matters as much as speed
A check that fails randomly teaches developers to rerun and ignore it. Track the failure rate of the check itself. If the service is unreachable, decide in advance whether to fail open. Document the choice and alert the platform owner whenever it happens.
Large monorepos
Split scans by package path. Give each path its own cache key. Avoid scanning every service when a shared library changes unless the rule requires it, and in that case run downstream scans in parallel with a concurrency limit so the build farm is not overwhelmed.
Communicating with developers
Share the measurements. Developers accept small delays when they can see that the team measured, set a budget, and acts when the budget is exceeded.
Try it yourself
Click through it at your own pace, or open it full screen. Open the demo and look at what the gate does and when. Think about which of those steps must be fast and which can wait.
Safeguard offers dependency scanning, policies and gates, and reachability analysis, so you can place quick checks in the pull request and deeper analysis elsewhere. Try a one off scan at gold.safeguard.sh/scan and note how long it takes on your project.
Quick check
Do checks need to run on every commit?
No. Run fast checks on pull requests and heavier ones on merge or on a schedule.
What is an acceptable delay?
Set a budget with your developers. Anything they feel on every run will be resented.
Is a nightly scan enough?
For deep analysis, yes. For blocking a risky new dependency, the pull request is the right place because that is when the change is cheap to undo.
Sources
Last reviewed: 19 October 2026.
