How Capa compares
Where Capa sits among the capability-typed languages and among the existing sources of capability claims. Everything on this page tracks docs/positioning.md in the compiler repository, which is the canonical version; this page was last reviewed against it in June 2026, and the statements about other projects reflect their public state at that date.
The property being compared
Comparing an SBOM's capability claims against a policy file is roughly thirty lines of code in any language. The pipeline downstream of the claims is not the interesting part. The interesting part is upstream: where do the claims come from, and why should an auditor believe them? Capa's answer is that the compiler refuses to ship a program whose actual code reaches an authority its declaration omits, so the declaration is a bound on behaviour rather than a report about it. Every row below is compared against that one property.
Where capability claims come from today
In the ecosystems that have capability claims at all, the claims come from one of three places.
| Source | What an auditor actually gets |
|---|---|
Author-declared manifests (npm permissions, Deno --allow-*, AndroidManifest.xml) |
The runtime enforces the list, but the static picture depends on the author being honest and complete; in practice a previous release's manifest gets copy-pasted forward and the discrepancies accumulate. |
| Heuristic static analysis (CodeQL, Semgrep, Joern, Slither) | Output with both false negatives (unmodelled indirect calls; adversarial code can route around the analyser deliberately) and false positives, so "no Net usage detected" cannot be distinguished from "the analyser missed it". |
| Runtime observation (seccomp, the Linux audit subsystem, Deno's prompts, eBPF tracing) | A record of what the program did during the runs that were observed, which says nothing about what it could do on a path no test exercised. |
| Capa | A declaration that lists every authority the function could possibly use, with a compiler that rejects any program whose code reaches an authority the declaration omits; the auditor re-derives the SBOM from source with capa --cyclonedx and needs no second analyser. |
Adjacent languages
Capability typing predates Capa by decades, and several language families have explored it. One sentence on each, and on how it relates to Capa's use case.
| Language / system | One-sentence comparison |
|---|---|
| Pony | Reference capabilities (iso, trn, ref, val, box, tag) govern aliasing and data-race freedom in an actor model: the same intellectual family, aimed at concurrency safety rather than external-authority audit. |
| Koka, Eff, OCaml 5 effect handlers | An effect row that includes <net> is shape-equivalent to a function taking a Net parameter, but the ecosystems are research-grade and there is no SBOM tooling story today. |
| Haskell | Phantom types and the ReaderT-of-capability-record pattern get close to the same soundness property, but as a library convention rather than a language guarantee: any contributor who imports IO directly bypasses it. |
| Roc | Capabilities arrive through the platform (the platform provides effectful primitives, the program receives them as values), which makes Roc the closest in spirit among production-aimed new languages; it is still pre-1.0 and the SBOM angle has not been explored upstream. |
| WebAssembly Component Model + WIT | A component's WIT imports are a genuine, machine-readable capability surface, at module granularity rather than function granularity; Capa compiles to Wasm-CM, so the two are complementary rather than competing. |
| Zero (Vercel Labs, May 2026) | The only other language with capability-based I/O as its headline: a systems language in the C / Rust space whose toolchain emits stable error codes and typed repair categories for AI-agent repair loops, so it shares Capa's root and splits on audience (AI-agent toolchain vs supply-chain auditor). |
The function-vs-module granularity point in the Wasm row is the one that matters most for audit work: most CVEs are caused by a small set of functions inside an otherwise-trusted module, and a module-level import list cannot isolate them.
What Capa cannot claim
A comparison page that only lists wins is marketing. The other column, from the same positioning document:
- The mechanism is not new. Capability typing is decades old and well-understood; Capa's contribution is the combination (discipline by construction feeding machine-verifiable per-function audit artefacts), not the primitive.
- It is a one-person project. Capa is at 1.10 with a stability commitment, but there are no industrial adopters and no third-party libraries.
- The default runtime is CPython, with measured overhead between 1.00x and 1.45x against hand-written Python on the benchmark suite; the Wasm Component Model backend covers native AOT execution, and a dedicated LLVM backend is deliberately deferred.
- The ecosystem is shallow. There is a CLI, an LSP server, a formatter, the SBOM emitters and diff tooling, a package manager with a signed registry index, and a small standard library; there is no debugger story beyond CPython's.
- The Wasm Component Model competes for the same role at module granularity, with a much larger ecosystem behind it.
Where to go next
Read the full positioning document →
The canonical, maintained version of everything on this page, including the thesis in one sentence.
Why Capa exists →
The case against ambient authority, with runnable code rather than comparisons.
The audit artefacts →
What capa --manifest, --cyclonedx, --spdx, --vex, and --provenance emit.
See it on an LLM agent →
A worked example where the per-function capability bound is the security argument.