The ‘F’ Frameworks
Michael Winser of the Alpha-Omega project recently wrote a blog on the Three F framework for managing the risk coming from the open source dependencies. Here is a list of the key points made in that article.
-
- Open source projects treat their upstream supply chain with the same level of apathy as that shown by their downstream commercial consumers.
- When it comes to dependencies, all of them pose the same level of risk.
- The three F’s are: Fixing a dependency issue by upgrading it, Forking a dependency to take ownership of a situation when upstream support is not available and Forgoing or removing a dependency to reduce risk.
- In the article, Michael Winser suggests a fourth F, Funding, which is what the aim of Alpha-Omega is as an organization.
The Six ‘F’ Strategies: From Vulnerability to Vigilance
1. Fix: The First Line of Defense
When a patch exists, applying it is the simplest yet most overlooked step. When the information about a vulnerability is published as a CVE, most of the time a fix is already available in a new release of the vulnerable package. If the package is a direct dependency, a downstream consumer can fix the dependency to mitigate the risk coming from the CVE.
Even for the new bugs found by Project Clean Beach in a dependency, in many cases we find that the bug is fixed in a subsequent version. For example, we reported that the insecure HTTP protocol was used instead of HTTPS in the org.fusesource.jansi:jansi package (version 1.11) which is a direct dependency of org.jenkins-ci.main:jenkins-core. This has been fixed in version 2.4.1 of the package which was released in October 2023. From the perspective of jenkins-core, the dependency should be upgraded to mitigate the risk.
When a fix is available in a subsequent version but the package is an indirect dependency, the situation becomes more complicated. In some cases, the package is reached transitively but a direct dependency in that chain also has an upgraded version available that has upgraded the vulnerable package. For example an insecure deserialization vulnerability was found in version 6.8.13 of the org.testng:testng package. This bug is fixed in version 7.5.1 and later.
But the package is an indirect dependency of the org.jenkins-ci.main:jenkins-core package. However, jenkins-core depends on this vulnerable package through another package, org.codehaus.groovy:groovy-all version 2.4.21, which is its direct dependency. A subsequent version of the package is available for org.codehaus.groovy:groovy-all, version 3.0.23, which updates the dependency of the org.testng:testng to version 7.5.1 which does not have the deserialization vulnerability.
Therefore, fixing the dependency for groovy-all fixes the problem.
Updating dependencies isn’t just about closing gaps. It’s a signal to maintainers that security is a shared priority. By automating updates and prioritizing fixes, teams not only protect themselves but also reinforce a culture where timely patches become the norm, not the exception.
3. Flip: Pivoting to Healthier Alternatives
Not every vulnerability warrants panic. Low-impact CVEs, like minor memory leaks in non-critical systems, can drain resources if over-prioritized. “Forgetting” is about triage—ignoring noise to focus on real threats. This doesn’t mean complacency; it means trusting teams to distinguish between a spark and a wildfire. In a world drowning in alerts, discernment is a superpower.
The 2021 ua-parser-js hijacking incident shows why small dependencies deserve scrutiny. This lightweight library, used by millions to parse user-agent strings, was compromised when a malicious actor hijacked its npm account and pushed versions containing malware. Overnight, projects relying on it, from analytics tools to enterprise applications, faced potential ransomware and data theft.
While rewriting such utilities in-house isn’t trivial, the incident underscores a harsh truth: convenience often masks risk. For critical workflows, “forgoing” means trading fleeting ease for long-term security. Teams burned by ua-parser-js, for instance, began maintaining minimalist internal parsers, eliminating a single point of failure. The lesson? No dependency is too small to ignore when it sits in the crosshairs of supply chain attackers.
Why These Strategies Reshape the Ecosystem
The Six ‘F’ approach isn’t just about survival—it’s about reshaping how the open-source world operates. Fixing and forging create a ripple effect, encouraging maintainers to prioritize security as a collective duty. Flipping and forking redirect attention to sustainable projects, weeding out stagnation. Forgetting and forgo teach balance: knowing when to act, when to wait, and when to take the wheel.
But this shift isn’t frictionless. Pressuring maintainers to update dependencies risks burnout unless paired with support. At the same time, forking fragments effort and can strain resources. Yet, these strategies acknowledge a hard truth: in a decentralized ecosystem, security demands both collaboration and self-reliance.
Conclusion: Rewriting the Rules of Reliance
Software supply chain attacks exploit our interdependence. The Six ‘F’ Strategies don’t eliminate that interdependence, they make it resilient.
The open-source ecosystem thrives on trust, but trust alone isn’t a strategy. It’s time to pair idealism with pragmatism, ensuring that the code connecting us doesn’t become the weapon that divides us. After all, the future of software isn’t just about writing code, it’s about rewriting how we protect it.
Credits
Md Abdullahil Kafi, secure software engineer of OpenRefactory, wrote this post.
