Probably not yet for most teams. The Transparency Exchange API, or TEA, is a standard in progress for exchanging SBOMs, VEX files, and attestations between systems. If you have few customers, a stable download URL and a dated index do the job. Look at TEA when automation requests start to pile up.
What TEA is
The project's README describes TEA as a standard, format-agnostic API for exchanging product-related artifacts such as bills of materials between systems. It says upstream vendors and open source projects can use it to keep downstream consumers up to date with transparency artifacts, including BOMs, VEX files, and attestations. The scope covers discovery of servers using a Transparency Exchange Identifier, retrieval of artifacts, publication, authentication and authorization, and querying.
Its data model
The README describes these objects.
| Object | Meaning |
|---|---|
| Product | Groups releases for a product line or family |
| Product Release | The main entry point; an identifier resolves to one or more |
| Component | A lineage of component releases |
| Component Release | One release of a component, with its own collection |
| Collection | A versioned list of artifacts for a release |
The versioning of collections is the useful idea: a release has a list of artifacts, and the list itself has versions when something changes, for example when a VEX file is added.
Status to check before you commit
At the time of writing, the README says the standard is being worked on within Ecma technical committee 54 with the goal of standardization, that it is in beta 2, and that the beta focuses on the consumer side of the API, with work on the publisher API starting after the 1.0 release. Check the repository for current status before you plan around it. A beta can change.
Decision guide
| Your situation | What to do now |
|---|---|
| Fewer than a dozen customers asking for SBOMs | Stable URLs per release and a dated index |
| Many customers asking for the same files | Automate delivery with a documented HTTPS endpoint |
| Customers ask for TEA by name | Read the spec, test against the beta, and tell them your timeline |
| You are building an SBOM platform | Follow the spec and take part in interoperability tests |
Make future adoption easy
Even without TEA, you can prepare.
- Give every release a stable identifier and URL.
- Keep SBOMs, VEX files, and advisories in one place per release.
- Version your artifact lists when you add or change items.
- Use common component identifiers such as Package-URL.
- Keep a history, so a consumer can see what changed.
CISA's 2026 minimum elements also describe API delivery as one valid way to share SBOMs, along with version-specific URLs and public repositories, so a plain endpoint remains acceptable while standards settle.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the inventory a release would carry. TEA would be the way to hand it on.
Where Safeguard fits
Safeguard's SBOM and dependency scanning produces inventories in standard formats. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is TEA a final standard?
Its README described it as in beta at the time of writing, so check the repository for current status.
Can I share SBOMs without TEA?
Yes. CISA's guidance lists version-specific URLs, APIs, and public repositories as valid ways to share.
Sources
- Transparency Exchange API, CycloneDX on GitHub
- 2026 Minimum Elements for a Software Bill of Materials (SBOM), CISA
Last reviewed: 19 October 2026.
