Ecma TC54 Explained: The Committee Behind CycloneDX, purl, TEA and CLE

Ecma TC54 is the technical committee of Ecma International, the Geneva standards body, that turns software transparency specifications into formal standards. It was established in December 2023. It publishes CycloneDX as ECMA-424, Package URL (purl) as ECMA-427 and Common Lifecycle Enumeration (CLE) as ECMA-428, and its task groups are still writing the Transparency Exchange API (TEA), the VERS version range syntax and a project health format called Contributing.yaml.

If you produce or consume SBOMs, TC54's decisions show up in your files: the purl in every component entry, the CycloneDX schema your tools validate against, the lifecycle events that say when fixes stop, and the API a supplier may one day use to hand you all of it. This post explains how the committee is organised, what it has published, how a community specification becomes an Ecma and then an ISO/IEC standard, and how to take part.

Key takeaways

• Ecma International is a 65 year old, Geneva based standards body. It was founded on 17 May 1961 as the European Computer Manufacturers Association, renamed Ecma International in 1994, and its by-laws commit it to publishing standards free of charge. It is best known for ECMAScript (ECMA-262).
• TC54 was established in December 2023 with a scope of standardising "core data formats, APIs and algorithms" for software transparency. It works under Ecma's Royalty-Free Patent Policy.
• TC54 runs four task groups. TG1 writes the Transparency Exchange API. TG2 writes Package URL, the VERS version range syntax and the process for purl types. TG3 writes Common Lifecycle Enumeration. TG4 writes Contributing.yaml, a machine-readable statement of an open source project's maintenance state. The CycloneDX core specification is reviewed by TC54 itself.
• Three standards are published. ECMA-424 (CycloneDX) has two editions: the 1st edition of June 2024 covered CycloneDX 1.6, and the 2nd edition, approved on 10 December 2025, covers CycloneDX 1.7. ECMA-427 (Package URL 1.0) and ECMA-428 (CLE 1.0.0) were approved the same day as 1st editions.
• The ISO/IEC route is fast-track. Ecma has a Category A liaison with ISO/IEC JTC 1 and, in Ecma's words, "uses the JTC 1 fast-track procedure". Ecma's own pages list ECMA-424 as ISO/IEC DIS 27055 and ECMA-427 as ISO/IEC DIS 27056, which means both are at the draft international standard stage, not yet published ISO/IEC standards.
• You do not need to pay to contribute. Specifications are written on public GitHub and discussed in the CycloneDX Slack. Voting needs Ecma membership; individuals can be invited experts; not-for-profits join for CHF 0.
• The outputs interlock. purl identifies a component, CycloneDX describes what a product contains, CLE records a component's lifecycle, and TEA tells a consumer where to fetch all of it for a product release.

This post goes one level deeper than our earlier pieces on the individual formats. For the edition history of CycloneDX itself, see CycloneDX versions explained, 1.0 to 1.7 and ECMA-424. For the question of whether an SBOM format counts as "official", see is an SBOM format an official standard? ECMA-424 and ISO 5962. For purl basics, see what is a Package URL (purl) in an SBOM. For whether to adopt TEA today, see do you need the Transparency Exchange API yet. CLE has its own deep dive in end of life data formats explained: OpenEoX and Common Lifecycle Enumeration, so this post covers CLE only where it touches the committee.

What is Ecma International?

Ecma International is a non-profit industry association that develops standards for information and communication technology. Its history page explains that by 1959 computers from different manufacturers could not share programs or data. On 27 April 1960 European computer manufacturers met in Brussels and decided to form the European Computer Manufacturers Association, headquartered in Geneva to sit near the IEC, ISO and the ITU. The association came into being on 17 May 1961. In 1994 it became "Ecma International", keeping "Ecma" as a name rather than an acronym.

Three features of Ecma's constitution matter for anyone who uses its standards.

Standards are free to read. Article 2 of the by-laws (December 2025 edition) commits Ecma to publish standards "free of charge". Every TC54 standard is a free PDF, and each points to a live HTML version that the standard calls "the most accurate and up-to-date" text.

Adoption needs two thirds of the ordinary members. Article 9 requires approval "by at least two thirds of all the ordinary members", with drafts available at least two months before the vote. Votes happen at the General Assembly in June or December, which is why TC54 standards carry those months.

Implementation is voluntary. The same article says no member must implement an Ecma standard. It binds you only when a contract, procurement rule or regulation points to it.

Ecma's best known output is ECMA-262, the ECMAScript language specification, written by TC39. That is relevant to TC54 in a practical way: ECMAScript is developed in the open on GitHub, with a markup format called ecmarkup that renders the specification as HTML. TC54's GitHub organisation carries its own copy of ecmarkup, and each TC54 standard points readers to a GitHub repository for issues and pull requests.

