The audit suite

Each audit answers one question completely, and produces evidence you can hand to someone else.

Scope is set per repository and per distribution model, not per seat. Run a single audit against one product line, or the full set across a portfolio.

License

License & obligation review

The core audit. Every component in the shipped artifact is identified and its license resolved to an SPDX identifier — including the components that never appear in a manifest because they were vendored, forked, statically linked or inherited from a base image. Obligations are then mapped against how you actually distribute: hosted, on-premises, embedded in hardware, or all three at once with different answers for each.

  • Component identification across declared dependencies, vendored trees and build inputs
  • License resolution with the evidence for each call, including dual-licensed and relicensed components
  • Obligation mapping per distribution channel — attribution, source offer, patent, network use
  • Incompatibility and conflict findings, ranked by exposure rather than by count
  • Policy fit: where your existing approval rules would have caught it, and where they missed

Deliverable

Audit report, component inventory, obligation matrix, notice set and a remediation plan ordered by exposure.

Run it when

You are about to ship on-premises for the first time, a customer sent a license questionnaire, or nobody can say what changed since the last review.

AGPL-3.0 MPL-2.0 Apache-2.0

SBOM

SBOM generation & attestation

Most SBOMs fail the moment somebody reads them closely: components missing, versions unresolved, relationships flattened, no author or timestamp, and no way to regenerate the file. We produce inventories that hold up to a customer security review or a regulatory submission, and leave the generation wired into your build so the next one is not another project.

  • SPDX 2.3 and 3.0, CycloneDX 1.6, generated from build inputs rather than guessed from a lockfile
  • Completeness check against the minimum elements regulators and customers actually test for
  • Relationship accuracy — contains, depends-on, static versus dynamic linking
  • Signing and attestation so the document proves who produced it and when
  • Pipeline integration, so an SBOM ships with every release build

Deliverable

Signed SBOMs per artifact, a completeness report against the target standard, and the pipeline configuration that regenerates them.

Run it when

A submission, tender or enterprise contract requires one — or your current SBOM was generated once, by hand, and is now out of date.

SPDX 2.3 CycloneDX 1.6

Snippet

Derived-code detection

Dependency scanning only finds what someone declared. The findings that break deals are copied functions, files with the header stripped, and forks that quietly diverged from a copyleft upstream. We match your source against a fingerprint corpus built in-house — Debian, the crates registry, the most-copied C and C++ projects — at the level of code fragments, not package names.

  • Fragment-level fingerprint matching against a multi-terabyte source corpus
  • Fork divergence: what your copy inherited, and which upstream license came with it
  • Removed or altered license headers, surfaced with the original text
  • Public-forum and sample-code attribution, held separately from the open source corpus
  • Each match carries the evidence — file, span and matched origin — for review, not just a score

Deliverable

Match report with per-finding evidence, an origin trace for each confirmed match, and a disposition recommendation.

Run it when

Before a transaction, after an acquisition, or when an engineering team has grown faster than its review process.

Fragment match Origin trace

Provenance

Provenance & supply-chain integrity

Knowing a component's name and version says nothing about where it came from. This audit traces each dependency back to a publisher and a source revision, checks that the artifact you build with corresponds to the source it claims, and marks the places where an unmaintained or single-maintainer upstream sits on a critical path.

  • Upstream tracing: publisher, repository, tag and the gap between them
  • Artifact-to-source correspondence for the components that matter most
  • Signature and attestation coverage across the dependency graph
  • Maintenance risk — abandoned, single-maintainer and recently transferred projects
  • Transitive concentration: which few upstreams your product actually rests on

Deliverable

Provenance report, signature coverage map, and a ranked list of supply-chain concentration risks.

Run it when

You are answering a supply-chain security questionnaire, or you ship into an environment where the origin of every binary has to be stated.

Attestation Upstream risk

Diligence

Transaction diligence

Deal-clock audits, run for either side of the table. On the buy side, the question is whether the target's code carries an obligation that changes what the acquirer can do with it. On the sell side, the work is finding those answers first, remediating what is cheap to remediate, and being able to answer the buyer's scanner with a document rather than a scramble.

  • Scoped to the deal timeline, with an interim read before the full report
  • Findings framed as deal issues: disclosable, remediable, or material
  • Copyleft exposure assessed against the acquirer's intended distribution, not the target's
  • Derived-code detection included by default — this is where it usually matters
  • Data-room-ready formatting, and a short version for people who will not read the long one

Deliverable

Diligence report with an executive summary, a findings register, and a remediation plan priced by effort.

Run it when

An LOI is signed, a raise is starting, or the board has asked what the code actually contains.

Buy-side Sell-side prep

Assisted

AI-assisted code review

Assistant-generated code enters the repository with no manifest entry, no license header and no memory of what it resembles. The audit question is not whether a team uses assistants — it is whether the resulting code can be attributed, and whether any of it reproduces a licensed work closely enough to matter.

  • Fragment matching across assistant-authored regions using the same corpus as the snippet audit
  • Attribution findings recorded with evidence, so a reviewer can accept or reject each one
  • Contribution policy review — what your current rules require, and what they cannot see
  • Practical controls: pre-commit checks and review gates that engineers will actually keep

Deliverable

Attribution findings report, policy gap review, and the check configuration to keep it from recurring.

Run it when

Assistant use went from experiment to default, and nobody has audited what landed since.

Attribution Policy

Engagement

Scoped in tiers, so the first pass is not the whole estate.

Portfolios are rarely uniform. Repositories that ship to customers carry far more exposure than internal tooling, so scope is tiered and priced to match.

Tier What sits here Depth
Tier 1 Code that reaches customers — distributed products, on-premises and embedded builds, anything a customer deploys themselves. Full audit, derived-code detection included
Tier 2 Hosted services and control planes — obligations differ, and network-use clauses become the live question. Full license and obligation review
Tier 3 Public repositories, internal tooling and everything else in the organization's namespace. Inventory pass with exceptions escalated

Engagements are time and materials against an agreed scope, or a fixed fee once the tiering is settled. Either way the scope is written down before work starts.

Get a scope How the work runs