Everyday Problems in Open Source Patch Management

A vulnerability is found, a patch is written, a new version is released. That is how you imagine the process. In practice, this is the best case — and it occurs less frequently than most companies assume.

The best case #

The project finds the root cause, fixes the problem correctly, and promptly releases a new version with the fix. You update the dependency, the vulnerability is closed.

This works with large, well-organised projects with full-time maintainers and structured release processes. For the majority of projects in a typical SBOM, the reality looks different.

Typical problems #

• The patch is insufficient. The correction fixes the reported symptom but not the underlying cause. The vulnerability remains exploitable — just via a different path.
• We write the patch, but it is not accepted. Maintainers reject contributions — for technical reasons, due to differing design preferences, or because they assess the security relevance differently.
• The patch is accepted, but there is no release. The fix is in the main development branch, but nobody creates a new version. Weeks, months, sometimes years pass without a release.
• The project is unmaintained. The patch is written, but there is nobody to apply it. There will be no review, no merge, and no release.
• We maintain a fork, but the toolchain does not follow. SCA tools and automated update pipelines only know the original project. They continue to pull the old, unpatched version.
• The maintainer disagrees with the assessment. Not every maintainer agrees that a problem is security-relevant. Without agreement, there is no fix.
• The fix causes a regression. The correction fixes the vulnerability but breaks existing functionality. Users face the choice between a security hole and broken software.
• The fix requires incompatible API changes. The correct remediation requires interface changes that downstream projects cannot adopt without rework of their own.

Why this is relevant for you #

Each of these scenarios means: a known vulnerability remains open even though a fix theoretically exists or could exist. Your compliance obligations do not distinguish between "no fix available" and "fix available but practically unusable". The legal expectation is clear:

• DORA Art. 9(4)(f) requires patch management as part of ICT risk management
• CRA Annex I Part II No. 2 requires the prompt remediation of exploitable vulnerabilities through security updates

"Just patch it" is not a solution when the reality of the open source ecosystem stands in the way. This is precisely why OTTRIA exists as an intermediary between your company and the open source world: we navigate these situations daily, know the maintainers, the processes, and the workaround strategies. When a patch is rejected, we maintain a fork. When a project is orphaned, we take over maintenance. When a release is missing, we coordinate with the community.

Further reading #

• Who actually maintains open source?
• Silent Fixes — the invisible threat
• Open source supply chain security

Stuck in one of these scenarios? OTTRIA resolves patch blockages in the open source supply chain. Talk to us.