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 supplier SBOM and VEX in CycloneDX or SPDX
Connect the scanners, source control, and CI your teams already run, and answer examiners with SBOM and VEX evidence built from source.
Built by founders who ran software at Bridgewater and Citi.
Most banks and funds run several scanners across several source control systems, and no two of them agree on what's in the software. When an examiner asks, someone spends the next two weeks assembling the answer by hand.
96% of software vulnerabilities sit at least two layers below the dependency a developer changed (J.P. Morgan, Patchmageddon 2026).
Each scanner reports in its own format and its own console. Nobody holds the combined picture, so every question starts a reconciliation.
A scanner lists the CVEs it matched. It can't show an auditor why the rest are safe, or where its view of the dependency tree stopped.
Acquisitions, a cloud migration still in progress, and AI coding assistants all add dependencies faster than any one tool tracks them. Each acquired team brings its own scanner and its own answer to "are we exposed?"
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, the examiner, or an allocator asks what's exposed, there is one inventory to answer from.
Every finding ships with its evidence, in open formats your auditors, customers, and regulators can read in their own tools.
Financial regulators have converged on the same three questions. 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 |
|---|---|---|
| DORA, Article 28 | A Register of Information covering the ICT assets behind each service and the sub-outsourcing chains behind material providers, on request | A dependency inventory built from source, including the transitive components your vendors ship to you |
| NYDFS Part 500.13 | 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 |
| PCI DSS 4.x, requirement 6.3.2 | An inventory of bespoke and custom software and the third-party components incorporated into it | The third-party components in your custom software, traced through every transitive layer |
| FFIEC IT Examination Handbook | Examiners assess how you inventory and manage third-party and open source components in software you develop and acquire | SBOM, VEX, and provenance records in open formats an examiner can check in their own tools |
For your CISO: Kusari gives us one inventory of every dependency in our software, across the tools each team already runs. 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.
What each regulation asks for, in detail: Are we exposed? and DORA, PCI DSS and NYDFS all now require a software inventory.
Kusari's founders spent two decades building and securing trading systems 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.
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. It also runs on custom build setups other tools skip, including Haskell on Nix, Pants monorepos, and quant research in R and MATLAB on top of Python.
DORA, NYDFS Part 500, PCI DSS 4.x, and the FFIEC IT Examination Handbook all ask for an inventory of the software you build and the third-party components in it. 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.
Tim Miller and Michael Lieberman, who ran engineering on trading systems at Citi, MUFG, and Bridgewater. They went on to create GUAC with Google, now under OpenSSF, and Mike maintains SLSA.