Use the pedigree field on the component. Put the original project in ancestors, and list your changes under commits or patches. The CycloneDX schema describes ancestors as commonly used for forks, so consumers of your SBOM can see both what you ship and what it was derived from.
The problem pedigree solves
An SBOM that lists a forked library under its own name hides its origin. A buyer reading it sees an unknown component. A scanner may match it against the wrong project or none. And an engineer a year later cannot tell whether the library is an original or a fork with changes.
What the schema says
The CycloneDX 1.6 JSON reference defines pedigree as a way to document complex supply chain scenarios where components are created, distributed, modified, redistributed and combined. Within it:
| Field | What it holds |
|---|---|
| ancestors | Components this one is derived from. Commonly used for forks, with the original in an ancestor node |
| descendants | The opposite, forks of an original |
| variants | Related components where the exact relation is unknown |
| commits | A trail of commits describing how it deviates |
| patches | Patches describing how it deviates, including defect or security fixes |
| notes | Free text commentary |
The reference also marks the older modified flag as deprecated and points to pedigree instead, so use pedigree for new work.
An example shape
Written in JSON, a forked component carries its own name and version, with an ancestor entry for the original:
{
"type": "library",
"name": "examplelib-acme",
"version": "2.4.1-acme.2",
"pedigree": {
"ancestors": [
{ "type": "library", "name": "examplelib", "version": "2.4.1" }
],
"patches": [
{ "type": "backport" }
],
"notes": "Backport of upstream fix for a path traversal issue."
}
}
Check the exact patch type values and required fields against the schema version your tooling emits, since they differ between versions.
Rules of thumb
- Give your fork a distinct version string, such as an upstream version plus a local suffix, so it cannot be mistaken for the original.
- Name the ancestor with the exact upstream version you forked from.
- List security backports under patches so a reviewer can see them without reading the Git log.
- Keep the pedigree in sync with each rebase. A stale ancestor version is worse than none.
- Where your tooling cannot write pedigree, add the same facts in notes and an external reference to the fork's repository.
Why buyers and auditors care
Procurement teams increasingly ask for SBOMs. A pedigree turns the question "what is this odd component?" into a one line answer. It also supports vulnerability matching, because the ancestor tells a consumer which upstream advisories to check. For more on what to request in a supplier SBOM, see license fields to require in a supplier SBOM.
Where Safeguard fits
Safeguard produces and ingests SBOMs as part of its SBOM and dependency scanning. Review how a component is presented in the demo below, and try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Pay attention to the name and version fields, which a fork must set honestly.
Quick check
Which field names the original project of a fork?
Ancestors, inside the pedigree. The schema describes it as commonly used to describe forks.
Should a fork keep the upstream version string unchanged?
Better not. A distinct suffix stops people and scanners from assuming it matches the original exactly.
Sources
Last reviewed: 19 October 2026.