How Ecma is organised

Work happens in technical committees (TCs), which can form task groups (TGs) for specific deliverables. The Ecma Rules (August 2024 edition) set the mechanics:

Ecma also maintains formal relationships with other standards bodies. Its own presentation on standardisation (dated January 2026) says it has a Category A liaison relationship with ISO/IEC JTC 1, gives it the "ability to propose Ecma standards as international standards", and that it "uses the JTC 1 fast-track procedure". The Ecma Directives (February 2026), which govern how Ecma documents are drafted, refer to the ISO/IEC Directives Part 2 for wording and terms, recommend ISO/IEC style titles, and tell editors to consider how a document will be split into parts "when it is envisaged to contribute the Ecma Standard or TR to ISO/IEC, e.g. for fast-track processing".

Why software transparency standards landed at Ecma

Nobody published a single document explaining the choice, so the following is our reading of the public record rather than a quoted rationale. Five things line up.

1. Royalty-free patents. The TC54 page says the work "intends not to use patents or if so then only royalty free patents". A shared identifier syntax with royalties attached would be useless.
2. Free publication. A format written into procurement contracts and implemented by small open source tools cannot sit behind a paywall.
3. A fast path to ISO/IEC. The Category A liaison lets an Ecma standard go to JTC 1 as a draft without being rewritten in a JTC 1 working group.
4. Open source experience. Ecma lists "cooperation with Open Source" as a strength, with ECMAScript as the reference case.
5. Speed to start. Ecma says new work can start within two weeks of provisional approval by its Executive Committee.

The community projects stayed where they were. CycloneDX is still an OWASP flagship project and Package URL still has its own community; TC54 adds a formal review and publication layer on top.

When was TC54 formed, and what is it chartered to do?

The TC54 history page on tc54.org dates the committee's establishment to December 2023, describing it as the first working group "chartered with holistic supply chain goals of standardizing core data formats, APIs, and algorithms that advance software and system transparency". The committee's formal name on the Ecma site is "TC54: Software and system transparency".

The scope statement on Ecma's TC54 page defines software transparency broadly: information about the components and dependencies inside software, how the software was manufactured, and the behaviours observed or attestations made by the organisation that built it. It names the Bill of Materials as the critical tool. The programme of work lists five items:

1. A standard for the CycloneDX software transparency and Bill of Materials specification.
2. A standard for the Transparency Exchange API (Project Koala) for discovering and sharing transparency information.
3. A standard and guidance for multiple BOM merging algorithms.
4. Investigating further standards in the software transparency space.
5. Evaluating proposals for complementary or additional technology.

Item three matters in practice: combining an application's SBOM with those of its base image and its vendors is a common problem, and no merging standard has been published yet.

At the time of writing, Ecma's TC54 page lists a two person chair group, Chris de Almeida and Alyssa Wright, and the Ecma Secretary General, Samina Husain, as secretary.

Which task groups does TC54 run?

The Ecma site, the TC54 GitHub organisation and tc54.org together give a consistent list of four task groups. Each has its own repository under the Ecma-TC54 organisation on GitHub, and each specification page on tc54.org names the task group that owns it.

TC54 plenary: CycloneDX

CycloneDX has no separate task group. The tc54.org contribute page describes how the work is split. The OWASP Core Working Group owns the CycloneDX project as a whole: the specification, the tools and libraries, and maintainer onboarding. An invite-only Industry Working Group of implementers gives feedback from real use. Feature Working Groups build large new features. Ecma TC54 is described as "responsible for final technical reviews of CycloneDX features and specification versions". In other words, a CycloneDX feature is designed in the OWASP community and then reviewed and adopted by TC54 before it becomes part of an ECMA-424 edition.

TC54-TG1: Transparency Exchange API

Ecma's TG1 page says the group is chartered to develop "a standardized, format-agnostic API that enables the efficient discovery and exchange of Bills of Materials (BOMs) and other related artifacts between systems". Its programme of work includes the API architecture and data models for xBOM, CycloneDX Attestations (CDXA), VDR and VEX, CLE and a query feature called insights. The convenor listed is Steve Springett. The specification lives in the CycloneDX organisation on GitHub (transparency-exchange-api), with an Ecma-TC54 repository named ECMA-xxx-TEA "renamed once an ECMA identifier is assigned".

TC54-TG2: Package URL and VERS

The TG2 repository describes three pieces of work: the PURL specification itself, the VERS specification for version ranges, and the standardisation of purl types (the per-ecosystem rules for maven, npm, pypi and the rest). Its programme of work also includes a "clear and transparent process" for accepting new purl types and a release process for completed types. This split explains why ECMA-427 contains no type definitions: the standard fixes the syntax and the schema for defining a type, while the types themselves are maintained as JSON files in the purl-spec repository and can be added without reopening the standard.

