CycloneDX Versions 1.0 to 1.7 Explained, Plus the ECMA-424 Editions

CycloneDX has had eight minor releases, from 1.0 in March 2018 to 1.7 in October 2025, plus patch releases that fix schema alignment. Version 1.6 became ECMA-424 1st edition in June 2024, and 1.7 became the 2nd edition in December 2025. Emit the newest version your oldest consumer can validate, in JSON unless a reader needs XML or Protocol Buffers.

The rest of this post goes release by release through what each version changed, using the schema files as the record, then covers ECMA-424, the three serialisations, compatibility, and how to validate and downgrade with the official CycloneDX tools.

If you want the shorter takes first, our posts on which CycloneDX version your build should emit and JSON, XML or Protobuf cover the everyday decision. This one is the reference underneath them.

Key takeaways

• Eight minor versions from 26 March 2018 (1.0) to 21 October 2025 (1.7), per the specification repository's release history.
• Big capabilities arrived in a clear order. Services (the basis of SaaSBOM) and JSON in 1.2. Protocol Buffers and compositions in 1.3. Vulnerabilities, so VDR and VEX, in 1.4. ML-BOM, data components, formulation and lifecycles in 1.5. CBOM, attestations, declarations and definitions in 1.6. Citations, patents and TLP distribution constraints in 1.7.
• ECMA-424 has two editions. The 1st edition (June 2024) is CycloneDX 1.6. The 2nd edition (December 2025) is CycloneDX 1.7. The Ecma page also lists an ISO/IEC number, DIS 27055, which is a draft, not a published ISO standard.
• Patch releases matter. The 2026 patches (1.5.1, 1.6.2, 1.7.1, 1.7.2) fixed places where XML or protobuf did not match JSON.
• Newer readers accept older documents; older readers reject newer ones. No field has been removed between 1.2 and 1.7, only deprecated, but from 1.4 the JSON schema forbids unknown properties, so a 1.6 validator fails a document that uses 1.7 fields.
• Validate against the version you claim. The CycloneDX CLI takes an explicit input version, and the JSON schemas can be used directly with any Draft 7 validator.

CycloneDX version timeline, 1.0 to 1.7

The dates below come from the release history table in the CycloneDX specification repository README and the GitHub releases page. The GitHub release objects for 1.0 and 1.1 were created later, in April 2024, so their release dates are taken from the release titles and the README rather than the GitHub timestamps. The one line summaries combine the official release notes, the CycloneDX history page and a diff of the schema files I ran against each version.

CycloneDX started as an XML format: the repository has no JSON schema before 1.2 and no protobuf schema before 1.3. The 2026 backports to 1.5 and 1.6 show older minor versions are still treated as live targets.

What each release added

1.0 (March 2018): a security focused parts list

The 1.0 XML schema is small. A bom holds components, and each component has a type, group, name, version, description, scope, hashes, licenses, copyright, CPE, Package URL and a modified flag. The allowed types were application, framework, library, operating-system and device. The CycloneDX history page describes 1.0 as the first general purpose, security focused BOM standard supporting software and hardware components, and credits it with introducing Package URL to software security use cases.

Package URL (purl) is what lets a scanner match a component to a vulnerability record without guessing, and CycloneDX built around it from the start.

1.1 (March 2019): pedigree and identity

1.1 added pedigree, with ancestors, descendants, variants and commits, so a BOM could say that a component is a fork or a patched build of something upstream. It also added serialNumber (a URN UUID that identifies one BOM document), externalReferences for links to advisories, websites and VCS, and license expressions. The history page calls it the first version with complete pedigree support.

1.2 (May 2020): JSON, metadata, services and dependencies

1.2 is where CycloneDX starts to look like the format most tools emit today. The release notes list firmware and container component types, SWID tags, service components, applied patches, JSON support, and "enhanced BOM metadata and dependency graphs previously only available through extensions". You can still see those older extensions in the repository's schema/ext folder (bom-descriptor-1.0.xsd and dependency-graph-1.0.xsd).

The new top level metadata object carried the timestamp, tools, authors, the component the BOM describes, its manufacturer and its supplier. services gave each service endpoints, an authenticated flag, an x-trust-boundary flag, data classifications and a provider. That services model is the root of what CycloneDX now calls SaaSBOM.

