Hook the scanner at a point every change must pass through, usually a pull request check at the repository host, not inside each individual pipeline. Add pipeline level scans only for artifacts that the pull request check cannot see, such as container images built later.
The problem
Legacy monorepos often run old and new CI side by side: a long lived build server for old services, a hosted pipeline for newer ones, and a few shell scripts on a machine under someone's desk. If you add scanning to one, the others stay uncovered, and you must maintain the same step in several places.
Four places to scan
| Hook point | Covers | Weakness |
|---|---|---|
| Pull request check at repository host | Every change, regardless of CI | Sees source, not built artifacts |
| Each CI pipeline | The pipeline's own build | Duplicated setup; gaps where pipelines do not exist |
| Pre commit or editor | Early feedback for one developer | Optional; can be skipped |
| Scheduled scan of default branch | Everything, including unchanged code | Not tied to a change |
A layered setup that works
- Pull request check at the repository host as the main gate. One configuration, applied to everything.
- Scheduled full scan of the default branch, to catch new advisories on old code.
- Artifact scan in the pipeline that builds container images or packages, because build time packages can differ from source declarations.
- Editor or CLI scanning offered to developers as optional early feedback.
The first two give you coverage. The third gives you precision. The fourth is goodwill.
Handling the old CI system
If the old system cannot call your scanner, do not rebuild it first. Options in order of effort:
- Trigger the repository host check from a webhook or status, so the old system is not involved.
- Run the scan from a small separate job that watches the default branch.
- Wrap the old build in a script that calls the CLI, as a stopgap with an expiry date.
Make results land in one place
Different hook points must report to the same dashboard and the same ownership map. If results scatter across systems, nobody sees the whole and counts will not reconcile. Choose one system of record early.
Document the coverage matrix
Keep a table: service, CI system, hook points that cover it, last verified date. Once a quarter, verify one service per CI system end to end, by introducing a harmless test dependency on a branch and confirming it is flagged.
Avoid the all CI rewrite trap
Teams sometimes decide to unify CI before adding security. That delays protection by a year. A pull request check works now and survives the later migration.
Where Safeguard fits
Safeguard offers pull request gates, continuous monitoring and container image scanning, so one tool can fill each hook point in the layered setup. See https://gold.safeguard.sh/scan for a free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how scheduled monitoring raises findings on code that has not changed.
Quick check
Is a pull request check enough on its own?
No. It misses advisories published after merge and packages added at build time. Pair it with a scheduled scan and an artifact scan.
Do we need to migrate CI first?
No. Start with the repository host check and migrate CI on its own schedule.
Last reviewed: 19 October 2026.