TC54-TG3: Common Lifecycle Enumeration

ECMA-428's introduction says CLE 1.0.0 was developed "under the auspices of Ecma International Technical Committee 54, Task Group 3 (TC54-TG3)". The standard lists three editors and points contributors to the Ecma-TC54/ECMA-428 GitHub repository. It also notes that it inlines the VERS syntax "pending standardization", which is a small but real example of how the task groups depend on each other. For the format itself, see our OpenEoX and CLE deep dive.

TC54-TG4: OSS Sustainability and Contributing.yaml

TG4 is the newest group and the one most people have not heard of. Its scope, from the TG4 repository, is to standardise "Contributing JSON, an open contributions specification" for machine-readable statements of an open source project's state, needs and support intentions, including maintainers' support levels and abandonment or handoff status. The tc54.org page calls the same work Contributing.yaml and says its aim is to support "software supply chain risk assessment, organizational investment decisions, and community sustainability efforts". The repository README lists Chris de Almeida and Piotr P. Karwasz as convenors.

The name is not settled (JSON in the repository scope, YAML on the website). The intent is clear: today "is anyone maintaining this package?" is answered by reading commit graphs and guessing, and TG4 wants maintainers to answer it themselves in a file tools can read.

What has TC54 published?

Here is the record, with each date taken from Ecma's own pages, the standards' title pages, or the tc54.org history page.

ECMA-424: CycloneDX

The ECMA-424 page describes the current edition as defining "the CycloneDX v1.7 Bill of materials specification", covering software and hardware components, services, dependencies, vulnerabilities, compositions, cryptographic artefacts, machine learning models, attestations and licensing. The page lists two editions, "1st edition, June 2024" and "2nd edition, December 2025", each a free PDF. The tc54.org CycloneDX page gives the 2nd edition's publication date as 2025-12-10 and the registered media types as vnd.cyclonedx+json and vnd.cyclonedx+xml.

Two details are worth knowing before you cite it.

First, the standard defines the JSON serialisation. The ECMA-424 page says the BOM "is serialised using a machine-readable JSON format". CycloneDX the OWASP project also publishes XML and Protocol Buffers schemas, so a BOM can be valid CycloneDX 1.7 without being in the form ECMA-424 describes. If a contract says "ECMA-424", deliver JSON.

Second, the 2nd edition's own overview says CycloneDX "in December 2025, was formally adopted as an Ecma International Standard". That sentence reads as if the first adoption happened in December 2025, which sits awkwardly with the 1st edition of June 2024 listed on the same Ecma page. The most likely reading is that the sentence refers to the edition in hand; when you need the first date, use June 2024 and cite the Ecma page.

The CycloneDX 1.7 JSON schema requires only two top-level fields, bomFormat (which must be "CycloneDX") and specVersion. Each component requires only type and name. Everything else, including version, purl and bom-ref, is optional in the schema, which is why "valid CycloneDX" and "useful CycloneDX" are different claims.

ECMA-427: Package URL

ECMA-427's page defines purl as "a valid URL and URI composed of seven components to identify a software package", and states that the standard "specifies the syntax for PURLs and the schema for defining PURL types, but it does not include any specific PURL type definitions". The tc54.org purl page gives the 1st edition date as 2025-12-10, the specification version as 1.0 and the owning group as TC54-TG2, and it names the PURL community and Ecma together as developers.

The seven components, from the purl-spec README, are:

scheme:type/namespace/name@version?qualifiers#subpath

The scheme is always pkg. Type and name are required; namespace, version, qualifiers and subpath are optional. Clause 5 of ECMA-427 sets the parsing and canonical form rules, and several of them are what make purls comparable across tools:

• The type is case insensitive and its canonical form is lowercase.
• Leading and trailing slashes in namespace, name and subpath are not significant and should be stripped.
• Namespace segments, the name, the version and subpath segments are percent-encoded strings, using the RFC 3986 mechanism.
• Qualifier keys must use only lowercase ASCII letters, digits, period, dash and underscore, must start with a letter, must not be percent-encoded and must be unique. A qualifier with an empty value is treated as if it were absent.
• "Implementations shall ensure that equivalent PURLs are consistently resolved to the same canonical representation."

Ecosystem rules sit in the type definitions. The pypi type, for example, says names are not case sensitive and must be lowercased with underscores replaced by dashes, because PyPI treats - and _ as the same character. The npm type's examples show that a scoped package keeps its @ percent-encoded: pkg:npm/%40angular/animation@12.3.1.

The purl-spec README also records that purl was added to the CVE Record Format at version 5.2.0, so the same identifier can now appear in a CVE record, an SBOM and a lifecycle document.

