Keep the scanners you already pay for
- Ingests existing scanner output, so nothing gets ripped out
- Normalizes findings from every tool into one ranked queue
- Takes in vendor SBOM and VEX in CycloneDX or SPDX
Build one dependency inventory across your claims, policy, and member systems, and answer examiners with SBOM and VEX evidence built from source.
Built by the team that wrote the standards auditors now cite.
A carrier or payer runs policy administration built decades ago next to cloud-native member portals, with actuarial code alongside both. Each generation came with its own scanner, and none of them sees the whole estate.
96% of software vulnerabilities sit at least two layers below the dependency a developer changed (J.P. Morgan, Patchmageddon 2026).
Part of the estate has moved to the cloud and part hasn't. Dependencies live in both, and the inventory lives in neither.
Acquisitions and AI coding assistants both add dependencies faster than any one tool tracks them. Each acquired team brings its own scanner and its own answer to "are we exposed?"
A scanner lists the CVEs it matched. It can't show an examiner why the rest are safe, or where its view of the dependency tree stopped.
Kusari takes in what your existing tools report and ties it to a dependency graph built from your actual builds. Each team keeps the tools it chose, and when the board or an examiner asks what's exposed, there is one inventory to answer from.
Every finding ships with its evidence, in open formats your examiners, auditors, and group customers can read in their own tools.
Insurance regulators ask the same three questions financial regulators do. What's in your software, can it be exploited, and what did you do about it?
| Regulation | What it asks for | What Kusari gives you |
|---|---|---|
| NYDFS Part 500.13 | For insurers licensed in New York: asset inventory policies covering owner, location, classification, support expiration, and recovery time objective | Every component mapped to the services it runs in and the team that owns each fix |
| State insurance data security laws | Based on the NAIC model law: a written security program grounded in a risk assessment, with oversight of third-party service providers | A dependency inventory built from source, including the components your vendors ship, so the risk assessment covers what you actually run |
| HIPAA Security Rule, for payers | An accurate and thorough risk analysis of the systems that handle ePHI | SBOM, VEX, and provenance records in open formats an auditor can check in their own tools |
For your CISO: Kusari gives us one inventory of every dependency in our software, across the claims, policy, and member systems we run. When an attack drops, we can say whether we're exposed and where, and every answer comes with SBOM and VEX evidence an examiner can check. The team behind it wrote the standards our auditors now cite.
Kusari's founders spent two decades building and securing software at Citi, MUFG, and Bridgewater. Then they wrote the standards auditors now cite: GUAC, built with Google and now under OpenSSF, and SLSA, which Mike Lieberman still maintains. Guidewire uses GUAC to collate the SBOMs, attestations, and provenance its insurance cloud platform produces.
No. Kusari ingests the output of the scanners you already run and ties it to a dependency graph built from your builds. You keep the tools, and you get one inventory to answer from.
When compromised versions of Axios were published, a national health insurer running Kusari had its answer in minutes: three affected artifacts, with proof. The same analysis removed 90% of the vulnerability noise from a backlog tens of thousands deep.
NYDFS Part 500, the state insurance data security laws based on the NAIC model, and the HIPAA Security Rule for payers all expect you to know what your systems are built from. Kusari produces that inventory from source, down through the transitive layers, and attaches evidence in open formats: CycloneDX, SPDX, OpenVEX, and SLSA provenance.
Yes. Kusari produces SBOMs in CycloneDX and SPDX and VEX in OpenVEX, open formats an auditor or customer can read in their own tools. Each VEX statement records why a finding isn't exploitable, so the reasoning travels with the document.