Upstream first means you submit your patch to the original open source project, and then pull the accepted change into your own product. It avoids carrying a private fork that you must re-apply after every release. For security fixes, it also means following the project's private reporting route, not a public pull request.
Definition
The Linux Foundation guide on creating an open source program recommends that organizations adopt an upstream-first development policy. By submitting patches to the upstream project first, and incorporating them downstream, you avoid spending a large amount of time and money on re-engineering after each release.
Upstream is the project you depend on. Downstream is your product or fork. The policy sets the direction of flow: fixes go up, then come back down in a release.
Why it pays off
- Less drift. A private fork diverges with every upstream release, and merging gets harder each time.
- More eyes. Maintainers and other users review your change.
- Shared fix. Other users stop hitting the same bug, and you stop paying alone.
- Cleaner audit story. You can say the fix is in a public release, not a one-off patch.
The security twist
A security fix is different from a feature. Publishing the exploit details in a public pull request before a release can put every user at risk. The right sequence is:
- Check the project's security policy (a SECURITY.md file or a private reporting channel).
- Report privately and offer a patch if the maintainers want one.
- Agree on a disclosure timeline.
- Ship a temporary mitigation downstream if you cannot wait.
- Remove the temporary patch once the upstream release lands.
If you are the reporter and unsure how, see how to report a vulnerability in an open source project.
When not to go upstream first
| Situation | Better move |
|---|---|
| The change is specific to your business logic | Keep it in your own layer |
| The project is abandoned | Fork, with an owner and a review date |
| The change contains confidential code or data | Do not send it, rewrite it clean |
| The maintainers decline the design | Carry the patch deliberately, with a written reason |
An abandoned project is its own risk class. See how to tell if an open source project is still maintained.
What to write in your policy
Three sentences are enough for a small company:
- We send generic fixes to the upstream project before shipping them.
- Security issues go through the project's private channel, never a public issue.
- Any patch we carry has an owner, a ticket and a review date.
Tracking carried patches
Each local patch is a debt. Record it with the upstream issue link, the component version, and the condition for removal. Review the list whenever you upgrade the component. A patch that has been merged upstream should be deleted, not kept as a safety net.
Safeguard's SBOM and dependency scanning shows which component versions you ship, and autonomous remediation can open fix pull requests for upgrades. It is off by default, with every category set to Manual, so a person approves each change. See a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how an upstream fix turns into an upgrade you can review.
Quick check
Does upstream first slow down a security fix?
It can, if you wait on a release. Apply a documented temporary mitigation downstream and remove it when the upstream release ships.
Can we contribute a security fix as a normal pull request?
Not until the maintainers agree. Use the private reporting route first, then follow the disclosure timeline.
Sources
Last reviewed: 19 October 2026.
