Tech Support
Documentation
Login
Contact Us
Go straight to an AI summary of this blog post instead 
Key Takeaways
- The Federal Risk and Authorization Management Program (FedRAMP) Revision 5 (Rev5) playbook requires providers to upload an updated plan of action and milestones monthly.
- FedRAMP’s Consolidated Rules for 2026 set December 7, 2026, as the adoption date for new vulnerability rules, with grace ending March 7, 2027.
- An unfixed finding remains in the provider’s monthly reports until it’s remediated, and the 2026 rules require it to be labeled an accepted vulnerability if it isn’t fully mitigated or remediated within 192 days of evaluation.
- Base images, pinned dependencies, and abandoned components keep the same open source findings coming back until someone changes the build.
- A platform team can schedule base image rebases, measure recurring findings, and decide early what to do about components with no upstream fix.
FedRAMP continuous monitoring (ConMon) requires a cloud service provider to upload an updated plan of action and milestones (POA&M) every month. Each unique vulnerability gets its own item in it. If a component in your build still carries an open finding, that finding tends to stay on the POA&M next month. That’s the Revision 5 (Rev5) path in the Continuous Monitoring Playbook from FedRAMP, the Federal Risk and Authorization Management Program.
A finding that comes back every month puts the same open source choice in front of reviewers again, and that is what the title means by re-litigating. On the Rev5 path, the Playbook points multi-agency ConMon meetings at past-due items, vendor dependencies, and anything that needs risk acceptance. Assessors also validate deviation requests and vendor dependencies at every annual assessment. Under FedRAMP’s 2026 rules, a finding still not fully mitigated or remediated 192 days after evaluation must be labeled an accepted vulnerability, with a written explanation of why. Starting in 2027, every agency customer will also see a summary of accepted vulnerabilities each quarter.
FedRAMP’s 2026 rules also say providers should design their service to reduce vulnerability risk by default. For open source components, that means choosing what goes into your build, and your platform team makes those choices.
How FedRAMP Continuous Monitoring Works Month to Month
On the Rev5 path (Playbook version 1.0, November 17, 2025), the provider scans operating systems, web applications, and databases at least monthly. It then uploads the updated POA&M and inventory, plus raw scan files when its agency agreements call for them. The agency’s authorizing official reviews the POA&M and approves deviation requests, which ask the agency to treat a finding as a false positive, a risk adjustment, or an operational requirement.
FedRAMP’s Consolidated Rules for 2026 (CR26) launched on June 24, 2026. Two of their rulesets, Vulnerability Detection and Response and Vulnerability Evaluation and Reporting, cover Rev5 Classes B to D and Classes B and C on 20x, FedRAMP’s newer certification path. Some cadences depend on both the path and the class. Early adoption opened on July 4, 2026. New applicants must follow the rulesets from December 7, 2026. Existing providers should adopt them by that date or face a corrective action plan. On March 7, 2027, the grace period ends, and FedRAMP revokes certification for providers that haven’t.
| Item | Rev5 Playbook v1.0 | CR26 vulnerability rules, as of October 15, 2026 | Basis |
|---|---|---|---|
| Scanning and verification | Operating systems, web applications, and databases are scanned at least monthly | Rev5 Class C and D providers must verify and validate machine-based resources at least monthly (Class B providers should). 20x Class C providers must do so every 3 days. | FedRAMP requirements |
| Monthly report | Updated POA&M and inventory | Vulnerability activity reported at least monthly in a consistent, human-readable format. Reports also summarize all activity since the previous report (Rev5 Classes B to D). | FedRAMP requirements |
| Unfixed findings | Tracked as POA&M items. Deviation requests need agency approval. | Must be marked as an accepted vulnerability, with an explanation, if it is not, or won’t be, fully mitigated or remediated within 192 days of evaluation. | Playbook guidance from the program office; CR26 requirement (MUST) |
Where Unfixed Findings Go After the First Report
On the Rev5 path, an unfixed finding is tracked on the POA&M with a remediation plan, and the provider can file a deviation request for the agency to decide on. A POA&M item that depends on an upstream vendor is tracked as a vendor dependency.
For a provider with more than one agency customer, the Playbook describes a monthly collaborative ConMon meeting. It says that covering every POA&M item isn’t practical, particularly those the provider expects to fix within FedRAMP’s prescribed timeframes. The discussion should center on past-due items, vendor dependencies, and deviation requests, especially those requiring risk acceptance. So, a finding that remains open past its due date is meant to come up in front of every agency in the group.
From the FedRAMP Consolidated Rules for 2026: FedRAMP recommends that agencies review only overdue and accepted vulnerabilities with a Potential Agency Impact N-rating above 2, unless the provider recommends mitigations or the service sits in a higher-risk federal system. The N-rating, from N0 to N5, is the provider’s estimate of the extent of harm exploitation could cause to the agencies using the service. Accepted vulnerabilities generally need review only when they’re added or when the agency’s use changes.
The 2026 rules also limit how long a provider can leave a finding open while planning to fix it. It must categorize any vulnerability that is not, or won’t be, fully mitigated or remediated within 192 days of evaluation as an accepted vulnerability. From then on, each monthly report explains why, whether the vulnerability is internet-reachable, whether it’s likely exploitable, and its current N-rating.
| Outcome | What the rules say | Basis |
|---|---|---|
| Partial mitigation | Reduces risk without removing the vulnerability. When full mitigation or remediation isn’t possible, providers should do this promptly, progressively, and persistently. | FedRAMP guidance note (SHOULD) |
| Full mitigation | Reduces risk to a negligible level, but the vulnerability still exists until it’s remediated. | FedRAMP guidance note |
| Remediation | Eliminates the vulnerability entirely. | FedRAMP guidance note |
| Accepted vulnerability | Label for a vulnerability the provider doesn’t intend to fully mitigate or remediate. Required once a vulnerability is not, or won’t be, fully mitigated or remediated within 192 days of evaluation. The provider must report why. | Definition; requirement (MUST) |
| False positive | Providers should evaluate detected vulnerabilities to determine whether they’re false positives. | Recommendation (SHOULD) |
Accepting a finding shifts the risk decision to your customers: each agency decides whether to continue using the service with the finding open, and FedRAMP asks agencies to track that decision in their own POA&M.
Why the Same Open Source Findings Keep Coming Back
For containerized systems, the Playbook requires a unique asset identifier for each class of container image and ties every production container back to its source image. It also says software patching should happen on the replacement image, never directly on the production environment. So a vulnerable package in a base image tends to show up in every container built from it, and the usual fix is to build a new image. Until someone rebases, the package set tends to stay the same, and the finding comes back with it.
Pinned dependencies behave the same way. A lockfile keeps a library at the version you chose, so a library with an open advisory stays at that version until somebody changes it. For an actively maintained component, the way out is a fixed release from upstream that someone then brings into your build. Upgrading carries its own risk, and our post on why “just upgrade it” is poor security advice covers it.
When upstream stops maintaining a component, new vulnerabilities can still be disclosed against it, but a fixed release usually isn’t coming. The finding then stays open until the component is replaced or someone patches the version you run, even after the 192-day mark forces an accepted label. A service rarely sticks to one language, so abandoned components can pile up across several ecosystems at once.
What Scanners Don’t Tell You About a Package
Scan output is built around known vulnerabilities. The Playbook requires the Common Vulnerabilities and Exposures (CVE) reference number in machine-readable findings for any vulnerability listed in the National Vulnerability Database. The 2026 rules say that older FedRAMP guidance generally focused on CVE-type vulnerabilities and left other types unaddressed, and the detection rule lists supply chain monitoring among the techniques providers use.
The scanners and other FedRAMP continuous monitoring tools a provider runs report on what’s in the build. A package that was tampered with or built from something other than its public source, may not show up as a CVE finding, and a malicious package may have no CVE at all. A software bill of materials (SBOM) has the same blind spot: a component can be listed accurately yet still be tampered with. Both describe what arrived, and neither says whether it should have.
What Platform Engineering Can Change Before the Next Report
If you own the build behind a FedRAMP continuous monitoring cycle, you can change what the next report contains by changing what goes into that build.
From the FedRAMP Consolidated Rules for 2026: Providers should evaluate vulnerabilities for logical groupings of affected resources, and FedRAMP’s detection and response rules then apply to each grouping rather than to each instance.
Start by scheduling base image rebases. Time them so the rebuilt images are in production before your monthly scan, so any fix in the updated base image shows in the next report. Under the grouping rule, a vulnerable package in a single base image can be treated as a single grouping, even if it appears in multiple containers.
Measure how many findings recur before you make the case for fixing them. Take your last three reports and count the findings that appear in all three. That roughly shows how much monthly work is carryover and gives whoever funds the work something to act on. Then tag recurring and new findings separately before triage, since new ones need fresh judgment and are easy to miss among familiar items.
When a component has no upstream fix, decide before the 192-day mark whether to replace it, patch the version you run, or accept the vulnerability.
Include transitive dependencies in your package inventory, because the packages you chose directly are only part of what ships.
The findings that keep coming back start in the build, and a change to the build is what remediates them.
Where SecureChain Fits in the Package Lifecycle
SecureChain is TuxCare’s product for the open source packages in your build. For the packages it covers, it rebuilds them from source in locked-down, isolated environments and inspects them for malware and suspicious code, stopping anything that fails from reaching your environment. Each package comes with SLSA Level 3 provenance attestation, SBOM, and VEX statement. Packages that are still maintained get monitored for new CVEs and patched under a service-level agreement. Once upstream maintainers stop, TuxCare backports critical and high-severity fixes to the exact versions you’re running. Coverage spans JavaScript, Python, Java, Go, and PHP.
If your monthly report keeps carrying components that upstream has stopped fixing, see what SecureChain covers.
FAQ
What Is ConMon in FedRAMP, and What Gets Reported Each Month?
In FedRAMP, the U.S. federal cloud authorization program, continuous monitoring (ConMon) covers a provider’s ongoing security reporting after its service is authorized. On the Revision 5 (Rev5) path, cloud service providers scan operating systems, web applications, and databases monthly and upload an updated plan of action and milestones (POA&M) and inventory, per the Continuous Monitoring Playbook (version 1.0).
Do Rev5 and 20x Providers Report Vulnerabilities the Same Way?
Under its Consolidated Rules for 2026, FedRAMP requires Revision 5 (Rev5) providers and 20x Class B and C providers to report vulnerability activity at least monthly and to mark any vulnerability not fully mitigated or remediated within 192 days of evaluation as accepted. Verification cadences differ by path and class. Rev5 Class C providers must verify and validate machine-based resources at least monthly, and 20x Class C providers must do so every 3 days.
What Is an Accepted Vulnerability in FedRAMP?
Under its 2026 rules, FedRAMP treats a vulnerability as accepted when the provider doesn’t intend to fully mitigate or remediate it. The label is also required once a vulnerability isn’t, or won’t be, fully mitigated or remediated within 192 days of evaluation. Providers must report why each is accepted, along with its internet reachability, likely exploitability, and estimated impact on the agency.
What Is a Deviation Request in FedRAMP?
In FedRAMP, a Revision 5 (Rev5) provider can file a deviation request asking the agency to treat a finding as a false positive, a risk adjustment, or an operational requirement. The Continuous Monitoring Playbook states that agencies approve these requests and that assessors validate them during the annual assessment.
Do FedRAMP Scans Separate Open Source Packages From Other Software?
FedRAMP doesn’t sort findings by open source status in the Continuous Monitoring Playbook or the 2026 vulnerability rules. The Playbook ties findings to inventory assets and container images, and the 2026 detection rule lists supply chain monitoring as a technique. Tracing a finding’s origin takes your own analysis.
When Do FedRAMP’s 2026 Vulnerability Rules Take Effect?
FedRAMP opened optional adoption of its 2026 vulnerability rules on July 4, 2026. New applicants must follow them from December 7, 2026. Existing providers should adopt by then and must by March 7, 2027, or FedRAMP will revoke certification.
