Open source audit practice
Every dependency you ship is a promise you made.
We audit what your codebase actually contains — licenses, obligations, copied code, provenance — and hand you a defensible record of it. The scan runs inside your environment. Your source never leaves it.
Independent. No tool to sell you, no platform to renew — the finding is the product.
- Permissive MIT · Apache-2.0 · BSD
- Weak copyleft LGPL · MPL-2.0 · EPL
- Strong copyleft GPL-3.0 · AGPL-3.0
- Undeclared or ambiguous NOASSERTION
- Snippet matches, no declared origin 24 findings
Why audit
Four questions a build system cannot answer for you.
-
What is actually in the product?
Not the lockfile — the shipped artifact. Vendored directories, forked packages, static links, container base layers and the code someone pasted in three years ago all travel with your release.
-
What does it oblige you to do?
Attribution, source offers, notice files, patent grants, network-use clauses. Obligations attach per component and per distribution model, and they change the moment you ship on-prem instead of hosted.
-
What was copied without anyone noticing?
Snippet-level matching against a source corpus finds copied functions, relicensed files and derived code that never appeared in a manifest — including code an assistant suggested.
-
Can you prove any of it?
A regulator, an acquirer's counsel or a copyright holder will ask for evidence, not assurances. The deliverable is a dated, reproducible record with the reasoning attached.
The suite
Six audits. Run one, or run the set.
Most engagements start with a license review and grow once the first findings land. Each audit stands alone and produces its own deliverable.
-
License
License & obligation review
Every component identified, every license resolved to an SPDX identifier, every obligation mapped to how you actually distribute. Conflicts and incompatible combinations flagged with the reasoning shown.
-
SBOM
SBOM generation & attestation
Machine-readable inventories in SPDX or CycloneDX that survive a customer security review: complete, versioned, signed, and regenerable on every build rather than once for a submission.
-
Snippet
Derived-code detection
Fingerprint matching against a source corpus built in-house — Debian, the crates registry, the most-copied C and C++ projects — to surface copied and modified code no dependency manifest records.
-
Provenance
Provenance & supply-chain integrity
Where each component came from, who published it, whether the artifact you build with matches the source it claims, and where an unsigned or abandoned upstream sits in your dependency graph.
-
Diligence
Transaction diligence
Audits sized to a deal clock, for acquirers and for targets preparing to be audited. Findings written for a data room: what is disclosable, what needs remediation, what is a genuine deal issue.
-
Assisted
AI-assisted code review
Generated code carries the licensing of what it was trained to reproduce. We check assistant-authored regions against the same corpus and record what can and cannot be attributed.
Data handling
Your source code never leaves your environment.
The usual objection to an audit is handing a proprietary codebase to an outside party. This practice is built so that never happens — which is also what makes private repositories, regulated environments and pre-announcement deals workable.
The scanner comes to the code
Work happens on site or through our CLI running inside your infrastructure, against your checkout, under your access controls.
Anonymized findings, nothing else
What leaves the boundary is component metadata and match evidence. No source files, no archives, no snapshots retained after the engagement.
You can run it again without us
Findings are dated to a commit and reproducible from the same inputs, so the report holds up when someone re-runs it a year later.
Deliverables
What lands at the end of an engagement.
| Deliverable | What it contains | Who reads it |
|---|---|---|
| Audit report | Findings by severity, the reasoning behind each call, and what changes if your distribution model changes. | Engineering leadership, counsel |
| Component inventory | Complete bill of materials in SPDX and CycloneDX, versioned to the audited commit. | Security, customers, regulators |
| Obligation matrix | Component by obligation by distribution channel — what you owe, where, and to whom. | Counsel, release management |
| Notice & attribution set | Generated attribution file and the source-offer positions that go with it. | Product, release management |
| Remediation plan | Ordered by exposure and effort: replace, isolate, relicense, request an exception, or leave it alone with the reason recorded. | Engineering |
Deliverables are yours. Findings are technical and informational — an audit records what is in the code and what the licenses say; your counsel decides what to do about it.
Start with the codebase you are least sure about.
Send a rough repository count and what is driving the deadline — a submission, a customer, a transaction. You get a scope and a fixed shape of engagement back, not a discovery call.