In a past life, I was a Federal employee serving as a Technical Representative for the Joint Authorization Board (JAB), an entity that helps oversee and manage the process of authorizing cloud services for the FedRAMP marketplace. I’ll start off here with a quick overview of FedRAMP, and then we’ll dive into details on FedRAMP’s vulnerability management requirements.

What is FedRAMP and why does it matter?

FedRAMP — the Federal Risk and Authorization Management Program (FedRAMP) — provides a pathway for Cloud Service Providers (CSPs) to get their Cloud Service Offerings authorized for use across the United States federal government. It involves leveraging security control baselines, derived from NIST’s 800-53 control catalog, and has three authorization levels (Low, Moderate and High) with progressively greater controls and implementation rigor.

All of this may not sound interesting if you’re unaware of this fact: the U.S. federal government spends tens of billions each year on IT and software. This makes it a massively compelling target for cloud-native vendors (including SaaS) because it represents a large addressable market with sizable long-term contract opportunities. FedRAMP authorization is a business priority for many CSPs, and financially well worth the headaches (and staff investment) that come with it. FedRAMP is also becoming viewed as an industry standard, with software consumers asking their vendors about FedRAMP compliance. Being able to demonstrate compliance is a valuable differentiator that helps business growth.

FedRAMP vulnerability management requirements

When a CSP becomes FedRAMP authorized, they enter a phase known as Continuous Monitoring, or “ConMon”. ConMon involves continuously maintaining and monitoring the security and compliance of your environment. This is facilitated through the combination of people, process, and technology. It includes vulnerability scanning policies and procedures, and the vulnerability scanning tools used to identify and prioritize vulnerability remediation— such as software composition analysis (SCA).

FedRAMP provides a standalone Vulnerability Scanning Requirements document that lays out the key considerations to maintain FedRAMP compliance. Without going too far in the weeds, most systems require authenticated scanning and full system authorization. The outputs must be in machine-readable formats (e.g. XML, CSV or JSON) and must use CVSS as the original risk rating if the scanning supports it. 

Third party dependencies and SLAs

There are very specific requirements for third party components, including open source software (OSS) found in your applications and containers. All dependencies must be inventoried, scanned, and their associated vulnerabilities accounted for — on a monthly basis — which of course is a challenge for SaaS and containerized applications. 

Each vulnerability must be tracked as “Plans of Actions and Milestones” (POA&M), and must be remediated within a strict vulnerability remediation timeline (commonly called SLAs, or service level agreements). Any non-remediated vulnerabilities must also be tracked and submitted as part of the CSP’s initial authorization and ConMon activities. 

When a vulnerability is discovered, you must remediate within the following timeframes.

• High (CVSS 7.0 and higher): 30 days
• Medium (CVSS 4.0 to 6.9): 90 days
• Low (CVSS under 4.0): 180 days

All exploitable vulnerabilities must be fixed, regardless of severity or probability of exploit. For example, a vulnerability with a CVSS 1.0 (low) still has to be remediated or mitigated; it is not acceptable under FedRAMP to accept this risk. This emphasizes the need to have a modernized comprehensive approach to application security testing and the ability to identify vulnerable dependencies, and also streamline the process of fixing those vulnerable dependencies, to avoid the cumbersome activity of manually tracking and monitoring them all. 

Special requirements for container images

Container dependency vulnerabilities fall under the same broader vulnerability management and remediation requirements of broader systems, software, and databases. However, FedRAMP also has specific guidance and requirements for scanning systems using container technologies. These requirements include the use of “hardened images”, or images where aspects such as vulnerabilities of dependencies, misconfigurations, alignment with DISA STIGs, CIS Benchmarks, and more must be considered. They also prohibit the use of containers with vulnerabilities listed on CISA’s Known Exploited Vulnerability (KEV) catalog.

The vulnerability scanning requirements also dictate that images be scanned through the deployment pipeline process, and you must deploy security sensors to continuously inventory production deployed containers and their associated security posture. The scanning and monitoring requirements for containers apply in runtime, pipelines, and registry environments. 

How to make FedRAMP vulnerability management more manageable

I’ve experienced FedRAMP vulnerability management first hand, both on the government side and within CSPs. It is a massive exercise to properly implement vulnerability management and manage all of the associated POA&Ms within the required SLAs. But there are steps you can take to greatly reduce the toil of tracking and managing all of the identified vulnerabilities.

Step 1: Get risks out of scope

Not all risks are exploitable within the context of your application. You can greatly reduce the number of risks to remediate by getting unexploitable risks marked as false positives, putting them out-of-scope for FedRAMP.

The most effective way to get a vulnerability marked as a false positive is to establish that it is not reachable: meaning the vulnerability cannot be exploited at the function level. Endor Labs’ research indicates that, on average fewer than 9.5% of vulnerabilities are exploitable at the function level in a given application. While reachability can be determined manually, it is a time-consuming task which requires highly-skilled practitioners. It’s better left to a tool that can do it automatically.

FedRAMP also allows for de-duplication of findings, meaning if two or more tools find the exact same instance of a vulnerability, then those separate findings are really one unique vulnerability. This scenario commonly happens with OSS dependencies that are used in containerized applications: The dependency is first used in the application and then once containerized, it’s also in the container image. Therefore a SCA tool and container scanning tool can find the same vulnerability in two different dependencies. Under FedRAMP they’re both still in scope, but it lowers the total number you have to address. This is why it’s really valuable to scan containers pre-deployment, so you can find these duplicated vulnerabilities at the same time they’re discovered by your SCA— and eliminate both instances.

