Keep a current SBOM and VEX for every release, built from source across your monorepo, and answer customer security reviews with evidence.
Built by founders who ran software security at Bridgewater and Citi.
Banks, insurers, health systems, and federal agencies pass their own obligations down to the software vendors they buy from. Whether you sell fintech, insurtech, healthtech, or defensetech, the security review gets longer at every renewal.
96% of software vulnerabilities sit at least two layers below the dependency a developer changed (J.P. Morgan, Patchmageddon 2026).
Enterprise buyers ask for an SBOM in procurement. A stale export from last quarter falls apart at the first follow-up question.
AI coding assistants and a fast-moving monorepo add dependencies every day. A scheduled scan describes the codebase you had last week.
A scanner lists the CVEs it matched. It can't show a customer's security team why the rest are safe, or where its view of the dependency tree stopped.
Kusari builds the dependency graph from your actual builds and keeps it current as the code moves. When a customer asks what's in the release they're running, the answer is already there.
When a customer's security team asks what's in your product, send the SBOM, the VEX, and the provenance, in open formats their tools already read.
Some of these apply to you directly, and the rest arrive through your customers' contracts. Either way the question is the same: what's in your software, and what did you do about it?
| Regulation | What it asks of a SaaS vendor | What Kusari gives you |
|---|---|---|
| SOC 2 | Auditors assess how you manage change and vendor risk, including the third-party code in your product | Evidence of every dependency change, in open formats your auditor can check |
| DORA, Articles 28–30 | If you sell to EU financial entities: they must set security terms with their ICT providers and register them, sub-contractors included | An inventory of the components in your product, transitive ones included, ready for your customer's register |
| NYDFS Part 500.11 | If you sell to New York banks or insurers: they must set security requirements for their third-party service providers. Fintechs licensed in New York are covered directly | SBOM, VEX, and provenance records that answer those requirements with evidence |
| PCI DSS 4.x, requirement 6.3.2 | If you're in the card data flow: an inventory of your custom software and the third-party components incorporated into it | The third-party components in your custom software, traced through every transitive layer |
| HIPAA Security Rule | If you handle ePHI as a business associate: an accurate and thorough risk analysis of the systems that handle it | A dependency inventory built from source, so the risk analysis covers what your product actually runs |
| FedRAMP | If you sell to US federal agencies: NIST SP 800-53 controls, including a system component inventory (CM-8) and supply chain risk management (the SR family) | A component inventory built from source, with SLSA provenance for each artifact |
| FDA section 524B | If you ship a cyber device, including software as a medical device: an SBOM in the premarket submission | SBOMs built from source, with a VEX statement for each finding that isn't exploitable |
For your CISO: Kusari keeps a current SBOM and VEX for every release we ship, built from source. When a customer sends a security review or a new attack drops, we answer with evidence the customer's own tools can read. The team behind it wrote the standards our customers' auditors now cite.
Kusari's founders spent two decades in security engineering at Citi, MUFG, and Bridgewater, the kind of regulated buyer that sends the security review. Then they wrote the standards auditors now cite: GUAC, built with Google and now under OpenSSF, and SLSA, which Mike Lieberman still maintains.
Yes. Kusari produces SBOMs in CycloneDX and SPDX and VEX in OpenVEX, open formats a customer's security team can read in their own tools. Each VEX statement records why a finding isn't exploitable, so the reasoning travels with the document.
Yes. Kusari watches the monorepo continuously and builds its graph from your actual builds, so the inventory reflects every service in it. It also runs on custom build setups other tools skip, including Haskell on Nix and Pants monorepos.
Yes. A regulated SaaS company runs Kusari in its FedRAMP environment, where it was running within three weeks and replaced GitHub Advanced Security.
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.
SOC 2 is the audit regulated customers commonly ask for. DORA and NYDFS Part 500 require banks and insurers to set security terms for their technology providers, and those terms end up in your contracts. PCI DSS 4.x applies if you handle card data, HIPAA if you handle ePHI as a business associate, FedRAMP if you sell to federal agencies, and FDA section 524B if you ship a medical device. All of them come back to an inventory of what's in your software, which Kusari produces from source with evidence attached.