Check whether your product actually reaches the vulnerable code, tell the upstream maintainers privately, plan a mitigation or patched build for your customers, and agree one timeline with the reporter. Do not publish details that put the upstream project's users at risk before they have had a chance to fix it.
Two jobs in one case
A flaw in a dependency creates a downstream problem and an upstream problem. Downstream is your product: are you affected, and what will you ship? Upstream is the library: someone must fix it for everybody. The CERT Guide to CVD advises, for reports outside a vendor's own code, to redirect the reporter or contact the upstream vendor. It also advises giving affected downstream vendors information early where they are known.
Steps
- Validate in your build. Reproduce using the library version you ship. Note how your product calls it.
- Check reachability. Does your code path actually call the vulnerable function with attacker controlled input? A flaw that cannot be reached is lower priority for you, but still matters to others.
- Check whether upstream already knows. Look at the project's advisories and issue tracker policy. Find its security contact before writing anything public.
- Ask the reporter. Have they contacted upstream? If not, offer to do so with their consent, or share the contact.
- Agree one clock. Two embargoes running in parallel invite confusion.
- Plan your customer response. Options: upgrade the library, apply a vendor patch, disable a feature, add input validation in your layer, or ship a workaround.
- Publish your own advisory when you have something to say, naming your affected versions and fixed versions, and linking the upstream record when it exists.
Decision table
| Finding | Action |
|---|---|
| Reachable, upstream unaware | Notify upstream privately, plan mitigation |
| Reachable, upstream fix exists | Upgrade, release, publish |
| Not reachable in your product | Document why, still tell upstream, update when safe |
| Reachable, upstream abandoned | Patch or replace, tell customers plainly |
Be careful with fixes in your own copy
If you carry a local patch, share it with upstream rather than keeping it private. A private fork that fixes a vulnerability and is never shared leaves everyone else exposed and leaves you maintaining it alone.
Credit and wording
Credit the reporter in your advisory and make clear that the flaw lies in the library. Do not blame the upstream maintainers, who are often volunteers. Name the library, the affected range, and what you did.
Try it yourself
The reachability demo shows how many dependency findings disappear once you ask whether the vulnerable code is called. Click through it and compare the lists before and after.
Click through it at your own pace, or open it full screen.
Quick check
Do we wait for upstream before telling customers?
Not if customers can protect themselves. Share a mitigation without publishing exploit detail, and coordinate wording with upstream if you can.
Can we disclose if upstream does not respond?
The CERT guide discusses non responsive vendors in terms of weeks of silence and courtesy notice. Check your own policy and take advice before going public.
Safeguard's reachability analysis, SBOM and dependency scanning are built for this question, showing which dependencies you ship and whether flagged code is reached. The free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