ECMA-428 and what is not published yet

ECMA-428 defines CLE 1.0.0, a JSON format for component lifecycle events, approved alongside ECMA-427; our CLE and OpenEoX post covers it in depth.

TEA has no Ecma number. Its README says it is in "Beta 2", focused on the consumer side, with the publisher API to follow the 1.0 release. The OpenAPI document declares API version 1.0.0, the version clients put in request paths, not a sign the standard is final. VERS and Contributing.yaml are "In Development" on tc54.org, with placeholder repositories (ECMA-xxx-VERS, ECMA-xxx-CONTRIBUTING). We found no public draft of the BOM merging standard.

How does a specification become an Ecma standard, and then an ISO/IEC standard?

The path has two halves. The first half happens inside Ecma and is fully documented in its by-laws and rules. The second half happens inside ISO/IEC JTC 1 and is only partly visible from outside.

Inside Ecma

Step 1 is where almost all of the technical substance is decided. By the time a CycloneDX version reaches the General Assembly it has already been released by OWASP: CycloneDX 1.6 shipped in April 2024 and became ECMA-424 in June 2024; CycloneDX 1.7 shipped in October 2025 and became the 2nd edition in December 2025. Ecma adoption is the formal stamp on a specification the community already uses, not the place where it is invented.

From Ecma to ISO/IEC: fast-track, not PAS

ISO/IEC JTC 1 accepts standards developed elsewhere through two routes, and it is easy to mix them up.

The Publicly Available Specification (PAS) route is for organisations that JTC 1 has approved as PAS submitters. JTC 1 publishes the list. The June 2026 version includes OASIS (reaffirmed through December 2030), W3C, the Joint Development Foundation, the Eclipse Foundation and others. The Linux Foundation appears under "Former Submitters" with status that expired in May 2008. Ecma is not on the list.

The fast-track route is for organisations with a Category A liaison to JTC 1. Ecma's presentation says it has that liaison and "uses the JTC 1 fast-track procedure which accelerates the path to approval and publication of the ISO/IEC standard", and calls itself "one of the very few standards-setting organizations having this relationship". In practice, a published Ecma standard is submitted to JTC 1 and goes to ballot as a draft international standard, skipping the earlier working draft and committee draft stages.

That is where TC54's work currently sits. The Ecma ECMA-424 page lists its ISO/IEC number as "DIS 27055", and the ECMA-427 page lists "DIS 27056". DIS stands for draft international standard. The purl-spec README says purl "is in process to also become an ISO standard", which agrees. ECMA-428 has no ISO/IEC number on its page.

We could not confirm the ballot dates or results for DIS 27055 and DIS 27056 on iso.org, which blocked our scripted requests, so we are not stating a date for ISO/IEC publication. If you need to cite an ISO/IEC number in a contract today, the honest wording is "ECMA-424, submitted to ISO/IEC JTC 1 as DIS 27055", not "ISO/IEC 27055".

How SPDX took the other road

The comparison is useful. On 9 September 2021 the Linux Foundation, the Joint Development Foundation and the SPDX community announced that the SPDX specification had been published as ISO/IEC 5962:2021. The Joint Development Foundation is on JTC 1's approved PAS submitter list. So both major SBOM formats have an ISO/IEC path, through different doors: SPDX arrived as a published ISO/IEC standard in 2021, while CycloneDX is in the DIS stage through Ecma's fast-track.

How can companies and individuals take part?

There are three levels of participation, and most people only need the first.

Level 1: community contribution, free and open

All four task groups and the CycloneDX project work in public:

• GitHub. The Ecma-TC54 organisation hosts repositories for ECMA-424, ECMA-427, ECMA-428, the TEA and VERS drafts, the Contributing specification, plenary meeting agendas and minutes, and one repository per task group. The CycloneDX organisation hosts the TEA specification and the CycloneDX schemas. The package-url organisation hosts purl-spec, including the type definitions.
• Slack. The tc54.org contribute page says TC54 "primarily communicates via Slack and utilizes the same Slack instance as CycloneDX", with channels per specification and working group, and invites open to anyone.
• Meetings. Task group calls are listed on tc54.org with times and video links. At the time of writing tc54.org lists a TG1 call on 4 November 2026, a TG2 call on 6 November, a purl community call on 28 October, a TG3 call on 29 October and a TG4 call on 5 November. The TEA repository says its biweekly meetings are recorded to a public playlist, and the contribute page says CycloneDX working group meetings are recorded and public.

Anyone can open an issue, comment on a pull request or join a call. The limit is on technical contributions that end up in the standard: the TG4 README says that individuals making technical contributions "must agree to Ecma's IPR agreements", usually by being a delegate of an Ecma member or an invited expert. That is the royalty-free patent policy doing its job.