dependencies added the graph: each entry names a ref and the refs it dependsOn, so readers can tell direct from transitive dependencies.

1.3 (May 2021): completeness and Protocol Buffers

1.3 added compositions, which let a producer state how complete a part of the BOM is. The 1.3 schema's aggregate values were complete, incomplete, incomplete first party only, incomplete third party only, unknown and not specified. Later versions added proprietary only and open source only variants of the incomplete values. The history page says this surpassed NTIA's framing of "known unknowns".

1.3 also added properties (a name value store on components, services and metadata), component evidence for licenses and copyright, a license for the BOM document itself, and the first .proto schema. The 1.3 release notes describe protobuf as a way to make machine to machine transport more efficient.

1.4 (January 2022): vulnerabilities, VDR and VEX

1.4 added a top level vulnerabilities array. Each entry has an ID, source, ratings, CWEs, advisories, timestamps, an analysis block and an affects list. The analysis block carries the VEX state (resolved, resolved_with_pedigree, exploitable, in_triage, false_positive, not_affected), a justification such as code_not_reachable or requires_configuration, and a response.

The same structure serves two purposes. Listed against your own components with no analysis, it is a Vulnerability Disclosure Report (VDR). Listed with analysis states, it is a VEX statement. The history page and the 1.4 announcement credit 1.4 with both. For how CycloneDX VEX compares with other VEX formats, see our VEX guide.

1.4 also added releaseNotes on components and services, an enveloped signature property in JSON, and improved hardware device support. A quieter change matters for validation: the 1.4 JSON schema sets additionalProperties to false at the top level. Earlier versions shipped separate -strict schema files for that behaviour (you can still see bom-1.2-strict.schema.json and bom-1.3-strict.schema.json in the repository).

1.5 (June 2023): ML-BOM, data, formulation and lifecycles

1.5 is the release that took CycloneDX beyond software and hardware parts. The 1.5 announcement lists Machine Learning transparency (ML-BOM), formulation, and SBOM quality indicators including evidence and lifecycles. In the schema that means:

• New component types: machine-learning-model, data, platform and device-driver.
• modelCard on components, for model parameters, quantitative analysis and considerations.
• data on components, for datasets and their governance.
• Top level formulation, with formulas, workflows, tasks, steps, triggers and workspaces that describe how something was built, trained or deployed. CycloneDX positions this as the basis of MBOM.
• metadata.lifecycles, with predefined phases: design, pre-build, build, post-build, operations, discovery and decommission.
• Top level annotations and top level properties.
• trustZone on services.
• proofOfConcept, workaround and rejected on vulnerabilities.
• bomLink definitions in the JSON schema, so one BOM can point at another BOM or at an element inside it.

1.5 also changed metadata.tools from an array of tool objects to an object that holds components and services. The 1.7 schema still accepts the old array, labelled "Tools (legacy)" and marked deprecated. Our 1.5 features guide goes deeper on the ML and formulation fields.

1.6 (April 2024): CBOM and attestations

The 1.6 announcement names two core additions: the Cryptography Bill of Materials (CBOM) and CycloneDX Attestations (CDXA). In the schema:

• A new component type, cryptographic-asset, with cryptoProperties describing algorithms, certificates, protocols and related material.
• Top level declarations (claims, evidence, attestations, signatories) and definitions (standards and their requirements).
• authors and manufacturer on components, replacing the single author string, and metadata.manufacturer, replacing metadata.manufacture. Both old fields are deprecated, not removed.
• tags, omniborId and swhid on components; licence acknowledgement (declared or concluded); environmental considerations in model cards; postal addresses on organisations; URLs for source distributions and RFC 9116 security.txt documents.
• A relaxed JSON $schema rule. Per the release notes, arbitrary $schema values are allowed; I confirmed the 1.4 and 1.5 schemas reject another version's $schema URL and 1.6 does not.

The 1.6 release notes said it "forms the basis of a future Ecma International standard"; it became ECMA-424 two months later.

1.7 (October 2025): provenance of data, patents and distribution limits

The 1.7 announcement leads with CBOM enhancements, citations and intellectual property transparency. The 1.7 release notes list:

