Scan what ships.
Not the whole source tree.

A tool that helps you produce, verify, and maintain a Software Bill of Materials to satisfy regulations like the EU Cyber Resilience Act and NIS2. Most tools scan the entire source tree with regex heuristics. ABIS reverses the order: it first measures which files actually flow into the shipped product (file lineage, observed from the real build), then scans only those — and generates the SBOM from measurement instead of declaration.

A declared SBOM lists what a vendor or manifest says is in the software. A measured SBOM is generated from evidence: ABIS observes the real build via syscall tracing and toolchain dependency artifacts, derives file-to-file and file-to-package lineage, verifies the result with a reduced rebuild plus unit-test comparison, and only then generates the SBOM (CycloneDX/SPDX) from the approved graph state. Reconciling measured against declared yields two delta lists: declared-but-unused (SBOM bloat) and used-but-undeclared (a compliance alarm and supply-chain indicator).

The measured dependency chain from source file to source file to package to shipped artifact — which files actually flow into the product for a given build configuration. ABIS measures it by executing the build once under observation: every file the build opens is logged, toolchain dependency files explain why, and backwards reachability from the shipped artifact qualifies exactly the set that ends up in the product. For a Linux kernel that reduces roughly 70,000 source files to about 20,000 product files before the first license scan.

Compliance scanners analyse the complete source tree and optimise handling of the result — none of them answers whether a file actually ends up in the product. Build systems like Bazel or Nix know the lineage exactly but require migrating the build. ABIS sits in the gap: it measures lineage by observing unmodified legacy builds, verifies the reduction with a rebuild and unit tests, and then feeds established tools like ScanCode a dramatically smaller, qualified file set. It complements the incumbents instead of replacing them.

Being able to produce a complete, current Software Bill of Materials — every component, library, and dependency inside a piece of software — whenever a regulator, customer, or security team asks. In the EU, the Cyber Resilience Act makes SBOMs a requirement for products with digital elements, and NIS2 pushes the same transparency onto essential and important entities.

The Cyber Resilience Act requires manufacturers to maintain a software bill of materials covering at least top-level dependencies. NIS2 requires supply-chain security measures, and the EU AI Act adds record-keeping and transparency obligations for AI systems. Together they make supply-chain transparency a standing obligation, not a one-off audit exercise.

Yes. ABIS publishes an SBOM for every release, and the Sovereign edition ships a signed SBOM with source escrow held by a notary — so ministries, banks, and air-gapped deployments can verify exactly what runs on their hardware without trusting a vendor claim.

AI assistants and BI connectors are the newest and least-scrutinised software in most estates: they touch the most sensitive data while their own supply chain is often a black box. A self-hosted tool with a published SBOM, no telemetry, and hash-chained audit logs closes that gap — you can prove what the software is, what it did, and what data it touched.