Level 2: invited expert

Ecma Rules 7.2.6 lets individuals participate in a TC "as invited experts", at the invitation of the Secretary General at the TC's request, without voting rights, after signing the relevant Ecma policy forms. This is the normal route for an independent maintainer of a purl library or an SBOM tool who is not employed by an Ecma member.

Level 3: Ecma membership

The Ecma "Join" page lists five membership classes and their annual fees:

Every class can send representatives to TC meetings, and within a TC each member organisation has one vote (Rules 7.2.3). Only ordinary members vote on adopting a standard at the General Assembly. Applications are voted at the next General Assembly, in June or December, and the Join page says that while an application is pending, the applicant's representatives may attend TC and TG meetings as guests.

For a small security tooling company, the SPC class is the practical door. For a foundation or a university, NFP membership costs nothing. For a large software buyer that wants a vote on whether a new edition is adopted, only ordinary membership gives one.

How do TC54's outputs connect?

The cleanest way to see TC54's portfolio is as answers to separate questions about one product.

The links between them are explicit in the documents.

• purl is the join key. CycloneDX components carry a purl field. CLE documents name their subject by purl, per the ECMA-428 introduction, which says CLE complements "the Package-URL (PURL) specification for component identification". TEA has a registered TEI type purl, and its /productReleases and /componentReleases queries accept idType=PURL.
• VERS expresses ranges. CLE uses VERS ranges for version constraints, and CycloneDX 1.7 components have a versionRange field.
• TEA carries the documents. The TEA README lists xBOM, CDXA, VDR and VEX, and CLE as artefact families. TEA's artefact type list in the OpenAPI document includes BOM, VULNERABILITIES, ATTESTATION, RELEASE_NOTES, LICENSE, SECURITY_TXT, THREAT_MODEL and others.
• CLE has a TEA projection. TEA exposes /cle endpoints on products, product releases, components and component releases. The README is careful to say these return "a TEA projection of CLE event content", not a full CLE 1.0.0 document. A publisher who needs to ship a bit-identical CLE document publishes it as an ordinary TEA artefact, of type OTHER until a dedicated type exists.

One more relationship is often missed. TEA is format agnostic. The README describes "a BOM format agnostic way of publishing, searching, and retrieval", says the API itself does not restrict artefact types, and says the initial focus for vulnerability information is CycloneDX VDR and VEX and OpenVEX, because CSAF "has its own distribution requirements that may not be compatible with APIs". So TC54's distribution API does not lock you into TC54's content format.

Walkthrough: one component through purl, CycloneDX and TEA

This walkthrough follows a single component through the three published or near-published TC54 specifications, using each specification's own examples so you can check every step against the source. We use the npm package @angular/animation at version 12.3.1, because it is the scoped package example in both the purl README and the npm type definition, and scoped names are where hand-written purls most often go wrong.

You need a shell with curl, python3 and jq. Nothing here modifies a system.

Step 1: write the purl and check its canonical form

Start from the parts:

That gives pkg:npm/%40angular/animation@12.3.1, which matches the example in the npm type definition exactly.

To check a purl in code rather than by eye, use a purl library. The package-url organisation maintains libraries in several languages. With the Python one:

python3 -m venv .venv
. .venv/bin/activate
pip install packageurl-python

python3 - <<'EOF'
from packageurl import PackageURL

p = PackageURL.from_string("pkg:npm/%40angular/animation@12.3.1")
print("type:     ", p.type)
print("namespace:", p.namespace)
print("name:     ", p.name)
print("version:  ", p.version)
print("canonical:", p.to_string())
EOF

The parsed namespace comes back decoded as @angular, and the canonical string comes back with %40angular. If a tool wrote pkg:npm/@angular/animation@12.3.1 with a literal @, parsing it and calling to_string() returns the canonical form; do that before you compare purls from different tools, or one package will look like two. The same round trip applies the pypi type's rules (lowercase, _ becomes -), so pkg:pypi/Django_Allauth@12.23 comes back as pkg:pypi/django-allauth@12.23. We ran both checks with packageurl-python while writing this post.

Step 2: put the component in a CycloneDX 1.7 BOM

A minimal CycloneDX 1.7 JSON document needs only bomFormat and specVersion, but a useful one names the component with a stable bom-ref and a purl. Save this as bom.json:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-24T09:00:00Z",
    "component": {
      "type": "application",
      "bom-ref": "app",
      "name": "example-web-app",
      "version": "4.2.0"
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/%40angular/animation@12.3.1",
      "group": "@angular",
      "name": "animation",
      "version": "12.3.1",
      "purl": "pkg:npm/%40angular/animation@12.3.1"
    }
  ],
  "dependencies": [
    { "ref": "app", "dependsOn": ["pkg:npm/%40angular/animation@12.3.1"] }
  ]
}

