Bitbison

Catch supply chain attacks
before they ship

Request early access Security for servers
Bitbison build analysis report: per-component verdicts, findings and network egress posture for one build

CVE-free is not enough

The problem

The highest-impact supply chain attacks compromise the build environment and the build process. Attacks of this class routinely go undetected for months. Some have run for years. The state of the art does not observe the build itself, which is where these attacks execute. Every incident here passed all of it, CVE-free.

Nothing in these attacks appears in a manifest. The tampering happens in the pipeline, on the runner or on the build host. A build can pass every declared-package check and still ship a compromised artifact.
No existing tool audits the complete build. Source, processes, secrets, caches and outbound connections interact as one graph. A tool that records fragments of that graph cannot judge it.
Integrity claims inherit the gap. If what the build did cannot be reconstructed, they rest on the manifest being accurate.

Real examples

Select an incident
2024 Build-time injection

xz (liblzma)

The payload entered as binary test fixtures in the release tarball (CVE-2024-3094). Build glue deobfuscated it into liblzma during compilation. There was no advisory to match and no network connection to flag. Every file was written by the build’s own processes. To a scanner, an egress control or a file monitor this was a normal build. Bitbison flags the shipped object because its bytes came from the test fixtures and not from compiled source.

Detected by Bitbison
Integration

Integration in minutes

Ephemeral runners

One line in the workflow captures every job.

On-premise servers

One package on the host captures every build.

Capture

Audit ready by default

Bitbison’s record is full fidelity. It holds every process, file operation and connection and the cause-and-effect edges between them across the entire build. Nothing is sampled and there is no event shortlist. Existing audit frameworks forego full capture because it meant runaway CPU, unbearable storage and dropped events. Bitbison removed that bottleneck.

Attempted full capture
Industry standard solutionBitbisonEVENTS LOST50%0%CPU COST100%6%DISK WRITTEN9.2 GB80 MB

A full 16-core parallel compilation of the Ubuntu Linux kernel, compared against industry-standard approaches to full-fidelity capture of a build process.

Detection

A semantic model of the build

Bitbison records every fine-grained interaction between the build and the system it runs on to construct a causally-complete graph. On that graph, Bitbison overlays build and ecosystem semantics and builds a semantic model of what the build is expected to do. Whatever falls outside the model is judged and the evidence is attached. This is how Bitbison detects attack classes that were previously undetectable.

tests/files/good-large_compressed.lzmaxzsedgawkxzliblzma_la-crc64-fast.old.bfd.libs/liblzma_la-crc64_fast.oCRITICAL FINDING
Bitbison analyzes the full lifecycle and flow of every interaction on your systems, on top of a build semantic model, to identify even difficult attack sequences such as the multi-stage xz supply chain attack.
Integrity

Whole-system integrity

In the real world, builds run on persistent infrastructure: reused runners, shared caches, installed toolchains and base images that outlive any single job. Each of these has been the target of a real supply chain attack that goes undetected until it's too late. Traditional workload protection platforms do little to protect the system itself. They do not protect the builds and their inputs at all. Bitbison monitors the integrity of the whole system. Build integrity depends on it.

build hostrunnercachetoolchainbase imagecredentialsTAMPER DETECTED
The persistent state a build inherits, monitored continuously. A foreign write to any of it is detected, with the writer named.
For developers

A security tool developers want to use

Bitbison answers build-hygiene questions from the same record it uses for security, helping you reduce code complexity and improve build times. A dependency that is compiled but never linked is visible in the record, so dead dependencies are identified from what the build actually consumed. Each finding comes with the change that fixes it, such as the manifest line to remove or the feature flag to adjust.

  • Find dead and duplicate dependencies
  • Reduce version sprawl across your dependency tree
  • Eliminate duplicate compiles and redundant build work
  • See every network fetch the build makes
Bitbison developer report: dead dependencies, version sprawl and redundant compiles for one build, each with its fix
Compliance

Go beyond compliance

Compliance, from evidence

Compliance frameworks require inventories and attestations. Bitbison generates these documents from the build record rather than from the manifest. The same record drives detection and policy. Every judgment is grounded in what the build actually did. The record covers every interaction of every build, more than these frameworks require. The underlying events are retained and available for audit.

Component inventory (SBOM)
Provenance and integrity controls
Change-management evidence
Secure development evidence
Exposure and incident reporting

Get early access

The private preview is open to a small group of teams. Ask for early access or a demo and we will reach out.

No spam. We will only email you about early access.