Days 31 to 60 move the program from one-off scans to repeatable checks. Add dependency, secrets and static scanning to CI in advisory mode, tune the noise with the teams, set fix targets by severity, and recruit a first group of security champions. Blocking comes later, in days 61 to 90.
Goal of this phase
You have a baseline and owners from the first 30 days. Now make the checks run on every change, so the baseline stops growing while you work it down.
Steps
- Pick the pipeline stage. Run fast checks on pull requests and slower ones on merge or nightly. Developers tolerate a check that finishes while they are still in the review.
- Run in advisory mode. Post results as comments or a status that does not block. Watch how often findings appear and how many are wrong.
- Tune with developers. Sit with two teams and go through the top false positives. Suppress with a recorded reason, never silently.
- Set fix targets. Write short target windows by severity and exposure. See how to write a remediation SLA policy.
- Recruit champions. One volunteer per team is enough to start. See starting a champions program.
- Start tracking. Record new findings per week and the age of open ones.
Advisory versus blocking
| Mode | Use when | Risk |
|---|---|---|
| Advisory | New check, unknown noise | Findings get ignored |
| Blocking on new issues only | Noise is tuned | Occasional friction |
| Blocking on all issues | Backlog is small | Teams stall on old debt |
Moving from the first row to the second is the plan for the next phase. Blocking only on newly introduced issues avoids punishing teams for debt they did not create.
What good looks like at day 60
- Every critical repository has automated scanning.
- The false positive complaints have a visible response.
- Fix targets are written and teams have seen them.
- You can state how many findings are new this week and how many were closed.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a finding points to a line of code. That precision is what lets you tune with developers.
Quick check
Should scans run on every commit?
Run fast checks on every pull request. Run slower scans on merge or on a schedule, so they do not stall reviews.
Why not block builds from day one?
Untuned checks block good code and teach developers to route around security. Tune first, then enforce.
Safeguard integrates scanning into repositories and pipelines, and its policies and gates can start in a lenient mode. A free scan is a low-effort way to see sample output.
Last reviewed: 19 October 2026.