• Top level citations, which record who or what contributed a piece of information to the BOM and when, for BOMs enriched by several tools.
• patentAssertions on components and services, plus patent and patent family definitions.
• metadata.distributionConstraints with a Traffic Light Protocol classification, so a BOM can say how widely it may be shared.
• isExternal and versionRange on components, for describing components that are expected to be supplied outside the product, with the versions that are acceptable.
• Multiple SPDX licence expressions alongside other licences, properties on external references, and the Streebog hash algorithm.
• A reworked CBOM model, with several older cryptographic fields deprecated in favour of new structures such as relatedCryptographicAssets.
• A wider scope for formulation, which can now describe how any referencable object came together, including the BOM itself.

The announcement also says the project published a standard list of cryptographic algorithm families and a list of elliptic curves that can be used independently of CycloneDX. For a field level review of 1.7, see our 1.7 features review and the 1.5 to 1.7 migration guide.

The patch releases (2024 to 2026)

Patch releases add no capabilities. They fix places where the three schemas disagreed, plus typos. From the release notes:

• 1.6.1 (November 2024): "functionally equivalent" to 1.6, with bug fixes to the XML, JSON and protobuf implementations.
• 1.7.1, 1.6.2 and 1.5.1 (2 June 2026): added the repeated properties node to model cards in XML and protobuf, and made several model card consideration lists repeatable in XML. 1.5.1 also stopped requiring the JSON version property, because it already had a default value.
• 1.7.2 (17 September 2026): added an optional XML node for related cryptographic assets under protocol properties, which JSON already allowed.

If you use XML or protobuf model cards, the June 2026 patches changed what is valid; JSON users saw little change.

What about CycloneDX 2.0?

As of 23 October 2026, the latest release on the specification repository is 1.7.2. The repository has a 2.0-dev branch and many feature branches named after it, and the 1.7 announcement quotes the TC54 chair describing an "API-first future" being built with 2.0. The cdxgen README already lists 2.0 as a generation target. Until 2.0 is released, treat 2.0 output as a preview.

When did each capability arrive?

"Arrived" means the version where the schema first carried the field. CycloneDX names the matching BOM type on its capabilities pages.

Which BOM types does CycloneDX cover today?

The specification README lists the BOM types CycloneDX supports today: SBOM, SaaSBOM, HBOM, ML-BOM, CBOM, MBOM, OBOM, VDR, VEX and CDXA. The CycloneDX site adds pages for the Bill of Vulnerabilities (BOV), BOM-Link and the Common Release Notes Format. For the family view, see our posts on AIBOMs, CBOMs and SaaSBOMs.

Top level fields and component types by version

I listed the top level properties of each JSON schema (1.2 to 1.7) and the elements of the 1.0 and 1.1 XML schemas. Every field below is still present in 1.7.

And the component type values over time:

This is the table to check when a consumer rejects your file. If your generator emits "type": "machine-learning-model" and the reader only knows 1.4, the document is invalid for that reader no matter what specVersion says.

A minimal, schema valid CycloneDX 1.7 SBOM

Here is the smallest useful SBOM: one application, one dependency, a licence, a dependency graph and the build lifecycle phase.

{
  "$schema": "http://cyclonedx.org/schema/bom-1.7.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-23T09:00:00Z",
    "lifecycles": [{ "phase": "build" }],
    "tools": {
      "components": [
        { "type": "application", "name": "example-sbom-generator", "version": "1.0.0" }
      ]
    },
    "component": {
      "type": "application",
      "bom-ref": "pkg:npm/example-app@2.4.0",
      "name": "example-app",
      "version": "2.4.0",
      "purl": "pkg:npm/example-app@2.4.0"
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/lodash@4.17.21",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ],
  "dependencies": [
    { "ref": "pkg:npm/example-app@2.4.0", "dependsOn": ["pkg:npm/lodash@4.17.21"] },
    { "ref": "pkg:npm/lodash@4.17.21", "dependsOn": [] }
  ]
}

I validated this document with a Draft 7 JSON Schema validator against the schema files in the CycloneDX specification repository as of 23 October 2026. Results:

• 1.7 schema: valid.
• 1.6 schema: valid. Nothing in it is new in 1.7, and 1.6 accepts any $schema value.
• 1.5 schema: invalid, only because $schema points at the 1.7 URL and the 1.5 schema only accepts its own.
• 1.4 schema: invalid three ways: the $schema value, metadata.lifecycles (added in 1.5) and the object form of metadata.tools (also 1.5).

When I added a 1.7 field, a distributionConstraints object with the TLP value AMBER inside metadata, the 1.7 schema accepted it and the 1.6 schema rejected it with "Additional properties are not allowed". That one test is the whole compatibility story in miniature.

And here is a minimal standalone VEX document. It validates against the 1.4, 1.5, 1.6 and 1.7 schemas, because it only uses fields that have existed since 1.4 and it has no $schema property. The affects reference is a BOM-Link that points at the lodash component inside the SBOM above, by serial number, BOM version and bom-ref.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:9c7a0d5e-3c1b-4f7e-8a42-5d1f0e6b2c11",
  "version": 1,
  "vulnerabilities": [
    {
      "id": "CVE-2021-23337",
      "source": { "name": "NVD", "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23337" },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "example-app never passes user input to lodash template()."
      },
      "affects": [
        { "ref": "urn:cdx:3e671687-395b-41f5-a30f-a58921a69b79/1#pkg:npm/lodash@4.17.21" }
      ]
    }
  ]
}

