Copied code and your SBOM: track borrowed code as a dependency

Code copied from another project does not show up in a lockfile, so an SBOM built from manifests misses it. CISA's 2026 guidance suggests naming the borrowed code as if it were a local fork and recording a dependency relationship, so a later advisory can still find it.

The problem

A scanner that reads package manifests sees only what is declared. If a developer pastes a function from an open source project into the codebase, nothing says where it came from. When a flaw is found upstream, the product is exposed and the SBOM is silent.

CISA's text describes the expected practice: when a developer uses another project, they make an internal fork, name it, possibly edit it, and import the local fork. When developers follow "less sustainable practices, such as copying and pasting functional code from another project, copied code is effectively a dependency that is better tracked as a fork and a dependency relationship."

What CISA suggests

A footnote says an SBOM author "may document the borrowed code as an inclusion dependency by naming it as if it were a local fork," and adds that tracking borrowed code this way "improves vulnerability management."

In plain terms:

1. Give the borrowed code a component entry with a name and a version or commit.
2. Name the original project as the component producer where known.
3. Record the dependency relationship from your product to that entry.
4. Note the license, since copying does not remove license terms.

Finding the copies

You cannot track what you do not know about. Some ways to find it:

• Search for license headers and project names inside source files.
• Ask in code review: where did this come from?
• Use tools that match code snippets against known projects.
• For AI-assisted work, check what the assistant added. See SBOMs for AI-assisted projects.

What a good entry looks like

Suppose a developer pasted a hashing helper from an open source project into your payments service two years ago. A useful entry records the project name as the component producer, the commit or release it was copied from, the license identifier, and a dependency link from the payments service. If the commit is unknown, say so. An honest entry with a gap is more useful than no entry, because it tells the next reader where to look.

Then check the entry against advisories like any other component. When an upstream flaw is announced, you can ask whether your copy is at an affected commit. Without the entry, you would be searching source files by memory.

Process rules that help

• Add a short comment with the source and commit when you paste code.
• Prefer a vendored, named copy in its own directory over inline pasting.
• Review the list of borrowed code each release.
• If you cannot identify a source, mark provenance unknown. CISA says unknown information should be stated explicitly.

Try it yourself

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

Look at which components come from manifests. Borrowed code is the kind you would have to add by hand.

Quick check

Sources

• CISA 2026 Minimum Elements for an SBOM

Last reviewed: 19 October 2026.