Your team owns the exception for vendored or forked code, because the copy is in your repository and ships in your product, even though upstream owns the fix. Record the exact copy, the upstream status, who backports fixes and when you plan to rejoin upstream.
Why this case is awkward
Scanners often miss vendored code, because it is copied files and not a declared dependency. When they do find it, the usual fix path, upgrade the package, does not exist. Someone has to patch the copy by hand or replace it.
That makes it easy for vulnerabilities in vendored code to sit with no owner. The exception process must make ownership explicit.
Steps
- Identify the copy. Which upstream project, which version or commit, which files, and what changes you made locally.
- Check upstream. Is the vulnerability fixed in a later release? Is the project maintained?
- Choose a route. Rebase on upstream, backport the fix, replace the library, or accept for a short time.
- Assign an owner. A person or team responsible for the copy, not "platform".
- Record the exception with the above, plus an expiry that matches the work.
- Add the copy to inventory. If it is not in your SBOM, it will be missed again.
Decision table
| Situation | Preferred route |
|---|---|
| Upstream fixed, copy is unmodified | Replace the copy with a normal dependency |
| Upstream fixed, local changes exist | Rebase local patches onto the fix |
| Upstream unmaintained | Backport yourself or replace |
| Fork is intentional and long lived | Treat as your own code, track advisories explicitly |
Forks need an advisory watch
For a long lived fork, nobody tells you about new upstream advisories. Subscribe to upstream releases and security notes, and add a recurring review. See the post on reading and acting on advisories for a routine.
Exception record specifics
| Field | Content |
|---|---|
| Upstream project and commit | Exactly what was copied |
| Local modifications | Summary or patch link |
| Upstream fix status | Link and date checked |
| Owner | Named team |
| Exit plan | Rebase, replace or retire, with date |
Because there is no package version to key on, tie the exception to file paths and the recorded upstream commit, and update both when anything changes.
Common mistakes
- Treating vendored code as outside the scanner's scope, so nothing is ever flagged
- Patching the copy and forgetting to record that it was patched
- Exceptions with no exit plan, which quietly turn into permanent forks
Prevention
Prefer declared dependencies over copied code whenever you can. If you must vendor, add a short manifest file that says where the code came from, and have your scanner or inventory read it.
Safeguard's SBOM and dependency scanning and asset discovery help you find what is actually in your repositories, and its reachability analysis helps decide whether a flaw in a copied library can be reached.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how components are inventoried, then ask whether your vendored copies would show up.
Quick check
Can upstream's exception cover our fork?
No. Your fork is a separate artefact with your own code and risk. Make your own decision.
How do I find vendored code?
Search for copied library directories, check for bundled minified files and use an inventory tool that fingerprints source.
Last reviewed: 19 October 2026.