Step 2: Seek a risk level adjustment

You’ve gotten those unexploitable vulnerabilities marked as false positives, but you might still have dozens (hundreds, or even thousands) of high risk findings to remediate within 30 days. That might be an impossible task. But there’s good news: you can get the risk rating lowered if you can demonstrate the actual risk the vulnerability poses is lower than what its base CVSS score suggests.

One way to make this argument to your Third Party Assessment Organization (3PAO, also known as auditors) is with the Exploit Prediction Scoring System (EPSS), which is fast becoming an AppSec industry favorite for accurately estimating the likelihood that a vulnerability can be exploited in the wild. A very low EPSS probability (e.g. under 1% of exploit) can be used as evidence for a level adjustment. Endor Labs found that 4 out of 5 reachable vulnerabilities have a 1% or less predicted chance of being exploited, so you may be able to successfully adjust a large volume of vulnerabilities, buying you extra time to remediate.

Keep in mind: The maximum number of level adjustments is two, and there is no option to take the risk to zero (unless it’s a false positive). Requesting a level adjustment is about buying time, not eliminating the requirement.

Step 3: Prioritize fixes based on ROI and complexity

You might think that remediations should be performed in order of greatest risk to least. But also consider this: not all dependency upgrades are equal. Some are very complex while others are simple. Upgrades have varying levels of return on investment (ROI) and complexity that (when you understand them) can be used to accelerate remediation.

ROI: Let’s say foo-bar v4.12.1 has 14 high risk vulnerabilities that are all reachable with an EPSS of 1% or more. A typical security practice is to send each of those 14 vulnerability findings back to devs, each with separate instructions on which version upgrade will remove the vulnerabilities. But that’s inefficient. Fixes for these various vulnerabilities were undoubtedly introduced across several subsequent versions, and developers think in terms of “dependencies”, not “vulnerabilities”. For example, upgrading to v4.13.0 might only fix 6 of those vulnerabilities, while upgrading to v5.1.8 fixes all of them. The more effective way to get these vulnerabilities fixed quickly would be to send a single instruction to upgrade foo-bar v4.12.1 to v5.1.8.

Complexity: How many vulnerabilities you can fix with a single upgrade is one part of the puzzle. The other part is how difficult will this upgrade be? An upgrade can cause unforeseen problems that can extend the amount of time it takes to get rid of vulnerabilities. Our research shows that 95% of version upgrades contain at least one potentially breaking change, and that includes both major and minor upgrades!

In a situation like this, you’ll want to make sure engineers are aware of challenges up front, before they try (and probably fail) to perform an upgrade. This way your organization isn’t rushing complex changes at the wire to meet a FedRAMP SLA; but you can also flag upgrades that are likely to be quick and easy so you can rapidly reduce your risk exposure.

Step 4: Empower developers to prevent risk

Perhaps this is obvious, but the fewer risks that enter production, the fewer you have to fix under FedRAMP requirements. Many organizations are evolving their vulnerability management programs to empower developers to prevent vulnerable dependencies from entering production. This works by implementing application security testing (like SCA) in their pipelines and creating policies to identify unacceptable risks. When they submit a pull request (PR) that triggers a policy, the developer is immediately warned — or you can even choose to break the build — and can replace the vulnerable dependency on the spot.

How Endor Labs Can Help With FedRAMP Compliance

Endor Labs helps you achieve the open source vulnerability scanning and continuous monitoring requirements of FedRAMP, while reducing your compliance costs.

Get risks out of scope and seek level adjustments

Advanced SCA capabilities with function-level reachability analysis that:

• gives you complete and accurate identification of software components and associated vulnerabilities
• identifies potential false positives (like unreachable vulnerabilities) and out-of-scope components (like dependencies only used by test code in CI/CD)
• arms you with contextual data you need to request risk adjustments where appropriate. 

Container vulnerability scanning identifies vulnerabilities at each layer of container images, and correlates findings with SCA scans to avoid duplication of items.

Prioritize based on ROI and complexity

Identify your hardest upgrades and patches, so you can start work on them right away. Find low-hanging fruit to crush quickly. Choose the upgrades that fix the most risk to limit your exposure to attack. All with an upgrade impact analysis that identifies risk of upgrades breaking your applications specifically.

And for the complex but critical upgrades, deploy Endor Magic Patches that remove the security risks without introducing the breaking changes that make those complex patches so expensive to deploy.

Empower developers and ops teams to prevent risk

Give developers information that’s relevant to what they’re working on, right in the systems where they already work (like GitHub, Jira, Slack, and more), with powerful and flexible policies and integrations. It’s so much easier to fix problems when they first appear!

And make your ops team’s lives easier with low-code / no-code artifact signing and verification that provides a strong layer of assurance and prevents regressions -- revoke a signature of a container or application package that’s outdated, and new instances can no longer be deployed. Support NIST 800-53 section SI-7(15) code signing requirements designed to ensure that only authorized applications, containers, and other deployment assets can run in your FedRAMP environment.

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.