An open source evidence pack is a small, indexed set of documents that lets a buyer or customer verify your claims about open source use. It normally holds an SBOM per release, your license policy, a log of decisions on flagged items, your notices files, and the dates of the scans behind them.
Why an index matters
Reviewers read quickly. A folder of loose files invites follow up questions. An index that says what each document proves, and when it was produced, answers many of them before they are asked.
Contents and what each proves
| Item | What it shows |
|---|---|
| SBOM for each shipped release | What components were in each version |
| License policy | The rules you apply, in plain words |
| Decision log | That flagged items were reviewed, by whom and when |
| Notices and license texts | That attribution duties are handled for shipped products |
| Scan record | The date and scope of each inventory |
| Exceptions register | Items accepted outside policy, with the reason |
| Process summary | Who owns open source review and how often it runs |
Format tips
Use common formats such as SPDX or CycloneDX for the SBOM so tools on the other side can read it. For license fields, see license fields to require in a supplier SBOM. Keep PDFs for narrative documents and structured files for data.
Keep it honest
State the scope of each document. An SBOM of one repository is not an SBOM of the company. If a part of the product was not covered, say which part and why.
A process standard such as ISO/IEC 5230 can sit in the pack as supporting context if you have adopted it, described accurately as a process standard. Do not present it as a certification of the product.
Steps to build one
- Choose the product and release in scope.
- Generate and save the SBOM and the scan record.
- Export the decision log from wherever you track findings.
- Add the policy and a one page process summary.
- Write the index with a one line purpose per item.
- Review it for anything that should not leave the company, and decide on NDA terms.
- Refresh the pack when the next release ships.
Keeping it fresh
A pack older than the latest release invites doubt. Tie its refresh to your release process, so updating it is routine, not a project. See questionnaire evidence pack folder structure for a layout you can adapt.
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 framework mapping demo and see how one piece of evidence can back several requirements. Think of each pack item the same way.
Click through it at your own pace, or open it full screen.
Quick check
Should the pack include source code?
Usually not. It holds inventories, policies and records. Code review is a separate arrangement.
Who should see the pack?
Share it under terms your legal team approves, and limit it to the people doing the review.
Sources
Last reviewed: 19 October 2026.
