{“lastseen”:”2026-06-04T22:05:12″,”description”:”In the first article in this series, we made the case for a prevention-led operating model. This article is about what happened next: the decision to build something that did not exist, and what it took to make it real.\\n\\nTurning an operating model into a product sounds straightforward until you are standing in front of the actual problem. For us, it was this: every organization we spoke to was managing risk signals that lived in completely separate systems, each scored by a different tool, each using a different definition of what critical actually means. Network risk, identity risk, software risk, asset risk, cloud risk \u2014 all of it siloed, all of it speaking a different language. No single team had the full picture. No single platform had been built to create one.\\n\\nThat fragmentation was not a reporting inconvenience. It was the core structural problem underneath everything else. If you cannot see risk as a whole, you cannot prioritize it intelligently. And if you cannot prioritize intelligently, you are always reacting to whatever is shouting loudest rather than what actually matters most to the business. And in today\u2019s AI-driven vulnerability landscape, the ability to sift through the noise and remediate at speed is no longer a nice-to-have; it\u2019s business-critical. \\n\\nThe first product we built for the ROC was an enterprise risk management platform designed to change that: every risk signal in one place, evaluated consistently, and tied directly to business consequences.\\n\\n**_Fragmentation was not a reporting inconvenience. It was the core structural problem underneath everything else._**\\n\\n* * *\\n\\n**Find out how Qualys solutions prepare you for the post-Mythos era of risk.**\\n\\nFind Out More\\n\\n* * *\\n\\n## Why Aggregation Was Not Enough\\n\\nThe first challenge we hit was one that sounds technical but is fundamentally a governance problem. Bring findings from a dozen different tools into one place, and you quickly discover they are not speaking the same language. One vendor’s critical is another vendor’s high. A score that means confirmed, weaponized, and actively exploited in one tool means theoretical maximum impact in another. Placing those scores side by side and treating them as equivalent produces decisions that are no more reliable than the inconsistent inputs they came from.\\n\\nNormalization had to be foundational to the platform \u2014 not just aggregating findings but standardizing how they were evaluated so that an organization could compare risk across its entire environment on a level basis. Every score carries a lineage. Every comparison traces back to its source. That transparency was not a feature we added later. It was a requirement from the beginning, because boards will not act on a risk view they cannot explain, and they will not explain one they do not believe in.\\n\\n## Tying Risk to the Business\\n\\nOnce findings were normalized, the next challenge was making them meaningful to the people who needed to act on them. That meant tying risk back to the applications and business functions that generate real-world consequences. We worked with finance teams to assign business value to individual applications: if this system went down or was compromised, what would it cost? What revenue would be affected? What operations would stop?\\n\\nThat exercise changed the shape of every prioritization conversation we had. A vulnerability that seemed minor in isolation suddenly carried material weight when set against the business process it could disrupt. A misconfiguration that would have sat in a queue for weeks moved to the top of the list the moment its business context was visible.\\n\\n**_A vulnerability that seemed minor in isolation suddenly carried material weight when set against the business process it could disrupt._**\\n\\nThat exercise also revealed the scale of what we were dealing with. A single business application might depend on thousands of components: users, containers, microservices, networks, firewalls, third-party services, system accounts, each carrying its own risk signals. Stitching that picture together manually consumed entire teams and still produced an answer that was stale before it was delivered. The platform existed to do it continuously, automatically, and in a form that a board member could read without a translator.\\n\\n## Knowing Is Not Enough \u2014 You Have to Be Able to Fix It\\n\\nDetection and prioritization tell you what matters. They do not make you safe. The gap between knowing about a risk and actually closing it is where most security programs quietly lose ground, and it is the gap we were determined to close.\\n\\nQualys was among the first vulnerability management platforms to integrate patch deployment directly alongside detection. The reasoning was simple: if you find a vulnerability and then hand it off to a separate system, a separate team, and a separate workflow, you have introduced latency at exactly the point where speed matters most. Putting detection and remediation in the same platform, with the same data, removes that handoff. Fewer steps between knowing and fixing means a smaller window for an attacker to walk through.\\n\\nOver time, what started as patching evolved into something more complete. Patching is not always the answer the situation demands. A server that cannot come offline during business hours, an asset locked behind a change control window, infrastructure where a patch carries a real risk of breaking something in production \u2014 for all of these, a patch is the right long-term fix and the wrong short-term response. The platform grew to offer virtual patching, WAF rules, compensating controls, configuration changes, software removal, and asset isolation. Not workarounds. Deliberate remediation paths matched to the asset and the moment.\\n\\nToday, with the exploitation window at negative seven days median and Claude Mythos Preview capable of chaining vulnerabilities into working exploits within hours of disclosure, this capability is not a convenience feature. It is the difference between an organization that can respond at the speed of the threat and one that cannot. The 80 percent reduction in average time to remediate that customers see on the platform is not just a product of faster patching. It is the product of having the right remediation option available for every asset, every environment, every constraint.\\n\\nThe logical next step in that journey is knowing not just what to remediate but what actually needs remediating in your specific environment \u2014 which vulnerabilities are genuinely exploitable given the controls you have in place, and which are theoretical risk that no attacker is going to reach. That is the question TruConfirm and Agent Val were built to answer, and it is what the next article in this series is about.\\n\\n## Why This Cannot Wait\\n\\nOn April 7, 2026, Anthropic announced Claude Mythos Preview \u2014 a frontier AI model that autonomously discovers and exploits software vulnerabilities by chaining multiple CVEs within hours of disclosure. In initial private testing, it surfaced thousands of zero-days, including a 27-year-old OpenBSD flaw and a 17-year-old FreeBSD remote code execution. More than 99 percent remain unpatched. As of May 22, 2026, the model has found more than 23,000 vulnerabilities. Other frontier models will follow, CVE volume is expected to surge two to three times, and the exploitation window will compress further. The argument for a different operating model was already strong before this happened. Mythos made it urgent.\\n\\nAgentic systems do not execute instructions. They reason, plan, and act across multiple tools with enough autonomy that the line between software doing what it was told and software deciding what to do becomes genuinely hard to locate. The threat this introduces does not look like a traditional attack. You do not need to break the infrastructure. You need to shape how the agent interprets its objectives. A poisoned data source, a manipulated retrieval store, and the agent begins making adjustments that are individually plausible and collectively catastrophic \u2014 disabling a logging service, lowering a detection threshold, adjusting an access policy \u2014 before any human sees a reason to look.\\n\\n**_You do not need to break the infrastructure. You need to shape how the agent interprets its objectives._**\\n\\nAlert-driven security was built on the assumption that failure is visible, discrete, and reversible. Agentic failure is cumulative, distributed, and sometimes entirely internal to the reasoning of a system operating in good faith on corrupted inputs. Security teams are not behind because they lack capability or commitment. They are behind because they have been asked to govern fluid, autonomous environments using a model built for a simpler era.\\n\\n* * *\\n\\n**Sign up for a demo of Qualys Enterprise TruRisk Management to see how you can set up your own ROC for detection-speed remediation.**\\n\\nSign Up Now\\n\\n* * *\\n\\n_In the next article in this series, we look at how the ROC handles the question that sits underneath all of this: not just which vulnerabilities are dangerous in theory, but which ones are actually exploitable in your environment today._”,”published”:”2026-06-04T21:17:17″,”modified”:”2026-06-04T21:17:17″,”type”:”qualysblog”,”title”:”From Operating Model to Product: How We Built the ROC for Detection-Speed Remediation”,”source”:””,”references”:””,”id”:”QUALYSBLOG:04729DC1A0A66FE61A5E92D6718FDCAE”,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/blog.qualys.com\/category\/qualys-insights”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-06-04T22:05:12″,”description”:”In the first article in this series, we made the case for a prevention-led operating model. This article is about what happened next: the decision…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,13,33,120,7,11,5],"class_list":["post-59816","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-news","tag-none","tag-qualysblog","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n