# FedRAMP’s new rules: closing the gap between finding and fixing > How recurring Apex scans, scoped pentesting, and fix reviews keep security testing moving as code changes and support FedRAMP vulnerability programs. Author: Cantina Published: October 6, 2026 Topics: FedRAMP, VDR, VER, Continuous testing, Fix Review Canonical URL: https://www.cantina.security/blog/fedramp-vdr-ver-vulnerability-verification FedRAMP’s new Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) rules raise the bar for how cloud providers find, investigate, and fix security issues. We think that shift is overdue. Continuous testing should give teams clear evidence of what an attacker could exploit and whether a proposed fix addresses it. We have seen why that matters in our own work. Across 3 months of customer fix reviews, we found [security issues in 62 of 193 fix pull requests](https://apex.cantina.security/blog/end-to-end-fix-review-workflows) that received a final verdict. Some left the original vulnerability in place while others introduced a new security problem. These results describe the customer patches we reviewed rather than an industry-wide failure rate, but they show why submitting a fix cannot be the end of the investigation. A team can detect a bug quickly and still leave customers exposed through an incomplete patch or an update that never reaches production. Closing that gap requires detection, investigation, remediation and verification to work together, with evidence from each step informing the next. ## What VDR and VER change FedRAMP has described the [legacy monthly scanning process as insufficient](https://www.fedramp.gov/notices/0014/). VDR covers finding and responding to vulnerabilities, while VER requires providers to [evaluate the risk in their own service](https://www.fedramp.gov/2026/providers/rev5/rules/vulnerability-evaluation-and-reporting/). That includes how an attacker could reach a bug over the internet, how likely the attack is to succeed and what harm it could cause agency customers. Reports must track the assessment and how that potential harm changes as the team acts. For Rev5 providers, [December 7, 2026 is the adoption date for both rulesets](https://www.fedramp.gov/2026/providers/updating/deadlines/rev5/). Existing providers that have not adopted them by then need a corrective action plan to maintain certification during the grace period, which ends on March 7, 2027. The practical question is how a provider supports its assessment when the code, configuration or protections change. A finding count alone cannot show which agency customers were exposed, what the team changed or why the remaining risk is lower. ## What continuous testing should mean Continuous testing means repeating the relevant checks as code changes and carrying the evidence from each finding into the next fix review. The cycle is practical: scan regularly, investigate findings, review proposed fixes, and test again as the application evolves. Scheduled scans provide regular coverage, while findings and code changes guide focused investigation and retesting. The provider carries those results into its broader vulnerability program, including deployment verification. Each type of check answers a different question: | Check | What it establishes | What still needs checking | | --- | --- | --- | | Recurring scans | Which possible vulnerabilities the tools detect in the resources they checked. | How each finding affects the service and what an attacker could do. | | Tests after a change | How new code, dependencies or configuration affect the behavior being tested. | Which other services or conditions the change could affect. | | Fix reviews | Whether the proposed code addresses the original bug without introducing related security problems or breaking supported behavior. | Whether that exact change reaches the affected service. | | Verification after deployment | Whether the intended change is running and the affected behavior passes the agreed checks in the deployed environment. | What remains outside those checks and what future changes should trigger another test. | The testing plan should name the systems covered, the changes that trigger another check and the evidence needed to complete it. Skipped resources, missing permissions and failed runs belong in the record because they leave unanswered questions. The required frequency varies by activity and certification class; teams should map their plan to the applicable [VDR timeframes](https://www.fedramp.gov/2026/providers/rev5/rules/vulnerability-detection-and-response/#timeframes). ![Continuous application testing cycle, from scheduled scans and investigation through fix review and deployment verification.](./fedramp-vdr-ver-vulnerability-verification/continuous-testing.png) ## Carry the evidence from the finding to the deployed fix Consider a document-sharing application. In an isolated test environment, two synthetic users each have sample files. A scoped test checks whether one user can read the other’s files, and code review follows the access checks behind that behavior. If the test demonstrates unauthorized access, the engineer has a concrete requirement for the fix: users must only be able to read documents they are allowed to access. The review should test that requirement across the affected routes and permissions, while checking that legitimate access still works. The finding records the code version, configuration, and conditions tested. The provider uses that evidence to determine whether the same conditions exist in its federal offering. After deploying the reviewed patch, its team confirms that the affected instances received it and validates the relevant behavior through a safe, approved test. While that work is underway, the team might restrict access to the affected feature. [VDR distinguishes reducing risk from removing the vulnerability](https://www.fedramp.gov/2026/providers/rev5/rules/vulnerability-detection-and-response/#vulnerability-response), so the record should explain what the temporary protection prevents and what remains unresolved. The original finding should stay linked to the investigation, engineering ticket, reviewed commit, deployed version and test results. Keeping those records together lets the team explain each change in risk and identify unfinished work without reconstructing the investigation from separate tools. The provider can then use that evidence to support the [history of evaluations and risk reductions required by VER](https://www.fedramp.gov/2026/providers/rev5/rules/vulnerability-evaluation-and-reporting/#vulnerability-details). ## Start with a defined application testing scope A scoped code review or an isolated application test gives engineers a concrete place to start an ongoing testing program. A test environment can use synthetic accounts and records to exercise the relevant application logic across releases. Agree on a regular testing cadence and which changes should prompt another check. The scope should identify the code and configuration being tested, the access required, and where code, prompts, findings, and test output will be processed. Choose that setup with the provider’s security team. Synthetic test data helps separate testing from live customer records; the suitability of the code, access, and processing arrangements still needs to be established for the engagement. The aim is useful evidence about the application that the provider can connect to its own assessment of production risk. ## How Apex supports this approach [Apex, Cantina’s autonomous OffSec agent](https://www.cantina.security/apex), brings code scanning, penetration testing, and fix review together. It investigates attack paths, reproduces suspected vulnerabilities where possible, and gives engineers evidence tied to the tested code and conditions. Its [Fix Review workflow](https://apex.cantina.security/blog/end-to-end-fix-review-workflows) checks proposed patches against the original finding, including alternate paths and related security problems. When evidence is missing, the review identifies what remains unresolved. ![Apex OpenClaw demo showing a denied file read followed by a changed argument that returned a synthetic test secret.](./fedramp-vdr-ver-vulnerability-verification/apex-test-evidence.png) *Apex’s [OpenClaw demo](https://apex.cantina.security/welcome) records the test evidence behind a confirmed finding: a direct file read was blocked, while a changed argument returned a secret used only for testing.* [Recurring scans and scheduled Fix Reviews](https://apex.cantina.security/docs/scheduled-scans) make that cycle repeatable. Scans look for new vulnerabilities within the configured scope, while scheduled Fix Review revisits eligible findings as patches land. Each new review checks the selected code against the original finding and records the result. That keeps the evidence tied to the version tested as development continues. That gives engineers a repeatable process for finding vulnerabilities and checking fixes, with evidence the provider can use in its broader [FedRAMP vulnerability program](https://www.cantina.security/solutions/fedramp). The provider connects those results to production exposure, confirms deployment, and assesses the impact on agency customers. Talk to Cantina about testing your application with Apex.