Baseline Scans: Separating Legacy Risk From New Introductions

When you first enable security scanning on an established repository, the initial full scan will find issues. Often hundreds of them. These are legacy findings: vulnerabilities and patterns that existed before you started scanning.

The worst thing you can do is show all of them on the next pull request.

Why baselines matter

Without a baseline, every PR inherits the full finding count of the repository. Developers see findings they did not introduce, cannot fix in a single PR, and are not responsible for. This kills adoption faster than any other factor.

A baseline draws a line: everything before this point is tracked separately. PR scanning only reports findings introduced after the baseline.

Creating a baseline

The baseline process:

1. Run a full repository scan against the default branch.
2. Record all findings with their file paths, line numbers, and fingerprints.
3. Store the baseline in version control or a scanning service.
4. Configure PR scanning to compare against the baseline and only report new findings.

# Example baseline creation
secbez scan --full --branch main --output baseline.json

# PR scan with baseline comparison
secbez scan --diff origin/main...HEAD --baseline baseline.json

Managing legacy findings

The baseline is not a mechanism for ignoring existing risk. It is a mechanism for managing it separately:

• Track legacy findings in a backlog with severity-based prioritization.
• Schedule remediation as dedicated work, not as PR blockers.
• Re-baseline periodically as legacy findings are resolved.
• Set SLAs for legacy finding resolution based on severity.

Baseline drift

Over time, the baseline should shrink as legacy findings are resolved. If the baseline grows, it means new scans are being baselined instead of fixed. Monitor baseline size as a health metric.

Practical tips

• Create the baseline before enabling any enforcement. This prevents the initial finding dump from blocking existing PRs.
• Store the baseline in a format that includes finding fingerprints, not just line numbers. Line numbers change with every commit.
• Update the baseline only through a deliberate process, not automatically.

Baselines make the difference between a security scanning rollout that succeeds and one that gets reverted within a week.