A software composition audit is a structured review of the third-party and open source code inside a product. It produces an inventory of components, the license on each one, known vulnerabilities, and notes on upkeep. In an acquisition, buyers use it to find legal and security surprises before they sign.
What the audit looks at
The audit starts from the code and the build, not from what the seller says. Typical inputs are the source repositories, lock files, build scripts, container images and any shipped binaries.
From those, the auditor builds a list of components with versions. Each one is then checked on three axes: the license it carries, the known vulnerabilities in that version, and whether the project is still maintained.
| Axis | Question | Typical output |
|---|---|---|
| License | What terms apply, and do they fit how the product is shipped? | License per component, flagged copyleft items |
| Vulnerability | Does this version have known advisories? | List of affected components and fix versions |
| Upkeep | Is the project alive, and is the version supported? | Notes on abandoned or end of life components |
| Provenance | Where did the code come from? | Copied code, vendored folders, unknown origin |
What a scan can miss
A package manager scan sees declared dependencies. It can miss code that was copied into the repository, libraries compiled into a firmware image, and files that carry a different license from the package around them. Good audits add manual review of the vendored folders and of anything flagged as unknown.
Steps for a clean audit
- Agree scope: which repositories, which products, which shipped artifacts.
- Collect lock files, build files and release artifacts for each in scope item.
- Generate an inventory, ideally in an SBOM format so it can be checked again later.
- Resolve unknowns by reading the license files and headers in the source.
- Classify each license against the buyer's policy: allow, review, deny.
- Write up findings with the component, the file path, the license and a proposed fix.
- Agree a remediation plan and who owns each item.
The distinction between internal use and shipping matters a great deal for copyleft. The same library can be low risk in a hosted service and a real issue in a downloadable app. See internal use vs distribution for that split.
How long the findings stay true
An audit is a snapshot. New advisories are published every day, and a dependency that looked fine at signing can have a known flaw a month later. Buyers often ask for a refreshed inventory just before closing, so keep the process repeatable rather than one off.
Who needs it
Buyers ask for it, and sellers benefit from running one first. A seller who has done their own audit can answer questions quickly and fix issues on their own schedule. For a related checklist, see security due diligence for sellers.
Safeguard offers SBOM and dependency scanning plus compliance and evidence automation, which can help you keep an inventory and supporting records current. A free scan shows the inventory side.
Try it yourself
Open the dependency inventory and look at how a component list is built from a project. Note which entries carry a license and which are blank.
Click through it at your own pace, or open it full screen.
Quick check
Is a composition audit the same as a penetration test?
No. A penetration test probes a running system for weaknesses. A composition audit inventories the code you depend on and checks its licenses and known vulnerabilities.
Does it give legal advice?
No. It gives findings and evidence. Whether a finding is a legal problem is a question for counsel.
Last reviewed: 19 October 2026.