The product and the analysis are illustrative. A real VEX statement needs a real investigation behind it.

What is ECMA-424?

ECMA-424 is the Ecma International standard that publishes the CycloneDX specification. It is maintained by Ecma Technical Committee 54 (TC54), which the CycloneDX history page says was established in December 2023. The OWASP Foundation and TC54 together drive the specification, according to the specification README.

A few details are easy to get wrong:

• Patch versions are not separate editions. 1.6.1, 1.6.2, 1.7.1 and 1.7.2 are fixes published by the CycloneDX project. The edition maps to the minor version.
• ECMA-424 is not yet an ISO standard. The Ecma page lists "ISO/IEC number DIS 27055". DIS means Draft International Standard. Our post on whether SBOM formats are official standards covers how that compares with SPDX and ISO/IEC 5962:2021.
• The standard text and the schemas are licensed separately. The specification README says ECMA-424 is published under a royalty free patent policy, while the schemas in the repository are the official interpretation of the standard under the Apache 2.0 licence. It also says the JSON Schema is the reference implementation.
• The 2nd edition's scope sentence mentions JSON. The 2nd edition PDF says the BOM "is serialised using a machine-readable JSON format", yet its serialisation section still lists JSON, XML and protobuf with schema links for each. Read that as JSON being the reference, not as XML and protobuf being dropped.
• Ecma's guiding principles include compatibility. Both editions list "Produce immutable and backward-compatible releases" among the CycloneDX design principles.

For procurement language, "CycloneDX as specified in ECMA-424" without an edition is ambiguous. Name the edition or the minor version, for example "ECMA-424 2nd edition (CycloneDX 1.7) or 1st edition (CycloneDX 1.6)". Our ECMA-424 2nd edition post has more on the ratification itself.

JSON, XML and Protocol Buffers: where they differ

All three serialisations describe the same object model, but they are not interchangeable in practice, as the patch history shows.

The media types accept a version parameter, for example application/vnd.cyclonedx+json; version=1.7, which is the cleanest way to say which version an API returns.

Practical guidance:

1. Default to JSON. It is the reference schema, the one ECMA-424 names in its scope, and the one the other two were aligned to in the 2026 patches.
2. Use XML when the reader requires it or when you need XML Signature in an existing XML security toolchain. Check that the fields you rely on exist in the XSD of the patch release your reader validates against.
3. Use protobuf for service to service transport where size and parse speed matter and both ends control their tooling. It has no embedded signature, so sign outside the document, for example with an in-toto attestation. CycloneDX recognises https://cyclonedx.org/bom as the official in-toto predicate type for all CycloneDX BOM varieties.
4. Convert, then validate. The CycloneDX CLI converts between XML, JSON and protobuf. Re-validate the output against the target version every time.

What the specification promises about compatibility

I found no formal versioning policy document in the specification, but three things are stated.

A stated design principle. ECMA-424 lists "Produce immutable and backward-compatible releases" among the CycloneDX guiding principles.