A few choices here follow from the specification:

• serialNumber must match the pattern urn:uuid: followed by a lowercase UUID, per the 1.7 schema.
• type must be one of the schema's enumerated values. In 1.7 those are application, framework, library, container, platform, operating-system, device, device-driver, firmware, file, machine-learning-model, data and cryptographic-asset.
• Using the purl as the bom-ref is a common convention, not a rule. It keeps references readable and stable across regenerations, as long as the same purl does not appear twice in one BOM.

Quick structural checks with jq:

# Format and version
jq -r '.bomFormat + " " + .specVersion' bom.json

# Every component has a purl
jq -r '.components[] | select(.purl == null) | .name' bom.json

# Every purl is in canonical npm scoped form (no literal @ in the namespace)
jq -r '.components[].purl | select(test("^pkg:npm/@"))' bom.json

The second and third commands should print nothing. For full validation, point any JSON Schema validator at the official schema, http://cyclonedx.org/schema/bom-1.7.schema.json; note that it references companion schemas (for SPDX license identifiers and JSON signatures) that your validator must be able to resolve.

If a customer contract asks for "ECMA-424 conformant" SBOMs, this JSON form is the one the standard describes.

Step 3: turn the purl into a Transparency Exchange Identifier

TEA does not look things up by purl directly in the URL path. It uses a Transparency Exchange Identifier (TEI), a URI of the form:

tei://<domain-name>/<type>/<unique-identifier>

The domain is one the vendor controls, the type is registered in the TEA repository's tei-types registry, and for the purl type the identifier is the purl "Base64URL-encoded without padding". The discovery specification is strict that a TEI is opaque and compared character by character, so a padded and an unpadded encoding are two different TEIs. To encode without padding:

printf '%s' 'pkg:npm/%40angular/animation@12.3.1' \
  | python3 -c "import sys,base64; print(base64.urlsafe_b64encode(sys.stdin.read().encode()).decode().rstrip('='))"

That prints cGtnOm5wbS8lNDBhbmd1bGFyL2FuaW1hdGlvbkAxMi4zLjE. If the vendor's TEA domain were products.example.com, the TEI would be:

tei://products.example.com/purl/cGtnOm5wbS8lNDBhbmd1bGFyL2FuaW1hdGlvbkAxMi4zLjE

In practice the vendor tells you the TEI. The discovery document says a TEI "is defined by the vendor and cannot normally be derived from known information", and suggests it be printed on a box as a QR code, on an invoice, or in a software "about" box. The purl type is the case where a consumer can build one, provided they know the vendor's domain.

Step 4: discover the API and fetch the BOM

Discovery has two stages. First, the client fetches the well-known document from the TEI's domain over HTTPS, verifying the certificate:

curl -s https://products.example.com/.well-known/tea | jq .

The specification's example response lists endpoints with supported versions and a priority between 0 and 1:

{
  "schemaVersion": 1,
  "endpoints": [
    { "url": "https://api.example.com", "versions": ["1.0.0"], "priority": 1 },
    { "url": "https://api2.example.com/mytea", "versions": ["1.0.0"], "priority": 0.5 }
  ]
}

The client picks the endpoint whose highest mutually supported version is greatest, using SemVer comparison, then the highest priority. It then calls /discovery with the TEI URL-encoded:

curl -s "https://api.example.com/v1.0.0/discovery?tei=tei%3A//products.example.com/purl/cGtnOm5wbS8lNDBhbmd1bGFyL2FuaW1hdGlvbkAxMi4zLjE" | jq .

A successful response is always a non-empty JSON array. Each element carries a productReleaseUuid and a servers list of API base URLs that serve that release. An unknown TEI returns HTTP 404 with the error OBJECT_UNKNOWN, never an empty array. All further calls go to a rootUrl from servers, which need not be the host you called for discovery.

From there the OpenAPI document defines the retrieval path. With the product release UUID in hand:

API=https://api.example.com/v1.0.0
REL=d4d9f54a-abcf-11ee-ac79-1a52914d44b1   # productReleaseUuid from discovery

# The latest collection of artefacts for this release
curl -s "$API/productRelease/$REL/collection/latest" | jq .

# Lifecycle events for the release, as a TEA projection of CLE
curl -s "$API/productRelease/$REL/cle" | jq .

A collection is a versioned list of artefacts. The README says collections are versioned "to indicate changes, e.g., an updated VEX or corrected SBOM", so a consumer that stores the collection version can tell when the supplier has corrected something. Each artefact has a type such as BOM or VULNERABILITIES, and each format of an artefact has a media type and, where a URL is given, checksums. Download the BOM from its URL, check the SHA-256 against the collection, and only then parse it. The OpenAPI document also defines /artifact/{uuid}/latest/download and a matching signature download path for artefacts that are signed.

