SARIF lets a scan result carry a baselineState of new, unchanged, updated or absent, compared with a previous run. Counting new and absent findings per change gives you introduced and fixed numbers, which trend more honestly than a running total of open findings.
The problem with totals
A total count of open findings goes up when you add code, goes down when you delete code and jumps when a scanner adds rules. It rarely tells you whether your process is improving. Counting what each change introduces and what each change fixes is closer to the thing you can influence.
What the standard says
The SARIF 2.1.0 specification defines the baselineState property on a result. It describes the state of that result with respect to a baseline run, and it has four values:
- new: detected in the current run but not in the baseline run.
- unchanged: detected in both runs without a significant change.
- updated: detected in both runs but changed in a way the tool considers significant.
- absent: detected in the baseline run but not in the current run.
The baseline run is identified by the baselineGuid on the run object. The spec also says baselineState is computed with respect to that run.
Turning states into metrics
| SARIF state | Metric it feeds |
|---|---|
| new | Findings introduced per change |
| absent | Findings fixed per change |
| unchanged | Carried debt |
| updated | Findings whose details changed, review for severity shifts |
Per pull request, compare against the target branch as the baseline. That gives a result that matches how gates should work: block on what this change introduced, not on inherited debt.
Steps
- Run your scanner on the target branch and keep the SARIF output as the baseline.
- Run it on the pull request branch, pointing at that baseline if your tool supports it.
- Count results by baselineState and by level.
- Store counts per change with the repository, date and scanner version.
- Chart introduced and fixed per week, with the carried debt as a separate line.
If your tool does not write baselineState, you can compute the same thing by comparing result fingerprints between two files. The SARIF format includes fingerprint properties for exactly this kind of matching.
Cautions
- A rule change can make old findings look new. Record scanner and rule versions and flag the weeks when they change.
- Findings that move because a file was renamed may appear as one absent and one new. Fingerprints help, but check a sample.
- Introduced counts depend on how much code changed. Read them alongside change size, or use them as a trend for one repository.
Quick check
Do I need baselineState to gate on new findings only?
No, but it makes it simpler. Any method that matches results across two runs, such as fingerprints, can give the same outcome.
Is carried debt a bad number?
It is a fact. Watch whether it shrinks, stays level or grows, and whether the oldest items are being addressed.
How Safeguard fits
Safeguard's dependency and SBOM scanning and policy gates can be set to act on what a change introduces. A free scan is available at gold.safeguard.sh/scan.
Sources
- OASIS, SARIF Version 2.1.0, section on the baselineState property: https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html
Last reviewed: 19 October 2026.