Deprecate, do not delete. Fields that are being replaced carry the text "[Deprecated] This will be removed in a future version" and stay in the schema. Examples: component.author (deprecated in 1.6 for authors and manufacturer), metadata.manufacture (deprecated in 1.6 for metadata.component.manufacturer), the legacy array form of metadata.tools (deprecated in 1.5), and several CBOM fields deprecated in 1.7. I diffed the property lists of the top level, component, service, metadata and vulnerability definitions across the 1.2 to 1.7 JSON schemas: nothing was removed, only added.

Immutable releases. Each version's schema has its own URL, such as http://cyclonedx.org/schema/bom-1.6.schema.json. Recent GitHub releases are marked "Immutable release". Patch releases fix alignment between serialisations but are not supposed to change meaning.

What that adds up to in practice:

• A newer reader can read an older document. A 1.7 aware tool can parse a 1.4 document, because every 1.4 field still exists in 1.7 with the same meaning.
• An older reader will often reject a newer document. From 1.4 the JSON schema sets additionalProperties: false, so any field the reader's schema does not know is an error. A lenient parser may instead drop it silently, which is worse.
• A document is only as new as the fields it uses. A file labelled "specVersion": "1.7" that only uses 1.4 era fields will pass a 1.6 schema check (1.6 tolerates the $schema value). Many tools still check the label first.
• Deprecated fields are still valid, but a reader built for a newer version may expect the replacement. If you emit author, also consider emitting authors.
• A major version may change the rules. CycloneDX 2.0 has not been released, so its compatibility rules are not yet stated. Do not assume a 2.0 document will validate against 1.x tooling.

Step by step: generate, validate and downgrade a CycloneDX document

This walkthrough uses only tools under the CycloneDX GitHub organisation. Flags are quoted from each tool's README as of 23 October 2026.

Step 1: choose the version deliberately at generation time

Each generator has its own flag and its own default.

For npm:

npm install --save-dev @cyclonedx/cyclonedx-npm
npx @cyclonedx/cyclonedx-npm --spec-version 1.6 --output-format JSON --output-file bom.json

For Maven, pin the schema in pom.xml:

<plugin>
  <groupId>org.cyclonedx</groupId>
  <artifactId>cyclonedx-maven-plugin</artifactId>
  <configuration>
    <projectType>application</projectType>
    <schemaVersion>1.6</schemaVersion>
    <includeBomSerialNumber>true</includeBomSerialNumber>
  </configuration>
</plugin>

For Go:

go install github.com/CycloneDX/cyclonedx-gomod/cmd/cyclonedx-gomod@latest
cyclonedx-gomod app -json -output-version 1.6 -output bom.json

For cdxgen, which covers many ecosystems and container images:

npm install -g @cdxgen/cdxgen --ignore-scripts
cdxgen -r -o bom.json --spec-version 1.6

Step 2: read the version back from the file

Never assume the flag worked. Read what the file says:

jq -r '.specVersion, (.["$schema"] // "no $schema")' bom.json

For XML, the namespace carries the version:

grep -o 'xmlns="http://cyclonedx.org/schema/bom/[0-9.]*"' bom.xml

Step 3: validate against the version you claim

With the CycloneDX CLI, installed from the Homebrew tap or run from the official Docker image:

brew install cyclonedx/cyclonedx/cyclonedx-cli
cyclonedx validate --input-file bom.json --input-format json --input-version v1_6 --fail-on-errors

docker run --rm -v "$PWD":/work cyclonedx/cyclonedx-cli \
  validate --input-file /work/bom.json --input-format json --input-version v1_6 --fail-on-errors

The README says the input version option defaults to v1.7, so always pass it. Otherwise you are checking a 1.6 document against 1.7 rules, which will pass even when a 1.6 reader would fail.

If you prefer plain JSON Schema, use any Draft 7 validator with the schema for your version. The CycloneDX schemas reference two helper schemas, spdx.schema.json and jsf-0.82.schema.json, which must be resolvable. A minimal Python version, run from a checkout of the specification repository:

import json, sys
from jsonschema import Draft7Validator
from referencing import Registry, Resource
from referencing.jsonschema import DRAFT7

schema_dir, version, bom_path = sys.argv[1], sys.argv[2], sys.argv[3]
registry = Registry()
for name in ["spdx.schema.json", "jsf-0.82.schema.json"]:
    contents = json.load(open(f"{schema_dir}/{name}"))
    registry = registry.with_resource(name, Resource.from_contents(contents, default_specification=DRAFT7))