There is also a direct query if you already know the purl and the API base:

curl -s "$API/productReleases?idType=PURL&idValue=pkg%3Anpm%2F%2540angular%2Fanimation%4012.3.1" | jq .

Two cautions: TEA is beta, so check the current OpenAPI document before writing a client, and example.com is the specification's placeholder, so these commands show the shape of the flow, not a live service.

At the end you have a canonical identifier (ECMA-427), a BOM that uses it as the join key (ECMA-424), and a defined way for a supplier to publish that BOM, its VEX and its lifecycle events per product release (TEA). If the supplier also publishes CLE, the same purl ties the BOM entry to its end of support date.

How does TC54 compare with SPDX, OASIS and ISO/IEC JTC 1?

People often treat "CycloneDX versus SPDX" as the only standards question. The more useful comparison is between the bodies that write software transparency specifications, because each has a different process, a different patent policy and a different route to an ISO/IEC number.

A few notes on reading that table.

OASIS is the home of the advisory side. CSAF is an OASIS Standard, and OpenEoX is being written by an OASIS TC, so CLE (Ecma) and OpenEoX (OASIS) overlap, as our CLE and OpenEoX post explains. The OpenEoX TC page we fetched still said the committee "has not yet produced any technical work", which looks out of date; check its document list instead.

JTC 1 is a destination, not a competitor. None of these formats was invented inside JTC 1. They reach it through PAS or fast-track and gain national body approval, which some public buyers prefer to cite.

The SPDX project and TC54 are different kinds of organisation. SPDX is a specification project with its own governance; TC54 is a committee inside a standards body that formalises community specifications. TEA is designed to carry BOMs in any format, SPDX included. And process is not quality: what a formal standard gives you is a stable, citable edition with a number and a date.

Common mistakes

Asking for "CycloneDX" without an edition. That lets a supplier deliver any version from 1.0 upward. "ECMA-424 2nd edition" means CycloneDX 1.7 in JSON. Name the edition in supplier requirements.

Calling CycloneDX an ISO standard. As of this writing, Ecma lists ECMA-424 as ISO/IEC DIS 27055: a draft, not a published ISO/IEC standard. SPDX is the SBOM format with a published ISO/IEC number (5962:2021). Say "ECMA-424" for CycloneDX until JTC 1 publishes.

Confusing ECMA-424 editions with CycloneDX versions. The 1st edition is CycloneDX 1.6; the 2nd edition is CycloneDX 1.7. CycloneDX 1.0 through 1.5 were never Ecma standards.

Expecting ECMA-427 to define npm or Maven rules. It does not. The standard defines the syntax and the schema for type definitions; the per-ecosystem rules live in the purl-spec repository's types directory. A parser that conforms to ECMA-427 but ignores type definitions will still get pypi names wrong.

Writing scoped npm purls with a literal @. The canonical form is pkg:npm/%40scope/name@version. Mixed forms in one inventory break deduplication and vulnerability matching.

Treating TEA as finished. The repository says Beta 2, consumer side only. Publisher APIs come after 1.0. Build prototypes and join interoperability tests if it matters to you; do not make it a hard supplier requirement yet.

Assuming TC54 membership is required to contribute. Issues, pull requests, Slack and most meetings are open. Ecma membership or invited expert status is needed for technical contributions that end up in the standard text and for votes.

Citing the live HTML as the edition. The Ecma PDF is the fixed edition. The live HTML text is "the most accurate and up-to-date" version, so it may include changes made after the edition you cite.

FAQ

What does TC54 stand for?

TC54 is Ecma International's Technical Committee 54. Ecma numbers its committees in order of creation; TC39, for example, is the ECMAScript committee. TC54's formal title is "Software and system transparency".

Who runs Ecma TC54?

The committee is run by its members under Ecma's rules, with a chair group and the Ecma Secretary General as secretary. Ecma's TC54 page lists Chris de Almeida and Alyssa Wright as the chair group. Each task group has its own convenor; Ecma lists Steve Springett as the TG1 convenor.

Is CycloneDX an ISO standard?

Not yet. CycloneDX 1.7 is published as ECMA-424 2nd edition, and Ecma lists the ISO/IEC number as DIS 27055, which is a draft international standard. SPDX, by contrast, is published as ISO/IEC 5962:2021.

What is ECMA-427?

ECMA-427 is the Ecma standard for Package URL (purl) 1.0, approved on 10 December 2025. It defines the seven-part purl syntax and the schema for purl type definitions, but not the type definitions themselves. Ecma lists it as ISO/IEC DIS 27056.

