Find the gaps your scanner can't see.

Security leaders choose Kusari to prioritize software supply chain risk verified at source.

01 02 03 04 05 06 07 scanner depth limit legacy scanner kusari · resolving frontend-console
Depth reached
7 levels
scanner: 2 kusari: 7

Built by the team behind GUAC and SLSA

Commercial and Open Source Partners
Google Microsoft Intel Red Hat VMware Yahoo DTCC Guidewire Roche Clear Alpha Purdue University
Take a Tour

Take a tour of Kusari Platform.

Explore this interactive tour to see how Kusari Platform puts the information you need at your fingertips.

Direct
Transitive
Deep transitive
your_app
5%
Visible to SCA tools
95%
Transitive — the blind spot
The problem

Your scanners see 5% of your risk.

The software supply chain is moving faster than any team can manually verify. Attackers are shifting upstream to exploit the trust you put in software you never wrote.

01

SCA tools start at runtime

Most scanners reverse-engineer what you've already shipped — they see the shadow, not the structure. Transitive dependencies several layers deep are effectively invisible.

02

Noise, not signal

Raw CVSS dumps thousands of alerts without context. Teams spend weeks triaging severity instead of prioritizing reachability, exploitability, and actual blast radius.

03

Zero-day response is a fire drill

When the next Shai-Hulud or Axios hits, you need to know which services are exposed and how to fix them — in seconds, not days.

The Solution

One Trust Fabric. Four surfaces.

Kusari Trust Fabric is the intelligence layer that unifies your existing stack. Ingest from every tool you've already deployed, normalize into a single source of truth, then act on it through the surface that fits the moment.

Kusari Platform
Foundation

The software supply chain command and control center. Continuously updated, built from source, and enriched with agentic risk analysis and exploitability context.

Full transitive graph Provenance Kusari Score Reachability Exploitability Dependency search Audit history
Kusari Inspector
Shift-Left

An autonomous security reviewer embedded in every PR. Thumbs up or down on every change, in context, before anything reaches main. Zero context-switching.

GitHub / GitLab / Bitbucket CI/CD native Fix-in-context Coding agents
Kusari Agent
Agentic AI

Natural-language queries against your entire estate with zero lag. "Do we have Shai-Hulud? Which services? What's the blast radius?" Built for the speed of a zero-day.

Zero-lag query Blast-radius mapping Ownership routing MCP-ready
Kusari AutoFix
Agentic AI

Autonomous remediation that actually ships. AutoFix traces to root cause, models the full dependency tree, accounts for your environment, then submits a working fix PR.

Root-cause-aware Environment-aware Working fix PRs Approval workflows
▸ Kusari Inspector

Security in every pull request. Without the bottleneck.

Every code change gets a thumbs up or thumbs down before it reaches production. Developers see which dependencies introduce risk and an actionable remediation path — all in context, inside the tool they already live in.

  • Transitive visibility, not just direct. Inspector evaluates the full dependency tree several layers deep — not just package.json.
  • Kusari Score, not raw CVSS. Reachability, exploitability, and blast-radius weighted into one actionable number.
  • Fixes that work the first time. No "upgrade to latest" build breaks. Inspector respects your existing constraints and approval workflows.
  • Wherever your code lives. GitHub, GitLab, Bitbucket, Azure DevOps, Jenkins, CircleCI — plus CLI, IDE, and coding-agent surfaces.
PR #847 · upgrade payments service
feat/payments-v2 → main
Kusari Inspector · Blocked
347 direct · 4,212 transitive
Direct dependencies: clean
347 scanned · no critical or high findings
Transitive dependency — critical
lodash@4.17.19 via expressbody-parser
CVE-2021-23337 · Kusari Score 8.4 · Reachable · Fix: lodash@4.17.21
AutoFix suggestion (environment-verified)
-  "lodash": "4.17.19"

+  "lodash": "4.17.21"
2 checks · 1 blocking · 7.3s ▸ kusari/inspector
▸ Kusari Agent

Ask your software estate anything. In seconds.

When a zero-day drops, the first hour is everything. Kusari Agent knows your graph — every direct and transitive dependency, every service, every owner — and answers instantly. No grep, no war room, no "we'll get back to you by Friday."

  • Natural language, zero lag. Ask in English, get a structured answer with paths, owners, and blast radius.
  • Built on the Trust Fabric. Every answer is grounded in your real dependency graph — no hallucinated CVEs, no stale SBOM.
  • Wired to your workflow. Routes incidents to owners, creates Jira tickets, notifies Slack channels, kicks off AutoFix runs.
  • MCP-ready. Plug the Agent into your LLM stack, your coding agents, or your security-ops runbooks.
kusari agent — ask.your.estate
Regulatory reality

The clock is already running.

EU CRA, FDA 524B, FedRAMP, SSDF, DORA — the regulatory surface for software supply chain isn't coming. It's here. Quarterly SBOM fire drills don't scale. Kusari produces them continuously, normalized, and audit-ready.

EU CRA EO 14028 / SSDF FedRAMP FDA 524B DORA SOC 2 CMMC 2.0 PCI DSS IEC 62443 CycloneDX · SPDX · VEX
▸ EU CRA Reporting Obligations
Days
Hours
Min
"
We invest heavily in our application security, but have a gap within transitive and indirect dependencies. Last thing we want is another React4Shell and not have Kusari in place.
Security Leader · Large Healthcare Organization · BCBS Affiliate
Provenance

