Identifying and Tracking FedRAMP False Positives
False positives can make FedRAMP ConMon costly. Learn why it’s hard to accurately identify false positives and some tactics for making this process less challenging.
False positives can make FedRAMP ConMon costly. Learn why it’s hard to accurately identify false positives and some tactics for making this process less challenging.
False positives can make FedRAMP ConMon costly. Learn why it’s hard to accurately identify false positives and some tactics for making this process less challenging.
False positives can make FedRAMP ConMon costly. Learn why it’s hard to accurately identify false positives and some tactics for making this process less challenging.
False positives can make FedRAMP ConMon costly. Learn why it’s hard to accurately identify false positives and some tactics for making this process less challenging.
.png)
FedRAMP demands rigorous vulnerability management. But what happens when your scans are flooded with false positives – vulnerabilities that aren't actually exploitable in your application? These "phantom threats" can clog your continuous monitoring (ConMon) efforts, inflate your vulnerability count, and even hinder your compliance journey.
False positives and FedRAMP: A quick primer
In the world of FedRAMP, a false positive isn't just any vulnerability that's not "really there." It's a vulnerability that, while technically present, is unexploitable within the specific context of your application. Think of it as a theoretical weakness that poses no actual threat.
Why does this matter for FedRAMP? Because even false positives need to be documented and addressed in your Plan of Action and Milestones (POA&M). This can add unnecessary weight to your ConMon workload, potentially diverting precious time and resources from addressing real security risks, ultimately increasing the cost of your FedRAMP compliance program. As Ben Scudera from Fortreum, a FedRAMP 3PAO, points out:
"If your tools and processes are failing to identify and monitor every component, or if they’re failing to identify vulnerabilities in those components, you won’t meet the ConMon requirement — and your FedRAMP authorization could be at risk."
Deviation requests for false positives
If you don’t want to fix those false positives — after all they could account for 70-80% of your findings — FedRAMP has a deviation request (DR) process where you can get an exception from fixing the finding. The process requires you to submit an explanation and evidence showing the finding incorrectly indicates a given condition exists when it does not. That’s where things get hard. Depending on your tools, documenting a false positive (and crossing your fingers that the DR gets approved) might be more work than performing the upgrade.
Why it’s hard to identify false positives
A good SCA tool generates a list of your open source dependencies and correlates them to a vulnerability database, generating a list of findings that could threaten your organization. Your task is to separate the exploitable from the unexploitable. Making that determination demands a deep understanding of your application's architecture, dependencies, and code execution flow.
Problem #1: Limited time
Your first problem is going to be scale. Depending on the complexity of your application, your SCA tool is likely to find hundreds or even thousands of vulnerabilities. Under FedRAMP, there are aggressive remediation SLAs (between 30-180 days after discovery) depending on severity. This means your team is racing the clock to (1) figure out what needs to be fixed and (2) fix it fast enough to meet SLAs. When you’re dealing with this kind of volume, many teams choose to fix everything – even if they might be false positives – because the burden to research is too great. But in reality, few teams are actually able to fix everything because of resource constraints, so they’re at greater risk for failing SLAs.
Problem #2: Limited context
You might be using an SCA tool that offers reachability analysis as a method to discover what’s exploitable. However, before relying on this analysis (or trying to convince your 3PAO to accept it), you need to be confident that it’s accurate. And for that to be possible, you need to understand how the tool works. Most SCA tools use the package manifest to construct your dependency inventory. But a manifest is like a recipe: you don’t have to follow it to end up with an application (or a cake). Given that 88% of imported code goes unused, this means this kind of SCA tool will list many dependencies that your application doesn’t use. In this situation, the tool lacks the context to determine if a vulnerability is truly exploitable within the application's specific environment, and this justification is unlikely to be accepted by your 3PAO.
Solution: Function-level reachability analysis
You might be thinking, “Wait, didn’t you just imply that reachability analysis isn’t going to help?”
There are several types of reachability analysis, but just one has the potential to help you identify FedRAMP false positives to a standard accepted by your 3PAO: function-level reachability. As Scudera explains, "When it comes to application vulnerability scanning, a high-quality reachability analysis — that is, an automated way to demonstrate that there is no path for an adversary to exploit a given vulnerability — can provide strong evidence that a vulnerability is a false positive." This SCA technique analyzes if a vulnerability can be reached within a codebase by examining if the vulnerable function is called or used by other parts of the code.
It is important to be cautious when evaluating products that claim reachability analysis; it is, unfortunately, a fairly vague term in the industry. Key things to be cautious of:
- Ensure that an “unreachable” determination is high-confidence. It’s important to be able to distinguish between “we can’t determine whether this vulnerability is reachable” and “we’re confident this vulnerability is not reachable”, because the former will not meet the high bar for a false-positive classification. Not all tools make this distinction clear, which could undermine your efforts to reliably identify false positives.
- Make sure that “unreachable” means “from any source”. For example, consider a tool that only tells you that something isn’t reachable from the public Internet. That could potentially support a risk adjustment, but not a false positive determination on its own: an adversary with local-network access might still pose a risk. If your tool is able to tell you that something isn’t reachable without a code or configuration change, that’s a much stronger support for a false-positive determination.
Use Endor Labs to identify false positives
Endor Labs leverages a static analysis technique called program analysis to perform function-level reachability analysis. This means it goes beyond simply identifying the presence of a vulnerable component (e.g., a library with a known CVE). Instead, we examine the actual execution paths within your application's code to determine if the vulnerable function is ever called or invoked in a way that makes the vulnerability exploitable.
Here's a breakdown of how it works:
Call graph construction and vulnerability mapping
Endor Labs builds a detailed call graph of your application, mapping out the relationships between different functions and modules. It then maps known vulnerabilities (CVEs) to the specific functions they affect within the identified components.
Reachability analysis and false positive identification
By analyzing the call graph and the vulnerability mapping, Endor Labs determines if there is a feasible execution path that reaches the vulnerable function from an entry point in your application. If no such path exists, the vulnerability is flagged as unreachable and therefore a false positive. This means that even though the vulnerable code is present, it cannot be exploited within the context of your application.
Endor Labs identifies false positives and also helps you meet FedRAMP's documentation requirements. Here's how:
SBOM and VEX Generation
Endor Labs automatically generates a Software Bill of Materials (SBOM) and a Vulnerability Exploitability Exchange (VEX) document. These documents provide a detailed inventory of your software components and vulnerabilities, including identified false positives. This gives you clear evidence of false positives for those deviation requests and makes it easy to clearly track false positives in your POA&Ms.
Continuous Rescanning and Alerting
You can configure Endor Labs to rescan your applications on your preferred cadence (daily, weekly, etc.). Crucially, if a code change suddenly makes a previously unreachable vulnerability exploitable, Endor Labs will immediately flag it, ensuring you're always aware of any shifts in your risk profile. This proactive alerting helps you stay ahead of potential threats and maintain continuous compliance.
Book a demo to learn more about how Endor Labs makes it easier to comply with FedRAMP while also creating a better experience for your developers.