schema = json.load(open(f"{schema_dir}/bom-{version}.schema.json"))
bom = json.load(open(bom_path))
errors = list(Draft7Validator(schema, registry=registry).iter_errors(bom))
for e in errors:
    print("/".join(map(str, e.path)), e.message)
sys.exit(1 if errors else 0)

Run it as python validate.py specification/schema 1.6 bom.json. This is the check I used for the examples above.

Step 4: downgrade only when a consumer needs it

If a reader only accepts an older version, convert and then validate again:

cyclonedx convert --input-file bom.json --output-file bom-1.5.json \
  --input-format json --output-format json --output-version v1_5
cyclonedx validate --input-file bom-1.5.json --input-format json --input-version v1_5 --fail-on-errors

cdxgen's README recommends its own converter for 1.5 output, and says component types the target version does not support are pruned during downgrades:

cdx-convert -i bom.json -o bom-1.5.json --to 1.5

Then diff what was lost. A quick check on component counts and types:

jq '[.components[] | .type] | group_by(.) | map({(.[0]): length}) | add' bom.json
jq '[.components[] | .type] | group_by(.) | map({(.[0]): length}) | add' bom-1.5.json

If the counts differ, the older file is missing parts of your inventory. Tell the consumer, or send both files.

Step 5: enforce it in CI

A GitHub Actions job that generates a 1.6 SBOM for an npm project and fails the build if it does not validate:

name: sbom
on: [push]
jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npx --yes @cyclonedx/cyclonedx-npm --spec-version 1.6 --output-file bom.json
      - run: |
          docker run --rm -v "$PWD":/work cyclonedx/cyclonedx-cli \
            validate --input-file /work/bom.json --input-format json --input-version v1_6 --fail-on-errors
      - uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: bom.json

Pin action and image versions to commit SHAs or digests in production workflows.

Which version should you emit when consumers lag behind?

The rule from our version choice post still holds: emit the newest version that every reader can parse. The table adds the version history to that rule.

Keep one canonical BOM at the newest version you can produce and derive older copies from it, and put the version in the file name or media type when you publish.

Where Safeguard fits

The fit here is direct for producing and analysing BOMs and indirect for version management. Safeguard's SBOM generation and analysis is generally available: it produces CycloneDX in JSON and XML and SPDX in JSON, XML and RDF, offers more than 30 export formats including CSV, Excel and PDF, and can scan continuously on push, on a schedule or on release. It also accepts CSAF and VEX uploads (generally available), so a CycloneDX VEX document like the one above can sit next to the SBOM it describes. Supplier SBOMs can be requested from vendors through third party risk management (generally available) and shared through the Safeguard portal (generally available). For AI assets, AI-BOM discovery is in early access and works with CycloneDX ML-BOM and the SPDX AI profile.

What Safeguard does not do matters just as much for a version post. It does not convert between CycloneDX versions, and its listed CycloneDX outputs are JSON and XML, not protobuf. It does not generate CBOMs, SaaSBOMs, OBOMs or MBOMs, and it does not author VDRs. Before you send a Safeguard export to a consumer with older tooling, read the specVersion in the file and validate it against the consumer's version with the CycloneDX CLI, exactly as in step 3.

A BOM in any CycloneDX version only lists the vulnerable component; it does not fix it. The format question decides whether your customers can read the list, while the remediation question decides how quickly the next version of that list is shorter.

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.

Common mistakes

Validating against the default version. The CycloneDX CLI defaults to 1.7. A 1.5 document checked without the input version set to v1_5 is being checked against the wrong rules.

Trusting specVersion as proof of content. The label says what the producer intended. Only validation tells you whether the fields match. A file labelled 1.5 that contains a citations array is invalid 1.5.

Mixing a $schema URL from one version with another version's schema. The 1.4 and 1.5 JSON schemas only accept their own $schema URL. If you downgrade by editing specVersion, also fix or remove $schema.

Assuming XML and protobuf carry everything JSON does. The June and September 2026 patch releases exist because they did not. If you depend on model card properties or CBOM protocol relationships in XML, make sure your reader uses the patched schema.

