Track copied or forked code as a named dependency with a relationship, not as your own original code. CISA's 2026 guidance says copied code is effectively a dependency better tracked as a fork, and that doing so improves vulnerability management. Tell buyers you do this and how.
Why this comes up in sales reviews
Fast moving teams borrow code. A function pasted from an open source repository, a patched fork of a library, a vendored directory checked into the repo. None of it appears in a lockfile, so a basic scan will miss it. A reviewer who asks "is everything in your SBOM?" is, whether they know it or not, asking about this.
What the guidance says
In a note on component names, CISA's 2026 document describes the expected practice when a developer uses another project: make an internal fork, name it, possibly edit it, and import the local fork. When developers copy and paste functional code from another project instead, the guidance says that copied code is effectively a dependency better tracked as a fork and a dependency relationship. It adds that an SBOM author may document borrowed code as an inclusion dependency by naming it as if it were a local fork, and that this improves vulnerability management (see Sources).
Three situations and how to record them
| Situation | How to treat it |
|---|---|
| Library forked and patched | Name the fork, record the upstream project and version it came from |
| Directory vendored into the repo | List it as a component with the upstream version |
| Snippet pasted into a file | Record it as a named inclusion with a dependency relationship to your component |
For each, note the source project, the version or commit, and the license, since those are what you need when an advisory appears or a license question arrives.
A simple process
- Find it. Search for vendored directories, third party license headers and "copied from" comments. Ask the team.
- Name it. Give each item a consistent name such as the upstream name plus a marker for your fork.
- Record the origin. Keep a small file listing upstream project, version or commit, date copied, and the reason.
- Add it to the SBOM. Configure your generator to include these entries, or add them in a supplement.
- Set a review point. Revisit forks when upstream publishes security fixes.
What to say to a buyer
"Most of our dependencies come from lockfiles and are picked up automatically. A few are forks or vendored copies. We name those, record their upstream source and version, and include them in the SBOM so an advisory can be matched."
If you have not done this yet, say so and give a date you will keep. A startup that admits the gap and has a plan is easier to trust than one that says everything is covered.
Common mistakes
- Treating a fork as first party code and leaving it out.
- Forgetting that a patched fork no longer receives upstream fixes automatically.
- Recording the fork without the upstream version, which makes advisory matching impossible.
Where Safeguard fits
Safeguard's SBOM and dependency scanning helps you inventory what package managers declare, and its policies can flag changes at review time. Borrowed code that never appears in a manifest needs the manual record above. Start with the free scan to see what is already detected.
Quick check
Is copying a small snippet really a dependency?
The CISA guidance treats copied functional code as effectively a dependency, because a vulnerability in the original can exist in your copy.
Will a scanner find vendored code automatically?
Not always. Tools that read lockfiles will miss it, so keep a manual record of forks and vendored directories.
Sources
Last reviewed: 19 October 2026.