Built by the team behind the standards themselves.

Kusari's founders co-created the open standards now used by Google, Microsoft, Intel, Citi, and Red Hat to secure their own supply chains. The platform isn't inspired by the specs. It was architected by the people who wrote them.

That's how Kusari builds from source, not runtime — why the graph is actually complete, not approximated — and why we can integrate with any scanner, SBOM format, or pipeline you already run.

GUAC
Graph for Understanding Artifact Composition. Kusari's team partnered with Google to create it. Now an OpenSSF Incubating Project.
SLSA
Supply-chain Levels for Software Artifacts. Co-authored with Google. The baseline framework adopted across the industry.
OpenSSF
Scorecard, OSPS Baseline, and ongoing contributions to the cross-vendor working groups defining what "secure" means for OSS.
in-toto
Attestation framework contributions. The provenance and integrity infrastructure behind modern supply-chain trust.
Standards trusted by: Google Microsoft Intel Citi Red Hat Ford
Native integrations

Works with what you've already built.

Kusari is the intelligence layer above your existing stack. Ingest from every tool you already deployed — Black Duck, GHAS, Dependabot, Prisma, and more — normalized into one source of truth.

GitHub
GitLab
Bitbucket
Azure DevOps
Jenkins
CircleCI
CycloneDX
SPDX
VEX
deps.dev
OSV
Clearly Defined
Jira
ServiceNow
Slack
MS Teams
Okta / Azure AD
MCP
FAQ

Software supply chain security, explained.

What is software supply chain security?

Software supply chain security is the practice of knowing, verifying and defending every component in the software you ship: the open source packages, transitive dependencies, build tools and pipelines it is assembled from, alongside the code your team writes. Modern applications are assembled more than written. J.P. Morgan research found 95% of open source vulnerabilities live in transitive dependencies that no developer selected directly, and the average JavaScript project carries 683 transitive dependencies against 10 direct ones.

Why aren't traditional scanners enough?

Scanners inspect the finished artifact and read its manifest, which is a declaration of what the software is supposed to contain. They typically resolve about two layers of a dependency tree that commonly runs nine layers deep, and take the manifest's word for the remaining seven. Anything the scanner could not resolve is absent from the report rather than flagged as unknown, so a gap and a clean result look identical. Scanners also cannot tell you whether an artifact matches the source that produced it.

What does "verified at source" mean?

Verified at source means the dependency graph is built from your source code and build systems as software is created, rather than reconstructed from finished binaries afterwards. The difference is between recording what actually happened during a build and inferring it later from the output. Source-built evidence captures transitive dependencies, build provenance and the identity of who produced each artifact, in formats a third party can independently check.

How deep does Kusari resolve dependencies?

Kusari resolves the dependency tree from source, and states where its data is complete or incomplete rather than leaving gaps indistinguishable from clean results.

What does Kusari do?

Kusari is a software supply chain security platform. It builds a continuously updated knowledge graph of the components across your repos, images and pipelines, verified at source rather than inferred from finished binaries. It answers four questions: do we have this vulnerability, where is it running, how bad is it once reachability, exploitability and blast radius are accounted for, and how do we fix it. Reachability identifies what is live in your code paths, exploitability ranks what attackers are actually using, and remediation arrives as a fix already built and tested.

Does Kusari replace my existing scanners?

No. Kusari ingests output from the scanners and SBOM tools you already run, including Snyk, Black Duck, Prisma Cloud, Dependabot, and GitHub Advanced Security, and normalizes it into a single graph alongside evidence built from your own source. Teams run both. Scanners tell you a vulnerability exists; Kusari tells you where it actually is in your estate, whether anything can reach it, and what fixing it costs.

Who built Kusari, and what are GUAC, SLSA and in-toto?

Kusari was founded by Tim Miller, Parth Patel, and Michael Lieberman, who work on the open standards this category is built on. They co-created GUAC with Google, co-created SLSA, and maintain in-toto attestations, which originated at New York University. GUAC is a graph for software supply chain metadata. SLSA is a framework for build provenance. in-toto is a specification for verifiable claims about how software was produced. Kusari's architecture is built on these standards rather than on a proprietary format layered over them.

What is reachability analysis?

Reachability analysis determines whether a vulnerable function in a dependency can actually be called from your application's code paths. A vulnerability in a package you import but never execute is present without being exposed. At one Kusari customer, a national health insurer, reachability and exploitability analysis removed 90% of findings before anyone triaged them, leaving the queue reflecting what was genuinely exploitable.

Does Kusari help with SBOM and regulatory requirements?

Kusari produces SBOMs and attestations in SPDX, CycloneDX and in-toto formats, which a third party can independently verify. In July 2026 CISA, the NSA, the FBI and international partner agencies replaced the SBOM minimum elements, taking required data fields from 7 under the 2021 NTIA baseline to 18, including a requirement to state explicitly when information is unknown or withheld. The same underlying evidence supports EU Cyber Resilience Act, DORA, PCI DSS 4.0 and NYDFS Part 500 software inventory obligations.