A common cadence: SAST and dependency scans on every pull request, dependency monitoring continuously because advisories change daily, and DAST on each release candidate plus a regular schedule. Adjust for risk. Internet facing apps deserve more frequent dynamic testing than internal tools.
Why the cadence differs
Each test reads a different thing, and the thing changes at a different pace.
- Your code changes with every commit, so SAST follows commits.
- Your dependency list changes when someone edits a manifest, but the advisory data about those packages changes without any commit. A package you shipped last year can gain a new advisory tomorrow.
- A running app changes when you deploy or reconfigure, so dynamic tests follow releases and infrastructure changes.
Cadence table
| Test | Trigger | Backup schedule |
|---|---|---|
| Secret scan | Every push | Periodic full history scan |
| SAST | Pull request, changed files | Nightly full scan |
| SCA | Pull request when manifests change | Continuous or daily recheck |
| Container image scan | Every build | Recheck images in the registry weekly |
| DAST | Release candidate on staging | Weekly or monthly full scan |
| Manual review or pen test | Major features, architecture changes | Per your policy and contracts |
These are starting points, not rules. Pick numbers you can keep.
Signals to run sooner
- A widely reported vulnerability in a library you use.
- A new internet exposed endpoint.
- A change to authentication or authorization.
- A customer or auditor asking for fresh evidence.
Signals you are running too often
Findings repeat unchanged, nobody reads the reports, or scans slow down delivery. Cut the frequency of the heavy tests and keep the cheap ones.
Common mistakes
Teams often set a cadence once and never revisit it. Review it when the application changes shape, for example when it becomes internet facing or starts handling payments. Also watch for scans that quietly fail. A weekly job that has not completed for two months is worse than no job, because people assume it is working. Add an alert for missed or failed runs, and show the date of the last successful scan on a shared dashboard.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a project is rechecked over time without a new commit.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning with continuous rechecks, zero day discovery and policy gates. Start with the free scan.
Quick check
Is a nightly full scan enough on its own?
It misses problems for up to a day and gives developers late feedback. Pair it with a fast pull request check.
How often is a penetration test needed?
That depends on your risk, contracts and any framework you follow. Check the requirement that applies to you rather than assuming a number.
Last reviewed: 19 October 2026.