Expecting a signature to survive conversion. A JSF signature covers the JSON document only, and protobuf has no signature field. Sign after conversion, or outside the document.

Downgrading silently. Converting 1.6 to 1.4 can drop CBOM components, lifecycles and model cards. Compare counts before and after, and tell the consumer.

Leaving compositions out. Without a composition entry, readers cannot tell whether your BOM is complete. Mark what is incomplete or unknown; it has been in the format since 1.3.

FAQ

What is the latest version of CycloneDX?

The latest minor version is 1.7, released on 21 October 2025. The latest patch release on the specification repository as of 23 October 2026 is 1.7.2, published on 17 September 2026, which fixed an XML schema alignment gap.

Is CycloneDX 1.7 the same as ECMA-424?

CycloneDX 1.7 is ECMA-424 2nd edition, published in December 2025. ECMA-424 1st edition, from June 2024, is CycloneDX 1.6. Both editions are listed on the Ecma International ECMA-424 page.

Is ECMA-424 an ISO standard?

Not yet. The Ecma page lists the ISO/IEC number DIS 27055, which is a Draft International Standard rather than a published one. Our post on ECMA-424 and ISO/IEC 5962 compares the standards status of CycloneDX and SPDX.

Which CycloneDX version added VEX?

Version 1.4, released in January 2022, added the vulnerabilities array with an analysis block. That one structure supports both VEX statements and Vulnerability Disclosure Reports.

When did CycloneDX add AI and machine learning support?

Version 1.5 (June 2023) added the machine-learning-model and data component types and model cards, which together form the ML-BOM. 1.6 added environmental considerations to model cards.

Can a CycloneDX 1.4 tool read a 1.7 file?

Usually not. From 1.4 the JSON schema rejects unknown properties, so any later field makes the file invalid for a 1.4 validator. Convert down with the CycloneDX CLI, re-validate, and check what was dropped.

Is CycloneDX backward compatible?

Within 1.x, newer schemas keep every older field, so newer tools read older documents. Fields are deprecated, not removed. An older tool reading a newer document is not guaranteed to work.

Should I use CycloneDX JSON or XML?

Use JSON unless a consumer needs XML. The JSON Schema is the reference implementation. XML remains fully specified and suits XML based pipelines or XML Signature.

See how Safeguard would help

This first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal, and fixes a lodash CVE by editing package.json to 4.17.21 and running npm install and npm test, asking before each command, then shows /scan .. In the context of this post, the scan output is your inventory, and the CycloneDX version checks from step 3 apply to whatever you export from it.

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

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and then scans from the terminal. That matters for BOM work because builds that must stay inside your network can still produce inventories, and you can run the CycloneDX validation step on the same machine before anything leaves it.

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 lets you choose which tools Claude can use. Once connected, you can ask questions about the projects and findings in your account in plain language, which helps when a supplier's BOM or VEX file raises the question "are we affected?".

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

To try it on your own code, download Safeguard or read the CLI documentation.

Quick check

Sources

• CycloneDX specification repository README and release history (GitHub)
• CycloneDX specification releases, 1.0 to 1.7.2 (GitHub)
• CycloneDX JSON, XML and protobuf schema files, 1.0 to 1.7 (GitHub)
• CycloneDX specification overview
• CycloneDX history
• ECMA-424, Ecma International
• ECMA-424 1st edition, June 2024 (PDF)
• ECMA-424 2nd edition, December 2025 (PDF)
• CycloneDX v1.4 announcement
• CycloneDX v1.5 announcement
• CycloneDX v1.6 announcement
• CycloneDX v1.7 announcement
• CycloneDX capabilities: SBOM
• CycloneDX capabilities: SaaSBOM
• CycloneDX capabilities: ML-BOM
• CycloneDX capabilities: CBOM
• CycloneDX capabilities: VDR
• CycloneDX capabilities: VEX
• CycloneDX capabilities: Attestations (CDXA)
• CycloneDX capabilities: Common Release Notes Format
• CycloneDX CLI README (GitHub)
• cdxgen README (GitHub)
• cyclonedx-npm README (GitHub)
• cyclonedx-maven-plugin README (GitHub)
• cyclonedx-gomod README (GitHub)

Last reviewed: 23 October 2026. Check the CycloneDX specification repository for releases after this date.