Address Open Source Risks with Endor Labs
Fixing open source risks involves accepting, mitigating, or remediating the risk, but that’s easier said than done. Learn how predicting the effort of an upgrade helps you accurately plan and prioritize— and fix things faster.
Fixing open source risks involves accepting, mitigating, or remediating the risk, but that’s easier said than done. Learn how predicting the effort of an upgrade helps you accurately plan and prioritize— and fix things faster.
Fixing open source risks involves accepting, mitigating, or remediating the risk, but that’s easier said than done. Learn how predicting the effort of an upgrade helps you accurately plan and prioritize— and fix things faster.
Fixing open source risks involves accepting, mitigating, or remediating the risk, but that’s easier said than done. Learn how predicting the effort of an upgrade helps you accurately plan and prioritize— and fix things faster.
Fixing open source risks involves accepting, mitigating, or remediating the risk, but that’s easier said than done. Learn how predicting the effort of an upgrade helps you accurately plan and prioritize— and fix things faster.
This article is the final part of our 3-part series on vulnerability prioritization workflows:
- Discover Open Source Risks with Endor Labs (Part 1)
- Prioritize Open Source Risks with Endor Labs (Part 2)
- Fix Open Source Risks with Endor Labs (this article)
The “vulnerability prioritization workflow” is one of the primary areas of responsibility for an AppSec team. And while that workflow will vary from place to place, they can all be summarized in a three-step process:
- Discover risks— Identify the vulnerabilities that could threaten your business.
- Prioritize risks— Eliminate irrelevant findings and determine are the greatest threats.
- Address risks— Accept, remediate, or mitigate the vulnerabilities.
Software composition analysis (SCA) tools are a common part of this workflow, used to automate toil so AppSec owners with limited resources can focus on higher-order tasks. In this series, we talk about the role SCA can play, shortcomings you might encounter, and what “better” looks like. We covered identifying risk and prioritizing risk in the first two blogs, and now we tackle the process of fixing risk.
Upgrading is harder than it sounds
So you found a vulnerability in a dependency… To the uninitiated, fixing a vulnerability might seem trivial. Just upgrade to a version where the CVE has been patched and go on your merry way, right? Wrong. ;)
Application security teams are often accountable for security but not responsible for changes to the product they are tasked with protecting. They need others to do work. When you need someone else to do work you spend their trust in you and your credibility in the organization each time.
More often than not, “simple updates” introduce other risks such as breaking changes, new bugs, performance issues, or specificity in version constraints that must be corrected. These hidden risks turn what can be perceived as trivial tasks into hours or days of effort refactoring code depending on what changed between the versions of a software component.
But we’re getting a little ahead of ourselves. In the “address” stage of vulnerability management, it’s not a simple matter of “go fix things”... there’s more triaging to be done because you’re still working with limited resources and an “upgrade them all” strategy isn’t usually feasible.
Accept risks that don’t present serious harm
The first option is to accept the risk, meaning you’ve determined that the cost of remediating or mitigating the risk is not worth the ROI. If you have good prioritization capabilities (like function-level reachability), it should be straightforward to decide which risks to accept, and you may even be able to automate risk acceptance. For example, you can decide a low criticality vulnerability with an EPSS vulnerability of 0.5% is not sufficient risk to the business to merit remediation or mitigation.
Remediate or mitigate serious risks
Remediating and mitigating often get lumped into the same action, but they’re subtly different:
- Remediation: Address the root cause of a vulnerability by neutralizing or eliminating the vulnerability or the likelihood of its exploitation. For example, you can remediate a vulnerability by upgrading to the closest non-vulnerable version.
- Mitigation: Reduce the risk to an acceptable level without completely removing the root cause. For example, you might mitigate a vulnerability by applying a patch that fixes the security problem without changing versions.
Deciding between remediation and mitigation tends to be influenced by how “hard” it is to move to a non-vulnerable version. The typical pattern is for a developer to try bumping the version and testing, and if it fails the conclusion is there were too many breaking changes. That is, changes to the code between versions that cause the application to behave differently or fail.
To get an idea of how often breaking changes occur across upgrades, we looked at 1250 patch-to-fix vulnerabilities and found that nearly all upgrades contained breaking changes.
- 24% of vulnerability fixes required a major version upgrade to remediate, which frequently means they will have significant breaking changes.
- Of the remaining 76% that are fixed by upgrading to a new minor or patch version, 94% of those upgrades also contained at least one potentially breaking change.
To achieve an understanding of the effort and risk of a dependency upgrade, developers need an accurate understanding of how the software dependencies interact. This research drags out the remediation timeline so it’s no wonder practitioners are looking to SCA tools to speed up this process.
Traditional SCA provides remediation recommendations without context
The traditional SCA industry hasn’t meaningfully improved an organizations’ ability to address risk, which can be traced to two problems:
- Lack application context: Because the tools don’t understand how dependencies interact within a specific application, they aren’t able to predict how version changes could cause breaking changes, new bugs, performance issues, or specificity in version constraints that must be corrected.
- Insensitive to developer pain: The industry has been very AppSec-focused, both for user experience and program outcomes. This is most obvious when you look at the developer experience for vulnerability findings. Many tools require developers to leave their SCM (e.g. GitHub) to review findings, and many are so noisy that developers have to spend time researching the findings to determine if they are actually exploitable. A tool that already doesn’t prioritize developer experience is unlikely to tackle high-quality fix intelligence.
Upgrade instructions and auto PRs are naive about impacts
Given these constraints, AppSec owners have limited success using SCA tools for fix intelligence. Assuming there is a patched version available, most SCA tools tell you a) what’s the first version containing the patch and sometimes b) what are a range of versions containing the patch. This is useful in that it alleviates having to look up the information in the repo but it doesn’t tell you the risk of performing the upgrade.
Some tools take upgrade recommendations a step further by allowing you to automatically opens a Pull Request (PR) that upgrades the vulnerable dependency to the closest non-vulnerable version. If the tests pass, fantastic! But when they fail, it’s up to developers to decide what to do about it - which might not result in the vulnerability getting remediated. And because these recommendations are ignorant about how your dependencies interact, an auto PR is more likely to select an upgrade that breaks. So while Auto PRs can save time by automating some vulnerability remediation, there’s a chance there will be unintended consequences that require developer intervention to troubleshoot and fix.
There’s a better way to do SCA: fix risks faster with Endor Labs
The problems with traditional SCA tools all stem from the same source: They don’t understand how your 3rd-party dependencies interact with your application code. A tool that doesn’t understand your application can’t predict the impact of fixing risks.
You should expect more from SCA. Your SCA tool should do more than show you problems: It should also give you solutions.
We broke down all the assumptions about how an SCA tool should function and came up with something entirely new. By using program analysis at the time of build, Endor Labs can see exactly what is in your 3rd-party dependencies and how they interact with your application code. When an SCA tool understands how your application works (including direct and transitive dependencies), you can speed up remediation because you can accurately predict the effort of an upgrade and help engineering accurately plan and prioritize remediation efforts.
The following is an example of a vulnerability prioritization workflow you can enable with holistic context into both the operational and security risk associated with updates for a software dependency.
When a new vulnerability hits headlines, security engineers can:
- Prioritize if the vulnerability is relevant in the context of your application
- Prioritize the urgency of the fixes
- Assess your remediation efforts based on an operational risk assessment of implementing a fix.
There are two ways you can reduce the possibility of a breach or failed audit: remediate (by switching to a non-vulnerable version) or mitigate (change factors that lead to risk). We help you achieve both.
Predict breaking changes (and more) with upgrade impact analysis
We go beyond telling you about the closest non-vulnerable version, and actually use your dependency call graph to determine a) how many findings can be fixed by a given upgrade, b) the complexity of the upgrade, such as version conflicts and breaking changes. For each dependency upgrade, we assign a remediation risk rating:
- High Risk = Upgrading is very likely to break your application at multiple points
- Medium Risk = Proceed with caution: upgrading has a moderate chance of breaking your application
- Low Risk = you're probably good: upgrading has a very low chance of breaking your application
Use this information to have an informed conversation with engineering about which vulnerabilities to fix right now (for example, a low risk upgrade) vs. which to add to the long term backlog because they need substantial developer hours to implement without negative impacts.
Mitigate hard-to-upgrade risk with Endor Patches
Some upgrades are going to be really hard and might take months or years. Yet your auditor (or CISO!) needs it fixed now…what are your options? With Endor Patches, we eliminate the hassle of hard-to-perform upgrades by providing security patches so you can stay safe and compliant while working to upgrade properly or lower the risk enough that it’s acceptable as-is. Originally created by the OSS package maintainers, we “backport” patches to your vulnerable version and maintain them for your security and convenience.
SCA that meets your expectations
With the Endor Labs approach to SCA, you can stop stressing about hidden risks, noisy tools, and mysterious upgrades. We provide:
- Faster risk reduction
- Improved developer productivity
- Accelerated compliance management
Book a 20-minute demo to learn how Endor Labs turns your vulnerability prioritization workflows dreams into a reality or start a free, full featured 30-day trial that includes test projects and the ability to scan your own projects.