Create a component entry by hand or by script with the library's name, exact version, origin URL, license and a hash of the files you copied. Without a package manager there is nothing to read automatically, so the record must be written when the code is added.
Why copied code is a blind spot
Package manager based generators read manifests and lockfiles. A C library dropped into a third party folder has neither. A generator may skip it entirely, or guess from file names and get the wrong version. Yet that folder often holds the most security sensitive code in the project: compression, parsing, cryptography and network protocols.
What a good entry contains
| Field | What to write |
|---|---|
| Name | The upstream project name, spelled as the project spells it |
| Version | The release tag or commit you copied, never "latest" |
| Origin | The upstream repository or download URL |
| Hash | A digest of the copied files or the archive you took them from |
| License | The license text found in the copied files, or unknown if absent |
| Local changes | A short note if you patched anything |
CycloneDX components can carry hashes, and SPDX packages can carry checksums, so both formats have a place for this.
How to find the version
- Look for a version macro or header in the copied code.
- Check the commit message or ticket that added the folder.
- Compare file contents against upstream releases. A diff against a tagged release is a reliable answer.
- If nothing works, record the date copied and mark the version as unknown, then plan to replace the copy with a pinned reference.
Keep it from drifting
The record is only useful if it changes when the code changes. Two habits help.
- Keep a small manifest file in the third party folder, with one line per library, and review it in every pull request that touches the folder.
- Add a check in the build that fails when the folder changes but the manifest does not.
Your SBOM script can then read that manifest and turn each line into a component. This is a small amount of work and it makes the folder visible to every later tool.
When the copy has been modified
If you patched the library, say so, and record the base version. A modified copy may or may not be affected by an upstream advisory. A reader needs the base version to start the question and the note to finish it.
Consider replacing the copy
For libraries that are updated often, such as TLS and compression code, consider a pinned reference to the upstream source instead of a hand maintained copy. Pinning to a commit hash gives you a reproducible build and a clean record.
Try it yourself
Open the dependency inventory demo and compare an entry that has a clear version with one you would need to chase. The goal is to make every copied library look like the first.
Click through it at your own pace, or open it full screen.
Safeguard scans dependency manifests and generates SBOMs. For copied code with no manifest, add the entries yourself using the approach above, then compare with a free scan.
Quick check
What if I cannot find the version?
Record it as unknown, add the copy date and a hash, and plan to identify it by diffing against upstream releases.
Do hashes help scanners?
They help you prove what you shipped and compare copies. Matching to advisories still needs a name and version.
Last reviewed: 19 October 2026.
