CVE Monitoring and Patch Development

Most newly published CVEs can roll into your next normal maintenance window. The few that can’t have to be caught the same day, before an attacker gets to them.

Rietta monitors our clients’ dependencies for published vulnerabilities daily via a combination of automated tooling, and open source intelligence (a fancy way of saying we subscribe to a lot of security announce mailing lists), and seasoned security knowledge.

This service is a foundation for maintaining the security of an application. One of our government clients said that he loves it when he gets an e-mail from us that we have deployed to production a fix for a problem and then the next day reads about the security risk in other media. He is able to communicate with his agency stakeholders that they have the problem under control and are prepared.

What This Solution Covers

CVE monitoring watches the open source and third-party software your application depends on for newly published vulnerabilities, and triages each one against your application. It is one part of our vulnerability management and remediation solutions:

• Making, testing, and deploying the fix happens under our application maintenance and remediation program.
• Keeping known-vulnerable dependencies from shipping in the first place is the job of secure CI/CD pipelines.

CVE Monitoring in Practice

Our security experts triage every flagged issue against your specific application. Some fixes need to ship that night, others can wait for a normal maintenance window, and we keep re-evaluating as new information comes in, because a CVE’s severity can change within hours.

On July 29, 2026, the Ruby on Rails project shipped a fix for a remote code execution flaw in ActiveStorage, tracked as CVE-2026-66066. During business hours it had no severity score assigned, and we triaged it as a regular update for the normal maintenance window. By evening our monitoring showed it had climbed to 9.5 out of 10, and we escalated it to a hotfix emergency. We ran each impacted application’s full automated test suite and had the patch in production for our clients that same night, without waiting for a technical writeup or an approval cycle.

The first exploit attempt against one of those clients, a State government application, arrived at 7:10 AM the next morning, eight hours and one minute after we deployed. Sustained probing followed throughout August. Every attempt failed at the exact point the patch was meant to stop it.

For the full timeline, see Government Rails Site Hit Hours After CVE Patch.

Automated and Expert Processes

• Inventory your software dependencies (or bill of materials)
• Automated monitoring for newly published CVEs that impact your software
• Evaluate upcoming issues prior to formal CVE based on open source intelligence
• Triage and remediate
  • Security expert examines all flagged CVEs and evaluates potential impact for your specific application
  • If an update is available and merited, we immediately produce and test a software update to fix the security issue
  • If the issue is lower risk, communicate that an update can be postponed
  • If no security patch is available for the risk, communicate potential options

Related Services

• Application maintenance and remediation of immediate high priority security issues
• Exception monitoring and triage for the errors that show up after a patch ships
• Automated test coverage for legacy applications, so a patch can be proven safe before it ships
• Dockerization
• Secure CI/CD pipelines with dependency and container scanning in GitHub or similar
• Ongoing monthly support and reporting