No. A one-time scan shows the state of your dependencies on one day. A Type 2 examination covers how controls operated across a period, so scanning has to repeat on a schedule and leave records. A one-time scan is useful as a starting baseline, but it is not the control.
Type 1 and Type 2 in one minute
A Type 1 report describes whether controls were suitably designed at a point in time. A Type 2 report adds testing of whether they operated effectively over a period, often several months. Both come from an independent CPA, and neither is a certificate.
For dependencies, the difference is practical. For a Type 1, you can show that scanning is configured. For a Type 2, you must show it kept running and that findings were handled each month.
What a one-time scan is good for
- Baseline. It tells you how big the backlog is before you commit to a policy.
- Scope check. It reveals repositories nobody remembered.
- Policy sanity. You see how many high severity items exist, which tells you whether a seven day target is realistic.
Run it early in readiness work, then use the results to set the policy. Do not treat it as the evidence.
What repeats instead
| Layer | Cadence | Record |
|---|---|---|
| Pull request check | On every dependency change | Check result on the PR |
| Default branch alerts | Continuous, as advisories land | Alert history |
| Full inventory rescan | Weekly or on each release | Run log |
| Management review | Monthly | Minutes and sampled tickets |
GitHub documents that Dependabot scans the default branch and sends alerts when a new vulnerability is added to the advisory database or your dependency graph changes. That kind of event driven alerting covers the gap between scheduled runs, because new advisories appear for software you shipped months ago.
The gap that hurts in a window
Vulnerabilities are published daily against versions you already run. A clean scan in March says nothing about June. If your only scan predates the window, the auditor has no operating evidence, and a gap in the middle of a window is an exception.
Pick a cadence you can keep. If you promise daily and run weekly, that mismatch is the finding.
Starting the clock
The window begins when your controls are operating as designed. Many teams start it only after the scan, policy and ticket workflow have run once cleanly. Ask your auditor which date they will treat as the start, and align your records to it.
Try it yourself
Open the demo and watch continuous monitoring flag a newly published issue against a component you already shipped. Look at how a one-time view would have missed it.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard provides dependency scanning and continuous monitoring with compliance and evidence automation, so the repeating records are kept as a by-product. Start with a free baseline scan at https://gold.safeguard.sh/scan.
Quick check
Is a scan before the audit useless then?
No. It is a good baseline for sizing the backlog and setting realistic policy. It just is not operating evidence.
Who decides when the Type 2 window starts?
You and your auditor agree on it. Ask early and keep records from that date.
Sources
Last reviewed: 19 October 2026.
