Before
- Finding a component means surveying teams.
- An SBOM says what you shipped.
- Exposure duration is an estimate.
SECURITY · Production Vulnerability Management
Ask where a component is, when it started running, where it came from, and how many known vulnerabilities are in production now. Kosli gives you an answer while the question still matters.
Search Kosli
7 matched artifacts
Before
After
Always know what's running across the estate. Kosli joins code commits, binary provenance, SBOMS with runtime forensics.
Record
Every component and finding recorded against what is running.
fingerprint: matched
sbom: CycloneDX
scan: SARIF · 3 tools
actor: release-agent
Control
Controls run as code, enforced automatically.
severity: critical
remediation-sla: 14d
evidence: required
exception: justified
Prove
Exposure proven from a continuous record.
as-of: any date
exposure-window: 71 days
known-at: 2026-03-26
answer: timestamped
Improve
Exposure insights from governance data.
criticals-in-prod: 47
created: 18
closed: 62
sbom-coverage: 89%
A build-time SBOM describes an artifact. It cannot tell you which environments are running it, or for how long. Kosli resolves the component against what is running, and the same fingerprint carries you back through the release, the build, and the commit.
Scanner volume is not exposure. Counting findings tells you how much your tools produced, not how much of production is affected, or whether the situation is improving. Kosli counts what is running, by severity, against the organisational model you already keep in Kosli.
A report of forty criticals says nothing about the artifacts carrying no scan data at all. Those read as zeroes, and the estate looks healthier than it is. Kosli reports the gaps as an answer in their own right.
When a disclosure lands, the answer is usually a person joining scanner output to deployment records to Git history under time pressure, while a regulator's clock is already running. Kosli answers the same questions through the interface, the API, the CLI, and MCP.
Answering "where is it running, and for how long" in the world's most regulated industries
Read the case studiesNo. You keep your scanners. Kosli takes the findings they produce, in SARIF or vendor formats, and resolves them against what is actually running, with the provenance behind each artifact attached. The value is not another finding list: it is knowing which findings are in production, and which of your services carry them.
Those describe an artifact. This describes production. A scanner can tell you a component is present now, but it holds no history and no provenance, so it cannot say when the component arrived, how long it has been there, or who released it. Those three come from the delivery record, not from a scan.
Not in the first release. Today you can ask any question and get an answer in minutes, but you have to know to ask. Continuous evaluation against a vulnerability feed, where Kosli tells you an advisory has just made something you are running interesting, is the next step rather than this one.
They are reported, not silently excluded. Coverage is a first-class answer: you can ask how many running artifacts have no dependency, scan, or provenance evidence, and every count tells you the proportion of the estate it covers.
As far back as Kosli has been recording for you. The start of the record is itself known and reported alongside an answer, so "nothing found" is never confused with "nothing found in the period we have".
Component and exposure answers as of any date, exposure intervals with a start and an end, and counts computed as they were known at the time, which is what makes a historical figure defensible when someone asks why it changed.
The record is already there. Connect a scanner and an environment, and the question that used to take a fortnight takes a few seconds.
See the platform enterprise teams use to automate governance across build, release, and runtime.
Kosli in action