Security Scans Have a History: Visibility Into Every Security Scan

A build fails. A pull request gets blocked. A finding shows up in the dashboard that nobody remembers from yesterday. In each case the first question is almost never about the vulnerability. It is about the scan that produced it.

What ran? Against which commit, branch, or image? Did it finish? Which policy made the call? Was this issue new, or has it been there for weeks?

Answering those questions usually means stitching together CI logs, source control history, and the security platform: three systems that each hold one piece of the story. As a security program scales to thousands of scans a day across repositories, pull requests, and container images, that reconstruction work becomes the slow part of every investigation.

When a scan blocks a build, teams investigate the scanner first

Most scanning tools treat a scan as a disposable event. Results get written to a dashboard and the execution that produced them disappears. The finding survives. The context does not.

That design holds up until something looks wrong. A developer sees a blocked merge and wants to know which rule blocked it. An AppSec engineer sees a new critical and wants to know whether it arrived with the last dependency bump or was always there. A platform engineer sees a CI job that passed while security results never landed and wants to know whether the scan even ran.

None of those answers live in the finding. They live in the scan, and the scan is already gone.

Scan History keeps the execution record, not just the result

Scan History is a centralized record of every scan Kodem runs across your repositories and container images. Instead of discarding execution once findings are generated, it preserves the context around each one: when the scan ran, what it scanned, whether it succeeded or failed, which findings it produced, which policies it evaluated, and why a violation fired.

That turns scanning from a point-in-time event into a traceable workflow. When a result needs explaining, the explanation starts at the scan record itself, not across three other systems.

Context turns a scan record into a fast investigation

Unexpected results almost always have a concrete cause. A new package entered the dependency graph. A policy threshold changed. A repository scan ran against a different branch than the one someone had in mind. Without execution history, those causes are guesswork.

Scan History makes the cause visible. It separates a new issue from an existing one, a policy decision from a scan failure, a code change from a configuration change. This is where runtime intelligence matters: a finding is not just a line in a report but a result tied to what actually executed, against a specific scan, under known conditions. A runtime-powered SCA scan can show not only that a vulnerable package is present but whether it is loaded in production, and the record holds that evidence. Prioritizing on that basis is the same logic behind runtime-aware vulnerability management: rank by what is real, not by raw severity.

One view across repositories, pull requests, and container images

Application risk rarely sits in one place. Repositories, pull requests, CI pipelines, and container images all contribute, and each tends to be investigated by a different team with a different tool. Scan History gives all of them one consistent view of scan activity: what was scanned, when, what it found, what it enforced, and where a scan failed.

That shared record matters most in the moments that least tolerate ambiguity: an incident, a release gate, a compliance review. Being able to show that scans ran, policies were evaluated, and findings were produced is its own form of evidence, an auditable trail of activity that no longer has to be assembled by hand from fragmented logs. It is also why the recommended way to roll out enforcement across the software development lifecycle is to start in warn mode, review the Scan History page, then move high-priority assets to block.

Scanning should answer questions, not become one

Security scans produce genuinely useful information. The friction has never been the findings. It has been the work of reconstructing how, when, and why a scan produced them, after the scan itself has vanished.

Keeping that record closes the gap. Scan History gives AppSec, engineering, and platform teams the context to troubleshoot a result, explain an enforcement decision, and trust the workflow underneath. Scanning is meant to help teams investigate risk. It should not be the thing they end up investigating.

Frequently Asked Questions

1. What is Scan History in Kodem? Scan History is a centralized record of every security scan Kodem runs across your repositories, pull requests, and container images. For each scan it keeps the operational context: when it ran, what it scanned, whether it succeeded or failed, which findings it produced, and which policies it evaluated.

2. Why did my build fail or my pull request get blocked? Open the scan in Scan History. Each record shows which policy was evaluated and why a violation fired, so you can tell whether a block came from a code weakness, a dependency issue, or a changed policy threshold, without reconstructing it from CI logs.

3. Can I confirm whether a scan actually ran? Yes. Scan History records the status of every scan, including failures and scans that did not complete, so you can confirm whether a CI job produced security results or silently skipped them.

4. Does Scan History cover container images as well as code? Yes. It gives one consistent view of scan activity across repositories, pull requests, CI pipelines, and container images, so teams investigating different asset types start from the same record.

5. How does Scan History help during audits? It provides an auditable trail showing that scans ran, policies were evaluated, and findings were produced, which supports incident reviews, release gates, and compliance evidence without assembling logs by hand.