Is the Transparency Exchange API a standard yet?

No. TEA is being developed by TC54-TG1 and is in Beta 2 according to its repository. It has no Ecma number yet, and the publisher side of the API will be worked on after the 1.0 release.

How much does it cost to join Ecma?

Annual fees range from CHF 70,000 for ordinary members to CHF 3,500 for small private companies with no more than 25 employees, and CHF 0 for not-for-profit organisations. Individuals can participate as invited experts without membership.

Can I contribute to CycloneDX or purl without joining Ecma?

Yes. Both are developed in public GitHub repositories and discussed in the CycloneDX Slack workspace, and anyone can open issues, review pull requests and attend most working group calls. Technical contributions that become part of an Ecma standard need agreement to Ecma's IPR policies, usually through a member organisation or invited expert status.

Why did CycloneDX go to Ecma instead of ISO directly?

No single document states the reason. The public record shows Ecma offers a royalty-free patent policy, free publication, experience with open source specifications from ECMAScript, and a fast-track route to ISO/IEC JTC 1 through its Category A liaison. Ecma adoption gives a numbered standard quickly, and fast-track then carries it to ISO/IEC.

What is TC54-TG4 working on?

TG4, the OSS Sustainability task group, is standardising Contributing.yaml (called Contributing JSON in its repository scope), a machine-readable way for open source projects to state their maintenance status, support levels and needs. It is in development with no publication date.

Where Safeguard fits

This post is about a standards committee, so Safeguard's fit is indirect, and we will keep it to one paragraph. Safeguard is not a TC54 deliverable and does not implement TEA. Its work sits on either side of the standards: scanning repositories, container images and existing SBOM files to build the component inventory that purls and BOMs describe, showing which projects contain a given component and version, matching components against vulnerability databases, and opening fix pull requests when you switch that on.

TC54's standards describe software; they do not patch it. A canonical purl and a clean ECMA-424 BOM tell you exactly which vulnerable component sits in which product release, and the next question is how fast the fixed version reaches your builds.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Nothing here implies an affiliation with Ecma or TC54. The three demos below show the inventory and remediation work on either side of the standards.

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. A scan of a repository, a container image or an existing SBOM file is the inventory step that comes before the walkthrough above: it produces the component list that the purl and BOM steps describe.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. Asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. Once a purl in your BOM matches an advisory, this is the approval-gated flow for moving that component to a fixed version.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. With your projects in Safeguard, that connection lets you ask in plain language which projects contain a given component and version, which is the question a canonical purl is meant to make answerable.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Ecma International: TC54 Software and system transparency
• Ecma International: TC54-TG1 Transparency exchange API
• Ecma International: ECMA-424 CycloneDX
• ECMA-424 2nd edition, December 2025 (PDF)
• Ecma International: ECMA-427 Package-URL
• ECMA-427 1st edition, December 2025 (PDF)
• Ecma International: ECMA-428 Common Lifecycle Enumeration
• ECMA-428 1st edition, December 2025 (PDF)
• Ecma International: approval of new standards at the 130th General Assembly, 11 December 2025
• Ecma International: approval of new standards at the 131st General Assembly, 1 July 2026
• Ecma International: History
• Ecma International: Join Ecma
• Ecma International: Rules
• Ecma International: By-laws
• Ecma International: IPR policies
• Ecma Directives, February 2026 (PDF)
• Ecma International: standardization at Ecma presentation (PDF)
• TC54: home
• TC54: history of CycloneDX and TC54
• TC54: participate and contribute
• TC54: CycloneDX specification page
• TC54: Package-URL specification page
• TC54: VERS specification page
• TC54: Common Lifecycle Enumeration specification page
• TC54: Transparency Exchange API specification page
• TC54: Contributing.yaml specification page
• Ecma-TC54 on GitHub: TG2 Package URL repository
• Ecma-TC54 on GitHub: TG4 OSS Sustainability repository
• package-url/purl-spec README
• purl-spec npm type definition
• purl-spec pypi type definition
• Transparency Exchange API README
• Transparency Exchange API: discovery specification
• Transparency Exchange API: OpenAPI document
• CycloneDX 1.7 JSON schema
• ISO/IEC JTC 1: Approved PAS Submitters
• Linux Foundation: SPDX becomes internationally recognized standard, 9 September 2021
• OASIS: Common Security Advisory Framework Version 2.0, OASIS Standard
• OASIS: OpenEoX TC

Last reviewed: 24 October 2026. TEA, VERS and Contributing.yaml are drafts, and ECMA-424 and ECMA-427 are at the ISO/IEC DIS stage; check the Ecma and tc54.org pages for the current status before citing them.