SecLens 情报中心

{
  "authors": [
    "Justina Wu"
  ],
  "body_html": "<p dir=\"ltr\">Some security leaders manage programs. Amit Levy engineers them. </p><p dir=\"ltr\">Amit spent a significant part of his earlier career on offense, learning how attackers think, what they look for, and where the gaps defenders typically miss. That background is the lens through which he runs everything.</p>\n<article class=\"media media--type-image media--view-mode-media-embed-default [&amp;.align-center_img]:mx-auto [&amp;.align-left_img]:my-0 [&amp;.align-left_img]:mr-[2em] [&amp;.align-right_img]:my-0 [&amp;.align-right_img]:ml-[2em]\">\n<div class=\"field field--name-field-media-image field--type-image field--label-visually_hidden\">\n<div class=\"field__label visually-hidden\">Image</div>\n<div class=\"field__item\"> <img alt=\"Amit Levy Quote\" height=\"201\" loading=\"lazy\" sizes=\"(min-width: 1280px) 1200px, (min-width: 1024px) 904px, (min-width: 768px) 700px, (min-width: 640px) 600px, 100vw\" src=\"/sites/default/files/styles/max_1200x1200/public/2026-06/Amit-Levy-Quote.png.webp?itok=e81xtn8R\" srcset=\"/sites/default/files/styles/max_400x400/public/2026-06/Amit-Levy-Quote.png.webp?itok=W8l-Psv8 400w, /sites/default/files/styles/max_600x600/public/2026-06/Amit-Levy-Quote.png.webp?itok=HxySju1o 600w, /sites/default/files/styles/max_700x700/public/2026-06/Amit-Levy-Quote.png.webp?itok=MsS7FnnB 700w, /sites/default/files/styles/max_800x800/public/2026-06/Amit-Levy-Quote.png.webp?itok=m5SFIjmU 800w, /sites/default/files/styles/max_904x904/public/2026-06/Amit-Levy-Quote.png.webp?itok=3aQKmTuq 904w, /sites/default/files/styles/max_1200x1200/public/2026-06/Amit-Levy-Quote.png.webp?itok=e81xtn8R 1200w, /sites/default/files/styles/max_2400x2400/public/2026-06/Amit-Levy-Quote.png.webp?itok=Ft6E6q1x 1278w\" width=\"1200\"/>\n</div>\n</div>\n</article>\n<p dir=\"ltr\">When he evaluates a bug report, he's asking: if I were the one who found this, what would I do next? Where does this chain? What's the actual blast radius? It's an instinct that shapes his program structure, his researcher relationships, and the unusually precise way he measures whether his security posture is actually improving.</p><p dir=\"ltr\">Amit is HackerOne's Q2 2026 Champion of the Quarter, a recognition we give each quarter to an individual in the <a href=\"https://www.hackerone.com/lp/champion-program\">HackerOne Champion Program</a> who demonstrates measurable impact, shares their learnings, and moves the practice of security forward.</p><h2>The Metrics Nobody Else Is Tracking</h2><p dir=\"ltr\">One researcher finding five bugs in an hour is a fire alarm.</p><p dir=\"ltr\">This is how Amit thinks about program health. When asked how he defines a healthy bug bounty program, he didn't talk about finding count or bounty paid. He tracks researcher satisfaction, signal-to-noise ratio, and something most teams aren't measuring at all: researcher-hours spent against specific features.</p><p dir=\"ltr\">\"I know that for a specific feature, five researchers spent eight hours trying to break it,\" he said. \"If they didn't succeed, that's 40 hours of adversarial effort and the feature held. That means something.\"</p><p dir=\"ltr\">The goal isn't just to catch vulnerabilities, but to build genuine confidence that your platform has been seriously tested. </p><p dir=\"ltr\">\"I care about findings,\" Amit said, \"but I also care about the level of effort researchers are spending trying to break my platform.\"</p><p dir=\"ltr\">He also watches the time between a feature launch and the first relevant submission, working to minimize that window as a measure of researcher engagement and program responsiveness.</p><p dir=\"ltr\">Researcher return rates are a leading indicator too. A researcher who keeps coming back is being treated fairly, paid promptly, and given enough context to do good work.</p><h2>A Rare Win in Security: Engineering That Asks for Testing</h2><p dir=\"ltr\">\"Just this week, the R&amp;D department personally asked us to run a campaign for a new product launch,\" Amit told me. \"It didn't come from security, it came from R&amp;D themselves. They know it's a really good shield for them.\"</p><p dir=\"ltr\">Getting engineering to pull security testing rather than have it pushed on them is a cultural shift most teams spend years pursuing. Amit got there by making the program consistently deliver. And the way he did that was architectural.</p><p dir=\"ltr\">He embedded adversarial testing directly into monday.com's SDLC as the mandatory final security review step before any significant feature goes live. Every meaningful new feature now ends with a targeted Campaign, scoped specifically to that surface.</p><p dir=\"ltr\">\"Once we have a new feature, the last step of the security review is to launch a campaign,\" Amit said. \"And we know that if there's going to be something critical, it will come from there.\"</p><p dir=\"ltr\">The pattern he's observed holds consistently: skilled researchers who know the platform deeply find their way to new surfaces quickly. High and critical findings surface close to launch, before customers ever encounter them. Applied over years, that discipline created something rare: genuine engineering buy-in.</p><h2>Building the Automation Pipeline That Made It All Scale</h2><p dir=\"ltr\">Running a high-quality program with a small team used to require a significant ongoing time investment. Amit's solution was to automate as much of the remediation workflow as possible, and over the last year, that investment has fundamentally changed what his team can do.</p><p dir=\"ltr\">When a valid report comes in, HackerOne's Triage team handles first-pass validation and researcher communication. From there, a combination of <a href=\"https://www.hackerone.com/platform/hai\">HackerOne’s agentic AI system, Hai</a>, and monday.com's own internal agents performs root cause analysis, identifies the issue in the codebase, suggests a fix, creates a PR, and opens a ticket for the responsible developer, complete with full context and a defined SLA. After the fix ships, an AI-assisted retest confirms resolution before the bounty is released.</p><p dir=\"ltr\">\"AI is doing the work, and we are just reviewing and approving it,\" he said. \"We managed to reduce the effort required to validate a report by 70-80%.\" </p><p dir=\"ltr\">That efficiency changed the program's economics entirely. With less overhead per report, Amit has been able to expand researcher invitations and run more targeted campaigns, all without adding headcount.</p><p dir=\"ltr\">There's a second benefit he's quick to point out: fast fixes prevent duplicate reports. </p><p dir=\"ltr\">\"If you're fixing it in real time, you avoid duplication,\" he said. \"You're fixing the vulnerability, that's first. And second, you're cutting noise.\" Less noise means better signal. Better signal means the team focuses on what matters.</p><p dir=\"ltr\">When other security leaders tell him a bug bounty program sounds like too much work, he doesn't argue with them. He just tells them what he built: \"I've automated almost all the process. Now it's a piece of cake. It's a shame not to use it.\"</p><p dir=\"ltr\">When monday.com became an AI platform, Amit treated it the same way he treats every new surface: find the researchers who can break it before anyone else does. For AI-specific vulnerabilities, that community is still the most reliable detection method available. </p><p dir=\"ltr\">A high-performing bug bounty program needs someone who owns it obsessively. For monday.com, that's Avihai Fedida, the operational engine behind the vision.</p><p dir=\"ltr\">\"Avihai Fedida is the person who takes my ideas and turns them into a real, working machine. As our HackerOne operational program manager, he's the one who makes sure everything actually runs: the metrics, the standards, the automations.”</p><p dir=\"ltr\">\n<div class=\"node node--type-cta-card node--view-mode-wysiwyg-card wysiwyg-cta-card not-prose flex flex-col\">\n<a class=\"wysiwyg-cta-card-link no-underline flex flex-col md:flex-row-reverse grow bg-white group-[.dark-bg]/c:bg-gradient-to-b group-[.dark-bg]/c:from-[#30344B] group-[.dark-bg]/c:to-blue-black-100 border rounded overflow-hidden border-blue-black-20 group-[.dark-bg]/c:border-blue-black-80 hover:bg-gradient-to-b hover:from-white hover:to-blue-black-5 group-[.dark-bg]/c:hover:brightness-125\" href=\"https://www.hackerone.com/resources/i/1519631-hai-solution-brief/0?\">\n<div class=\"wysiwyg-cta-card-media mx-1 mt-1 md:mx-0 md:mt-0 rounded md:rounded-none border md:border-none border-blue-black-80 overflow-hidden md:shrink-0 md:[&amp;_.media--type-image]:h-full [&amp;_.field--type-image]:relative [&amp;_.field--type-image]:w-full md:[&amp;_.field--type-image]:w-50 [&amp;_.field--type-image]:h-56 md:[&amp;_.field--type-image]:h-full md:[&amp;_.field--type-image]:min-h-[158px] [&amp;_.field--type-image_img]:absolute [&amp;_.field--type-image_img]:w-full [&amp;_.field--type-image_img]:h-full [&amp;_.field--type-image_img]:object-cover\">\n<div class=\"wysiwyg-cta-card-image md:h-full field field--name-field-cta-card-image field--type-entity-reference field--label-hidden field__item\">\n<article class=\"media media--type-image media--view-mode-cta-card-image [&amp;.align-center_img]:mx-auto [&amp;.align-left_img]:my-0 [&amp;.align-left_img]:mr-[2em] [&amp;.align-right_img]:my-0 [&amp;.align-right_img]:ml-[2em]\">\n<div class=\"field field--name-field-media-image field--type-image field--label-visually_hidden\">\n<div class=\"field__label visually-hidden\">Image</div>\n<div class=\"field__item\"> <img alt=\"Hai\" height=\"500\" loading=\"lazy\" sizes=\"(min-width: 1280px) 450px, (min-width: 1024px) 400px, (min-width: 768px) 94vw, (min-width: 640px) 94vw, 100vw\" src=\"/sites/default/files/styles/max_500x500/public/2025-05/Hai-orb-with-logo.png.webp?itok=tv8yLJzA\" srcset=\"/sites/default/files/styles/max_325x325/public/2025-05/Hai-orb-with-logo.png.webp?itok=Id0CIsP5 325w, /sites/default/files/styles/max_400x400/public/2025-05/Hai-orb-with-logo.png.webp?itok=abFvFJeL 400w, /sites/default/files/styles/max_650x650/public/2025-05/Hai-orb-with-logo.png.webp?itok=LHHtn-Sl 650w, /sites/default/files/styles/max_800x800/public/2025-05/Hai-orb-with-logo.png.webp?itok=uF8k4xxD 800w, /sites/default/files/styles/max_904x904/public/2025-05/Hai-orb-with-logo.png.webp?itok=3w9OZuCR 904w, /sites/default/files/styles/max_1000x1000/public/2025-05/Hai-orb-with-logo.png.webp?itok=2FsaMZo3 1000w, /sites/default/files/styles/max_1200x1200/public/2025-05/Hai-orb-with-logo.png.webp?itok=TEcCPSdd 1200w\" width=\"500\">\n</img></div>\n</div>\n</article>\n</div>\n</div>\n<div class=\"wysiwyg-cta-card-content p-8 flex flex-col grow gap-2 justify-center\">\n<div class=\"wysiwyg-cta-card-headline h4 group-[.dark-bg]/c:text-white field field--name-field-cta-card-headline field--type-string field--label-hidden field__item\">Hai Solution Brief</div>\n<div class=\"wysiwyg-cta-card-link-text flex flex-row items-center gap-1 text-sm font-medium leading-140 text-blue-black-100 after:content-icon-cta-secondary after:block after:leading-none after:w-3 after:h-3 group-[.dark-bg]/c:text-white\">\n          Download the Brief\n        </div>\n</div>\n</a>\n</div>\n</p><h3 dir=\"ltr\">Why Amit Is Champion of the Quarter</h3><p dir=\"ltr\">Amit built something that most security teams aspire to: a program that finds the most critical vulnerabilities, runs with minimal overhead, earns genuine buy-in from engineering, and keeps getting better as the threat landscape shifts.</p><p dir=\"ltr\">He did it with a small team, on a complex platform, over years,  through a combination of attacker instincts, operational discipline, and a genuine belief that the researchers testing your systems are partners worth investing in.</p><p dir=\"ltr\">That's what the HackerOne Champion Program is here to recognize. Security leaders who do exceptional work and help the rest of the industry do the same.</p><p dir=\"ltr\"><a class=\"cta-primary-wysiwyg\" href=\"https://www.hackerone.com/lp/champion-program\">Join the HackerOne Champion Program</a></p>",
  "detail_summary": "Some security leaders manage programs. Amit Levy engineers them. Amit spent a significant part of his earlier career on offense, learning how attackers think, what they look for, and where the gaps defenders typically miss. That background is the lens through which he runs everything. Image When he evaluates a bug report, he's asking: if I were the one who found this, what would I do next? Where does this chain? What's the actual blast radius? It's an instinct that shapes his program structure, his researcher relationships, and the unusually precise way he measures whether his security posture is",
  "hero_image": "https://www.hackerone.com/sites/default/files/styles/og_image/public/2026-06/Champion-Q2.png.jpg?itok=bajsHly0",
  "listing_image": "https://www.hackerone.com/sites/default/files/styles/max_500x500/public/2026-06/Champion-Q2.png.webp?itok=DaJVx6EY",
  "listing_solutions": [],
  "listing_topics": [
    "Exposure Management"
  ],
  "modified_time": null,
  "taxonomy": {
    "blog_topic": [
      "Exposure Management"
    ]
  }
}

{
  "authors": [
    "Ilona Cohen"
  ],
  "body_html": "<p dir=\"ltr\">The Administration released an Executive Order today addressing cybersecurity in the age of frontier AI. It's not a comprehensive regulatory framework, but a targeted set of directives drawing on many existing authorities. HackerOne has been engaged in those policy conversations, including meetings last month with the Office of the National Cyber Director and the federal government's CISO. Here's our read on what's in the Executive Order and what to watch over the next 60 days.</p><h2>Discovery is No Longer the Problem</h2><p dir=\"ltr\">For years, a primary challenge in cybersecurity was improving vulnerability discovery. Frontier AI models are now identifying vulnerabilities at a speed and scale that outpaces organizations' ability to respond. H1 Platform data shows vulnerability submissions up 92% year over year, with critical and high-severity findings climbing while remediation throughput lags by a wide margin. The constraint isn't finding vulnerabilities anymore. It's everything that comes next: validating findings, prioritizing real-world risk, coordinating disclosure, and remediating before adversaries act.</p><p dir=\"ltr\">That shift is reflected throughout this order.</p><h2>What's In the Executive Order</h2><h4>Upgrading Federal Cybersecurity</h4><p dir=\"ltr\">Within 30 days, agencies will issue directives to prioritize AI-enabled defense of federal civilian systems and extend access to AI-based defense tools to critical infrastructure, including rural hospitals, community banks, and local utilities. </p><p dir=\"ltr\">Key provisions:</p><ul><li aria-level=\"1\" data-list-item-id=\"ee5affdab7e51a2580497ee2e3bcdadd6\" dir=\"ltr\">Treasury, NSA, and CISA will establish a voluntary AI cybersecurity clearinghouse with industry to coordinate vulnerability discovery, remediation, and patch distribution</li><li aria-level=\"1\" data-list-item-id=\"e95d6c51fc094f18e9f3a8604541a7549\" dir=\"ltr\">Federal budget officials will identify grant funding for advanced AI vulnerability detection</li><li aria-level=\"1\" data-list-item-id=\"ef903e4284c8e43e0aa108697d7f1bb9c\" dir=\"ltr\">The government will expand cybersecurity hiring through its U.S. Tech Force initiative</li></ul><h4>Vulnerability Clearinghouse</h4><p dir=\"ltr\">Vulnerabilities in advanced AI systems don’t stay contained. They run through every product and service built on top of the model that carries them. The clearinghouse, led by Treasury in coordination with NSA and CISA, appears designed to address that: scanning for software vulnerabilities across federal agencies and critical infrastructure operators, coordinating mitigations, and pushing patch distribution at scale. It mirrors the AI Action Plan’s recommendation to establish an AI Information Sharing and Analysis Center. Together, they suggest the Administration is trying to build a durable coordination architecture for AI-related cyber risk - not just a one-time disclosure program.</p><h4>Covered Frontier Models</h4><p dir=\"ltr\">Federal security and AI policy officials will establish a classified benchmarking process to designate certain advanced AI models as \"covered frontier models.\" Developers of covered models would participate in a voluntary framework providing 30 days of government pre-public access before releasing the models to other trusted partners. The designation authority sits with the NSA, and the benchmarking methodology is classified, meaning frontier AI cyber capabilities are seen as a national security issue, not a technology or governance one. </p><h4>Criminal Enforcement</h4><p dir=\"ltr\">The order prioritizes federal criminal enforcement against those who illegally use AI to access or damage computer systems, directing the Attorney General to prioritize enforcement of the Computer Fraud and Abuse Act. HackerOne has long advocated for protecting good-faith security researchers from legal risk. Whether enforcement guidance includes clear safe harbors for legitimate research will matter.</p><h2>What to Watch During Implementation</h2><p dir=\"ltr\">The 30- and 60-day timelines are tight. Three things stand out.</p><p dir=\"ltr\">The clearinghouse needs legal cover to function. Participation depends on legal protections for shared information comparable to those the <a href=\"https://www.hackerone.com/blog/reauthorize-cisa-2015-ai-action-plan\">Cybersecurity Information Sharing Act of 2015</a> provides for traditional threat sharing. Extending those protections to AI vulnerability data needs to be an early implementation priority.</p><p dir=\"ltr\">Coordinated disclosure is becoming national infrastructure. Vulnerability disclosure programs are no longer optional best practices. They are operational infrastructure. The clearinghouse model requires trusted channels connecting government, AI developers, critical infrastructure operators, and the security research community.</p><p dir=\"ltr\">Remediation, not discovery, is the critical control point. The order’s emphasis on patch distribution and AI-enabled security tooling signals that policymakers are catching up to where the threat landscape already is. Federal agencies and critical infrastructure operators need systems that can validate findings and route remediation, not just receive reports. Grant funding aimed at building those capabilities is where implementation can have the most direct impact.</p><h2>HackerOne's Approach</h2><p dir=\"ltr\">HackerOne has been making the same arguments for years:</p><ul><li aria-level=\"1\" data-list-item-id=\"e74027511a975097e0069af45aa03ad9b\" dir=\"ltr\">Voluntary, collaborative frameworks between government and industry work</li><li aria-level=\"1\" data-list-item-id=\"e8289ccdd2157ee9a3ec7e5b9ae35550f\" dir=\"ltr\">Scaling vulnerability disclosure and remediation requires resources, incentives, and accountability, including requiring vulnerability disclosure programs for federal contractors</li><li aria-level=\"1\" data-list-item-id=\"e83b137a2dc4af41ee27a9d49c9ba0f4d\" dir=\"ltr\">The private sector must be a genuine partner in defending critical infrastructure, not an afterthought</li></ul><p dir=\"ltr\">Success in cybersecurity is no longer measured by how many vulnerabilities organizations can find. Resilience depends on how quickly findings can be validated, how accurately exploitability can be assessed, and how efficiently remediation happens. That shift has driven HackerOne to deploy new validation capabilities that combine AI-assisted analysis with human expertise to help organizations prioritize what actually needs to be fixed.</p><p dir=\"ltr\">This order reflects that policymakers are beginning to recognize the same shift the security industry is already navigating. Next comes the real challenge: implementation.</p><p dir=\"ltr\"><a class=\"cta-secondary-wysiwyg\" href=\"https://www.hackerone.com/blog/public-policy\">Follow the HackerOne policy blog for expert insights and updates that matter to security leaders</a></p><p dir=\"ltr\"> </p><p dir=\"ltr\"><em><sup>The content on this page is for informational purposes only and not for the purpose of providing legal advice. The applicability of any of the information provided will vary based on your or your organization’s circumstances.</sup></em></p>",
  "hero_image": "https://www.hackerone.com/sites/default/files/styles/og_image/public/2026-06/What-You-Need-to-Know-About-the-New-AI-Executive-Order-Banner.png.jpg?itok=m7Z8hgwB",
  "listing_image": "https://www.hackerone.com/sites/default/files/styles/max_500x500/public/2026-06/What-You-Need-to-Know-About-the-New-AI-Executive-Order-Banner.png.webp?itok=6hz3md30",
  "listing_solutions": [],
  "listing_topics": [
    "AI",
    "Public Policy"
  ],
  "modified_time": null,
  "taxonomy": {
    "blog_topic": [
      "AI",
      "Public Policy"
    ],
    "region": [
      "North America"
    ]
  }
}

{
  "authors": [
    "Tony Lee"
  ],
  "body_html": "<p>The security landscape shifted in a meaningful way earlier this year. With the release of more advanced AI models and tools in February, the entire industry began seeing a significant (100%+) surge in report volume. It's a moment that has challenged us, pushed us to innovate, and ultimately reinforced the work we do together with security researchers and customers.</p><p>We're grateful for the opportunity to share where we've been, what we've learned, and where we're headed.</p><h2>A New Kind of Volume</h2><p>Historically, an increase in report volume was a signal worth celebrating. More reports meant more researchers engaged, more vulnerabilities found, and more programs protected. That dynamic hasn't disappeared, but it has become more nuanced.</p><p>Not all AI-assisted volume is created equal. Some of it is genuinely valuable: novel findings, well-documented reports, and real security impact. But some of it includes duplicates, unverifiable submissions, or reports that lack the depth needed to act on them. This means we have to be more intentional than ever about prioritizing quality over quantity, while being careful not to throw out the signal along with the noise.</p><p>We've resisted the temptation to make a sharp, reactive change. Instead, we've leaned on our data, listened closely to the community, and consulted with long-standing customers to take a measured, balanced approach, one that keeps the right reports flowing to the right programs at the right time.</p><h2>Our Commitment to the Security Researcher Community</h2><p>We genuinely believe in the power of AI to make security researchers more efficient and effective. We use these tools ourselves. But with that efficiency comes responsibility, and we think that's a healthy tension.</p><p>After carefully analyzing the volume trends, we updated the <a href=\"https://www.hackerone.com/policies/code-of-conduct\" target=\"_blank\">HackerOne Code of Conduct</a> to reflect the realities of AI-assisted research. The core expectation remains the same as it always has been: high-quality, valid reports with clear steps to reproduce and demonstrated impact. What we've clarified is that researchers are responsible for the quality of what they submit, regardless of whether a human or a tool generated the first draft.</p><p>We've also built detection and enforcement mechanisms to back this up. We are fortunate to work with such a thoughtful, skilled community and the response has been overwhelmingly positive. Many researchers simply weren't aware of the downstream impact their submissions were having on program teams. Once they understood, they adjusted. That kind of responsiveness reflects the community we've all built together.</p><h2>Supporting Our Customers</h2><p>The impact of AI-driven volume hasn't been uniform across programs. Public programs have felt it more acutely than private ones, because they're open to anyone, including those simply operating tooling. Programs with open-source repositories in scope have seen even higher submission rates, in part because AI code-scanning tools are being run against the same repositories by multiple researchers, leading to higher duplication rates.</p><p>Our approach with customers has been grounded in transparency and collaboration. We are working with them to help them understand the root causes of increased volume and, in many cases, have been able to optimize their program to meaningfully improve the signal-to-noise ratio. This comes at no cost because it uses existing features already available within the HackerOne platform and by ensuring appropriate program scope. We're already seeing those improvements working, and we're proud of the partnership it's taken to get there.</p><h2>Investing in Process and Product</h2><p>Challenges like this are catalysts for innovation, and we're grateful for the push.</p><p>As we grew in 2025, we invested heavily in scaling triage, including developing TriageOne Smart Routing, which is a system designed to route reports to the right analyst based on skillset, severity, and researcher signal. The historical data we've accumulated is a real advantage here: it helps us distinguish and prioritize a highly experienced, trusted researcher from a newly created account backed solely by automated tooling. We are also using this data to identify new and promising researchers who we can work with to grow their skills and their access to programs that can benefit from their skillset. The volume surge in February accelerated our TriageOne adoption to all standard triage operations and we're seeing meaningful improvements in our ability to surface the signal above the noise.</p><p>We also accelerated the development of <a href=\"https://www.hackerone.com/platform/hai\">our core agentic system, Hai</a>, and the specialized agents that support it, including agents for deduplication, priority escalation, insight generation, and report assistance. These agents are helping customers and our team work smarter: in some cases, what once required nine manual steps now takes one. That's not about replacing our people—it's about freeing them to focus on the judgment calls that only humans can make.</p><h2>Looking Ahead</h2><p>We won't pretend the surge in AI-driven volume hasn't created real short-term challenges. It has. But we also believe it has made us better, more efficient, more intentional, and better prepared for what's coming. AI-driven volume isn't going away. The tools will keep improving, and so will we because we embrace them.</p><p>We're deeply grateful to the researchers who've embraced this feedback and continue to bring their expertise and integrity to every submission. We're grateful to the customers who've trusted us to navigate this with them. And we're energized by what it means to build the future of security research, together.</p><p>Let’s continue to work together to overcome this challenge making the platform and the community stronger.</p>",
  "hero_image": "https://www.hackerone.com/sites/default/files/styles/og_image/public/2026-05/Blog-Header-Keep-Pace-With-Your-Changing-Attack-Surface.png.jpg?itok=nneFGdBT",
  "listing_image": "https://www.hackerone.com/sites/default/files/styles/max_500x500/public/2026-05/Blog-Header-Keep-Pace-With-Your-Changing-Attack-Surface.png.webp?itok=j6wRSglf",
  "listing_solutions": [],
  "listing_topics": [
    "AI",
    "HackerOne News"
  ],
  "modified_time": null,
  "taxonomy": {
    "blog_topic": [
      "AI",
      "HackerOne News"
    ]
  }
}

{
  "authors": [
    "Nidhi Aggarwal",
    "Sandeep Singh"
  ],
  "body_html": "<p dir=\"ltr\">Two weeks ago, we published<a href=\"https://www.hackerone.com/blog/ai-vulnerability-discovery-remediation-gap\" target=\"_blank\"> Finding Fast, Fixing Slow: The Crisis of Asymmetric Remediation</a>, where we highlighted that AI-accelerated vulnerability discovery exacerbates the asymmetry between finding vulnerabilities and remediating them.</p><p dir=\"ltr\">We went back and analyzed HackerOne platform data to determine if this trend is already appearing across our programs. </p><p>We looked at remediation performance on the HackerOne platform for the twelve months ending March 2026. The analysis covered all vulnerability reports submitted on the platform, with a specific focus on critical-severity findings.</p><h2>AI-Driven Acceleration in Submission Volume</h2><p dir=\"ltr\">Total submissions across the platform grew by approximately 76% during the year, with a sharp increase in early 2026. Critical-severity submissions increased at similar rates, reaching a peak in March 2026. The timing lines up with AI-assisted discovery tools becoming more accessible to the security researcher community, something we noted in the original post.</p><p dir=\"ltr\">Signal rates stayed relatively consistent throughout this period. This stability indicates that the increase in volume represents a mix of valid and invalid vulnerabilities rather than an influx of AI-generated noise reports.</p>\n<article class=\"media media--type-image media--view-mode-media-embed-default [&amp;.align-center_img]:mx-auto [&amp;.align-left_img]:my-0 [&amp;.align-left_img]:mr-[2em] [&amp;.align-right_img]:my-0 [&amp;.align-right_img]:ml-[2em]\">\n<div class=\"field field--name-field-media-image field--type-image field--label-visually_hidden\">\n<div class=\"field__label visually-hidden\">Image</div>\n<div class=\"field__item\"> <img alt=\"Total Volume Increase and Critical Volume Increase\" height=\"676\" loading=\"lazy\" sizes=\"(min-width: 1280px) 1200px, (min-width: 1024px) 904px, (min-width: 768px) 700px, (min-width: 640px) 600px, 100vw\" src=\"/sites/default/files/styles/max_1200x1200/public/2026-05/Total-Volume-Increase-and-Critical-Volume-Increase.png.webp?itok=YMj5tcyK\" srcset=\"/sites/default/files/styles/max_400x400/public/2026-05/Total-Volume-Increase-and-Critical-Volume-Increase.png.webp?itok=VknrjHaS 400w, /sites/default/files/styles/max_600x600/public/2026-05/Total-Volume-Increase-and-Critical-Volume-Increase.png.webp?itok=JaK8BVVg 600w, /sites/default/files/styles/max_700x700/public/2026-05/Total-Volume-Increase-and-Critical-Volume-Increase.png.webp?itok=lzkr0VA3 700w, /sites/default/files/styles/max_800x800/public/2026-05/Total-Volume-Increase-and-Critical-Volume-Increase.png.webp?itok=wwgFctyG 800w, /sites/default/files/styles/max_904x904/public/2026-05/Total-Volume-Increase-and-Critical-Volume-Increase.png.webp?itok=9_hDxCpb 904w, /sites/default/files/styles/max_1200x1200/public/2026-05/Total-Volume-Increase-and-Critical-Volume-Increase.png.webp?itok=YMj5tcyK 1200w, /sites/default/files/styles/max_2400x2400/public/2026-05/Total-Volume-Increase-and-Critical-Volume-Increase.png.webp?itok=pkNo33vE 1278w\" width=\"1200\"/>\n</div>\n</div>\n</article>\n<h2 dir=\"ltr\">The Remediation Metrics That Surprised Us</h2><p dir=\"ltr\">Over the twelve-month period, mean time to remediate (MTTR) across the platform dropped by about 80%, and median MTTR fell by over 70%. Organizations can resolve faster than ever.</p><p dir=\"ltr\">But here's what caught us off guard. The total number of vulnerabilities resolved each month fell by about  46% over the same period, even as overall submissions grew by 76%. The cumulative backlog of validated but unresolved vulnerabilities grew by more than 21x.</p><p dir=\"ltr\">We can resolve faster. We just didn't resolve more. Somewhere along the way, we took our eye off the ball. Teams got faster at closing individual issues, but the overall effort going to remediation seem to shrink. The result is a backlog of vulnerabilities that is growing quietly in the background.</p>\n<article class=\"media media--type-image media--view-mode-media-embed-default [&amp;.align-center_img]:mx-auto [&amp;.align-left_img]:my-0 [&amp;.align-left_img]:mr-[2em] [&amp;.align-right_img]:my-0 [&amp;.align-right_img]:ml-[2em]\">\n<div class=\"field field--name-field-media-image field--type-image field--label-visually_hidden\">\n<div class=\"field__label visually-hidden\">Image</div>\n<div class=\"field__item\"> <img alt=\"Median MTTR Reduction\" height=\"676\" loading=\"lazy\" sizes=\"(min-width: 1280px) 1200px, (min-width: 1024px) 904px, (min-width: 768px) 700px, (min-width: 640px) 600px, 100vw\" src=\"/sites/default/files/styles/max_1200x1200/public/2026-05/Median-MTTR-Reduction.png.webp?itok=1GgHSpXA\" srcset=\"/sites/default/files/styles/max_400x400/public/2026-05/Median-MTTR-Reduction.png.webp?itok=TwzStn9R 400w, /sites/default/files/styles/max_600x600/public/2026-05/Median-MTTR-Reduction.png.webp?itok=GBz-uxJb 600w, /sites/default/files/styles/max_700x700/public/2026-05/Median-MTTR-Reduction.png.webp?itok=qlL4UGZP 700w, /sites/default/files/styles/max_800x800/public/2026-05/Median-MTTR-Reduction.png.webp?itok=D9mbknhk 800w, /sites/default/files/styles/max_904x904/public/2026-05/Median-MTTR-Reduction.png.webp?itok=kocq_eJq 904w, /sites/default/files/styles/max_1200x1200/public/2026-05/Median-MTTR-Reduction.png.webp?itok=1GgHSpXA 1200w, /sites/default/files/styles/max_2400x2400/public/2026-05/Median-MTTR-Reduction.png.webp?itok=a6RocRgi 1278w\" width=\"1200\"/>\n</div>\n</div>\n</article>\n<article class=\"media media--type-image media--view-mode-media-embed-default [&amp;.align-center_img]:mx-auto [&amp;.align-left_img]:my-0 [&amp;.align-left_img]:mr-[2em] [&amp;.align-right_img]:my-0 [&amp;.align-right_img]:ml-[2em]\">\n<div class=\"field field--name-field-media-image field--type-image field--label-visually_hidden\">\n<div class=\"field__label visually-hidden\">Image</div>\n<div class=\"field__item\"> <img alt=\"Total and Critical Resolved Trends\" height=\"676\" loading=\"lazy\" sizes=\"(min-width: 1280px) 1200px, (min-width: 1024px) 904px, (min-width: 768px) 700px, (min-width: 640px) 600px, 100vw\" src=\"/sites/default/files/styles/max_1200x1200/public/2026-05/Total-and-Critical-Resolved-Trends.png.webp?itok=on0ZuDCJ\" srcset=\"/sites/default/files/styles/max_400x400/public/2026-05/Total-and-Critical-Resolved-Trends.png.webp?itok=Anfi2FJ9 400w, /sites/default/files/styles/max_600x600/public/2026-05/Total-and-Critical-Resolved-Trends.png.webp?itok=Qq2EtRLU 600w, /sites/default/files/styles/max_700x700/public/2026-05/Total-and-Critical-Resolved-Trends.png.webp?itok=MSMBGrBD 700w, /sites/default/files/styles/max_800x800/public/2026-05/Total-and-Critical-Resolved-Trends.png.webp?itok=b086bVME 800w, /sites/default/files/styles/max_904x904/public/2026-05/Total-and-Critical-Resolved-Trends.png.webp?itok=P1yQqz67 904w, /sites/default/files/styles/max_1200x1200/public/2026-05/Total-and-Critical-Resolved-Trends.png.webp?itok=on0ZuDCJ 1200w, /sites/default/files/styles/max_2400x2400/public/2026-05/Total-and-Critical-Resolved-Trends.png.webp?itok=Xz7sKYz_ 1278w\" width=\"1200\"/>\n</div>\n</div>\n</article>\n<h2 dir=\"ltr\">Exposure Debt is Rising, and We Let It </h2><p dir=\"ltr\">The cumulative backlog is an important risk indicator in security reporting. The compounding volume of unresolved findings is what shows the debt an organization carries.</p><p dir=\"ltr\">Unresolved vulnerabilities grew 21x. Unresolved criticals grew 25x. That pattern typically increases the risk of breaches, because it shows discovery velocity outpacing remediation capacity. Organizations are no longer addressing vulnerabilities in a sustainable way, and that creates a widening window for adversaries who can use the same powerful AI discovery tools to find these unpatched surfaces. When you put this alongside the contracting <a href=\"https://zerodayclock.com/\" target=\"_blank\">time-to-exploit</a> window, it tells you that threat actors can now weaponize new findings faster than internal teams are processing them.</p>\n<article class=\"media media--type-image media--view-mode-media-embed-default [&amp;.align-center_img]:mx-auto [&amp;.align-left_img]:my-0 [&amp;.align-left_img]:mr-[2em] [&amp;.align-right_img]:my-0 [&amp;.align-right_img]:ml-[2em]\">\n<div class=\"field field--name-field-media-image field--type-image field--label-visually_hidden\">\n<div class=\"field__label visually-hidden\">Image</div>\n<div class=\"field__item\"> <img alt=\"Exposure Backlog Over Time (All Severities)\" height=\"676\" loading=\"lazy\" sizes=\"(min-width: 1280px) 1200px, (min-width: 1024px) 904px, (min-width: 768px) 700px, (min-width: 640px) 600px, 100vw\" src=\"/sites/default/files/styles/max_1200x1200/public/2026-05/Exposure-Backlog-Over-Time-%28All-Severities%29.png.webp?itok=60YEaYok\" srcset=\"/sites/default/files/styles/max_400x400/public/2026-05/Exposure-Backlog-Over-Time-%28All-Severities%29.png.webp?itok=GJyJnNpZ 400w, /sites/default/files/styles/max_600x600/public/2026-05/Exposure-Backlog-Over-Time-%28All-Severities%29.png.webp?itok=M_NXaxTE 600w, /sites/default/files/styles/max_700x700/public/2026-05/Exposure-Backlog-Over-Time-%28All-Severities%29.png.webp?itok=bJnaQno9 700w, /sites/default/files/styles/max_800x800/public/2026-05/Exposure-Backlog-Over-Time-%28All-Severities%29.png.webp?itok=DUK2YSlT 800w, /sites/default/files/styles/max_904x904/public/2026-05/Exposure-Backlog-Over-Time-%28All-Severities%29.png.webp?itok=et3FITqd 904w, /sites/default/files/styles/max_1200x1200/public/2026-05/Exposure-Backlog-Over-Time-%28All-Severities%29.png.webp?itok=60YEaYok 1200w, /sites/default/files/styles/max_2400x2400/public/2026-05/Exposure-Backlog-Over-Time-%28All-Severities%29.png.webp?itok=yIb0vzST 1278w\" width=\"1200\"/>\n</div>\n</div>\n</article>\n<h2 dir=\"ltr\">Critical-Severity Vulnerabilities Aren’t Escaping This Trend</h2><p dir=\"ltr\">We might assume that even if the overall numbers are slipping, organizations might be prioritizing criticals. The data shows they're not. The same pattern holds.</p><p dir=\"ltr\">MTTR for critical findings improved by about 73%, but that efficiency only applied to a small subset of total volume. The actual remediation throughput has been dropping significantly. The resolution rate for critical issues fell from over 83% to under 40%. This gap between discovery and resolution caused the backlog of unresolved critical vulnerabilities to grow by about 25x. This trend demonstrates that current remediation capacity is not keeping up with the influx of critical-risk findings.</p>\n<article class=\"media media--type-image media--view-mode-media-embed-default [&amp;.align-center_img]:mx-auto [&amp;.align-left_img]:my-0 [&amp;.align-left_img]:mr-[2em] [&amp;.align-right_img]:my-0 [&amp;.align-right_img]:ml-[2em]\">\n<div class=\"field field--name-field-media-image field--type-image field--label-visually_hidden\">\n<div class=\"field__label visually-hidden\">Image</div>\n<div class=\"field__item\"> <img alt=\"Exposure Backlog Over Time (Criticals)\" height=\"676\" loading=\"lazy\" sizes=\"(min-width: 1280px) 1200px, (min-width: 1024px) 904px, (min-width: 768px) 700px, (min-width: 640px) 600px, 100vw\" src=\"/sites/default/files/styles/max_1200x1200/public/2026-05/Exposure-Backlog-Over-Time-%28Criticals%29.png.webp?itok=ufk48QvY\" srcset=\"/sites/default/files/styles/max_400x400/public/2026-05/Exposure-Backlog-Over-Time-%28Criticals%29.png.webp?itok=MndNfVBE 400w, /sites/default/files/styles/max_600x600/public/2026-05/Exposure-Backlog-Over-Time-%28Criticals%29.png.webp?itok=dn9X9udS 600w, /sites/default/files/styles/max_700x700/public/2026-05/Exposure-Backlog-Over-Time-%28Criticals%29.png.webp?itok=2D-MapeC 700w, /sites/default/files/styles/max_800x800/public/2026-05/Exposure-Backlog-Over-Time-%28Criticals%29.png.webp?itok=yotDsTQr 800w, /sites/default/files/styles/max_904x904/public/2026-05/Exposure-Backlog-Over-Time-%28Criticals%29.png.webp?itok=rcR_1Xws 904w, /sites/default/files/styles/max_1200x1200/public/2026-05/Exposure-Backlog-Over-Time-%28Criticals%29.png.webp?itok=ufk48QvY 1200w, /sites/default/files/styles/max_2400x2400/public/2026-05/Exposure-Backlog-Over-Time-%28Criticals%29.png.webp?itok=Uw4_UhRC 1278w\" width=\"1200\"/>\n</div>\n</div>\n</article>\n<h2 dir=\"ltr\">Underlying Structural Patterns</h2><p dir=\"ltr\">The trends point to a consistent pattern of aggregate resolution rate declining and each month a smaller proportion of vulnerabilities getting fixed. Even as validated findings rise, the total effort going to remediation appears to be shrinking.</p><p dir=\"ltr\">The data points to a shift in resource allocation. Teams are fixing individual issues faster (suggesting they might be prioritizing selectively), but overall remediation throughput is not scaling with the growing discovery volume. </p><p dir=\"ltr\">The result is a fast-growing backlog of validated exposures. Without a strategic adjustment to remediation capacity, this trajectory leads to a progressively unmanageable risk profile.</p><h2 dir=\"ltr\">What Has to Change</h2><p dir=\"ltr\">In our previous post, we outlined the need for longer-term changes: organizational redesign, better feedback loops for bug class elimination at scale, and stronger validation. Those still matter. But the accelerating backlog demands tactical steps right now, alongside those structural changes.</p><ul><li aria-level=\"1\" data-list-item-id=\"e489d0ece0e6ff8d65b2d9869b2868282\" dir=\"ltr\"><strong>Focus on overall risk reduction.</strong> MTTR tells us how fast we fix, not how much risk we're reducing. We need to pair it with resolution rate and the exposure backlog to get a full picture of whether we're reducing overall risk or just resolving faster.</li><li aria-level=\"1\" data-list-item-id=\"e46c95660bade07155d04f9fc3f447ae1\" dir=\"ltr\"><strong>Increase remediation capacity where possible.</strong> We need dedicated remediation capacity and dedicated sprints to reduce the exposure backlog. Validated vulnerability volumes have grown significantly, and remediation now requires scalable resource allocation and AI-assisted approaches to keep up</li><li aria-level=\"1\" data-list-item-id=\"e2664172f4b636e0583309fe903a58738\" dir=\"ltr\"><strong>Put AI to work on the remediation side too.</strong> As AI accelerates discovery, remediation needs the same. AI-assisted fix generation, automated regression testing, and agentic workflows help development teams process more findings to keep pace with increased discovery volume.</li></ul><p dir=\"ltr\">The good news is that we've proven we can remediate faster. Now we need to prioritize doing more of it, continuously.</p><p dir=\"ltr\"><a class=\"cta-primary-wysiwyg\" href=\"https://www.hackerone.com/resources/pf/col/home/h1-validation-solution-brief\">See how H1 Validation helps you cut through the backlog</a></p>",
  "hero_image": "https://www.hackerone.com/sites/default/files/styles/og_image/public/2026-05/More-Images-Claude-Mythos-%282%29.png.jpg?itok=J_yzTfi-",
  "listing_image": "https://www.hackerone.com/sites/default/files/styles/max_500x500/public/2026-05/More-Images-Claude-Mythos-%282%29.png.webp?itok=qS-WDFxz",
  "listing_solutions": [],
  "listing_topics": [
    "AI",
    "Exposure Management"
  ],
  "modified_time": null,
  "taxonomy": {
    "blog_topic": [
      "AI",
      "Exposure Management"
    ]
  }
}

{
  "authors": [
    "Michiel Prins",
    "Saida Wijpkema",
    "Miray Mazlumoglu"
  ],
  "body_html": "<p dir=\"ltr\">Last week, we shared <a href=\"https://www.hackerone.com/blog/opus-4-7-vulnerability-validation-benchmarks\">our benchmarks on Opus 4.7</a> and how it sharpened precision on vulnerability validation. Then OpenAI released GPT-5.5 and we had to know: how does the latest OpenAI frontier model compare against Anthropic’s models? </p><p dir=\"ltr\">We evaluated GPT-5.5 through OpenAI's Trusted Access for Cyber program, which provides early access to frontier models for cybersecurity research. That access lets us put GPT-5.5 on the same validation harness we use for every frontier model we evaluate, alongside Claude Opus 4.7 and Claude Sonnet 4.6, and push all three through the reality of vulnerability triage at scale.</p><p dir=\"ltr\">Across our platform, we're seeing two trends: time-to-discovery is shrinking as AI-assisted discovery tools accelerate, and the volume of vulnerability findings is growing. Validation that can't keep pace, in both speed and accuracy, becomes the bottleneck between a finding landing and a team remediating it. For security teams, keeping validation in step with growing vulnerability volume is critical to maintaining remediation speed. Faster validation means findings move from \"pending triage\" to \"confirmed, fix now\" in minutes rather than hours. Higher accuracy means fewer false positives wasting engineering cycles and fewer missed vulnerabilities sitting unpatched. We therefore wanted to determine which frontier model delivers the best balance of both, and whether model choice is still a meaningful lever for improving validation outcomes. </p><p dir=\"ltr\">We put three models on the same benchmark: Claude Opus 4.7, Claude Sonnet 4.6, and OpenAI's GPT-5.5. We evaluated each model using our internal validation harness, built from real-world vulnerability workflows and informed by patterns we see across the HackerOne platform. We tested on both structured CVE cases and unfiltered vulnerability reports, the kind that range from meticulously documented findings to overstated claims and AI-generated noise. We ran them first with a baseline agent, then invested in prompt engineering and additional tooling to see how far we could push performance.</p><p dir=\"ltr\">The results surprised us.</p><h2 dir=\"ltr\">The Baseline: All Three Models Are Neck-and-Neck on Precision</h2><p dir=\"ltr\">We evaluated each model on a set of publicly known CVEs (both validation cases: vulnerable code and its corresponding patch) across C/C++ projects. The agent workflow is identical for all three: trace the code, assess exploitability, and render a structured verdict.</p><p dir=\"ltr\">With the same generic prompt and minimal tool set, all three models performed remarkably well. From the perspective of correctness, a single verdict out of 38 test cases separated the best performing model from the lowest performing model, a difference of 2.5%.</p><ul><li data-list-item-id=\"e8deec2364ad6aa09050173360da07d35\"><p dir=\"ltr\"><strong>GPT-5.5 leans conservative</strong>, with fewer false positives and faster completions. When it flags a vulnerability, it's almost certainly real. It completed validations nearly 3x faster than Sonnet and 50% faster than Opus.</p></li><li data-list-item-id=\"efe1b8d31881cbb21ce5fecb051e9b946\"><p dir=\"ltr\"><strong>Sonnet 4.6 leans thorough</strong>. It catches vulnerabilities that both GPT-5.5 and Opus 4.7 miss, particularly in complex buffer overflow and memory corruption patterns. The tradeoff is that it occasionally flags patched code as still vulnerable.</p></li><li data-list-item-id=\"eb1a5d01f0cda5a29a36c0b68ad3f9db8\"><p dir=\"ltr\"><strong>Opus 4.7 sits in the middle</strong>, with balanced reasoning and strong coherence on multi-step analysis. </p></li></ul><p dir=\"ltr\">Think of each model as a security analyst with a different disposition, one more cautious, another more aggressive. Depending on your risk tolerance, whether you would rather miss fewer vulnerabilities or generate fewer false alarms, one might suit your workflow better than another. But the performance gap is narrow enough that model selection alone will not transform your validation outcomes.</p><h2 dir=\"ltr\">Where Models Agree and Where They Don't</h2><p dir=\"ltr\">We analyzed the error patterns across all three models. The finding: 75% of errors are shared by two or more models.</p><p dir=\"ltr\">Only a single CVE fooled all three, where the vulnerable code contained what appeared to be input validation, but the check was insufficient. All three models saw the bounds check and concluded the code was safe, missing that the validation logic itself was flawed.</p><p dir=\"ltr\">The overall shared failure mode is highly specific: patch completeness judgment. All three models reliably detect vulnerabilities in vulnerable code. Where they struggle is determining whether a patch fully resolves the issue, particularly when mitigations are partial or when the fix introduces minor behavioral changes that don't eliminate the root cause.</p><p dir=\"ltr\">We also tested majority-vote ensembling across all three models, running all three models on the same case and picking the verdict that two or more agreed on. It barely helped because the models share blind spots on the same ambiguous patches. When they are wrong, they tend to be wrong together, so voting amplifies errors rather than correcting them.<br/><br/>That's a notable finding on its own, but CVEs are only half the story. A clean CVE dataset doesn't capture what validation actually looks like in production, where reports arrive in every shape, quality, and degree of honesty.</p><h2 dir=\"ltr\">Beyond CVEs: The Same Pattern on Live Application Reports</h2><p dir=\"ltr\">To validate that these findings extend beyond our CVE benchmark, we ran the same models against a separate test: vulnerability reports submitted against a real web application covering XSS, SQLi, SSRF, RCE, and IDOR findings.</p><p dir=\"ltr\">These reports reflect the full spectrum of what lands in a triage queue. Some are meticulously documented with CVSS scores, step-by-step reproduction, and accurate impact analysis. Others are thinly written, vague on details, or clearly generated with AI assistance. And some exhibit a pattern familiar to anyone who has triaged bug bounty submissions: overstated impact, where a real but low-severity finding is dressed up with a theoretical exploit chain to justify a higher payout. One report chains a working SSRF into a claimed Remote Code Execution through a deserialization path that is provably impossible on the target framework. Another reports SQL injection against an endpoint that uses parameterized queries, with fabricated PoC screenshots.</p><p dir=\"ltr\">This is the reality of vulnerability triage at scale. The challenge isn't just \"is this code vulnerable?\", but it's separating signal from noise across a stream of reports that vary wildly in quality, honesty, and accuracy of impact claims. It's a problem we see across the HackerOne platform every day, and one that generic benchmarks built from clean CVE descriptions don't capture.</p><p dir=\"ltr\">All three models agreed on the large majority of reports, correctly validating XSS, SQLi, and SSRF findings regardless of report quality. On the disagreements, Opus demonstrated noticeably sharper judgment, particularly on the reports designed to mislead. Where both Sonnet and GPT-5.5 hedged with qualified verdicts, Opus committed: either confirming a vulnerability outright or rejecting it entirely.</p><p dir=\"ltr\">GPT-5.5 was the fastest model per report, completing validations in roughly half the time of Sonnet. But speed came with a consistency trade-off. On one confirmed SSRF vulnerability, GPT-5.5 returned \"Fabricated\" on its first run, then correctly identified it as \"Valid\" on rerun, with identical inputs. Both Claude models returned consistent verdicts across every run. For triage workflows where you don't get second chances, this non-determinism matters.</p><p dir=\"ltr\">We also tested GPT-5.5 with elevated reasoning effort, which improved its accuracy on complex reports to match Opus, but with significantly higher latency. The model needed 5x more tool calls than Opus to reach the same conclusions. Opus identified critical code paths in an average of 16 tool calls per report; GPT-5.5 with high reasoning effort required 85.</p><p dir=\"ltr\">On the inflated RCE claim, both Sonnet and GPT-5.5 identified that the underlying SSRF worked but the full chain was broken, and gave partial credit. Opus identified three independent reasons the chain fails and rejected the report outright. The exploit chain is provably impossible against this codebase, but partial credit for sub-components muddles the signal that matters to a triaging team.</p><p dir=\"ltr\">On the fabricated SQL injection, Sonnet correctly identified the endpoint was parameterized but stopped there. Opus cross-checked the PoC's response bodies against what the controller actually returns, found inconsistencies in the field selection, and concluded the evidence was manufactured, not merely mistaken. GPT-5.5 reached the same \"not a vulnerability\" conclusion as Opus here, but through less rigorous reasoning, it identified the parameterized query without investigating whether the PoC evidence was fabricated.</p><p dir=\"ltr\">On speed, GPT-5.5 had the lowest time per report, but Opus was the most efficient in terms of reasoning steps. When the answer is \"no,\" Opus finds it in fewer tool calls and moves on. GPT-5.5 often searched extensively but arrived at the same conclusion Opus reached in a fraction of the steps — or worse, arrived at the wrong one.</p><p dir=\"ltr\">Both models correctly validated critical findings: UNION-based SQL injection, stored XSS, SSRF with file read, regardless of report quality. A hastily written three-line XSS report was triaged just as accurately as a detailed write-up with reproduction steps and remediation guidance.</p><p dir=\"ltr\">The pattern across both benchmarks is consistent:</p><ul><li data-list-item-id=\"ee374d4c132c2958524a2227e34aa399d\"><p dir=\"ltr\">GPT-5.5 is fast and capable on straightforward findings, but less reliable on reports that require multi-step reasoning or that are designed to mislead.</p></li><li data-list-item-id=\"e4e184a47aa6e6c6feeaefd82211ae7fb\"><p dir=\"ltr\">Opus demonstrates the highest \"signal efficiency\": it reads fewer files, makes fewer tool calls, and still arrives at more decisive, correct verdicts.</p></li><li data-list-item-id=\"e00ffe11d1f1a042557755cd76dd22078\"><p dir=\"ltr\">When we gave GPT-5.5 more reasoning budget, it closed the accuracy gap, but at significant latency cost, suggesting the limitation is in reasoning quality per step rather than exploration breadth.</p></li></ul><p dir=\"ltr\">Opus is the better choice when false positives are expensive and you need decisive, actionable verdicts. But the gap remains narrow enough that the consistent finding holds: both models are already operating at a level where the remaining errors are judgment calls about exploit chain completeness and impact accuracy, the same category that better tooling addresses.</p><p dir=\"ltr\">What this benchmark reinforces is that the hardest part of validation at scale isn't the technical analysis, it's the judgment layer: distinguishing overstated impact from genuine severity, AI-generated noise from legitimate findings, and partial truths from fabrications. That judgment is shaped by seeing thousands of real submissions across hundreds of programs. It's the kind of signal that lives in our platform data, not in any model's pretraining set, and it's what allows us to build validation tooling that handles the messy reality of what actually gets reported.</p><h2 dir=\"ltr\">The Power of Tooling Today</h2><p dir=\"ltr\">Here's what excites us most: every frontier model already performs at 80%+ accuracy with a completely generic agent, no model-specific tuning, no specialized tools, minimal prompting.</p><p dir=\"ltr\">The remaining errors are not fundamental reasoning limitations, they come from two categories: determining whether a patch fully resolves a vulnerability, and separating genuine findings from noise in reports with fabricated evidence or overstated impact. Those are the kinds of judgment that better tooling can address.</p><p dir=\"ltr\">When we invested in the scaffolding around the model, refining the prompt to emphasize diff-aware reasoning, adding tools for targeted code navigation, and structuring the validation workflow to explicitly compare before and after patch behavior, we pushed accuracy to 98% across our benchmark set.</p><p dir=\"ltr\">This held regardless of which model powered the agent.</p><h2 dir=\"ltr\">But For How Long?</h2><p dir=\"ltr\">At HackerOne, we closely follow the changes in new models coming up and how they affect accuracy and effectiveness of the agents we are building. Validation and remediation being two significant contributors to resolve vulnerabilities discovered every day even faster than before.</p><p dir=\"ltr\">Today, the differentiator is tooling. The performance gap between models is narrow enough that a different set of vulnerabilities or a different codebase could easily reshuffle the ranking. What remained consistent across all our experiments is that the gap between a generic agent and an optimized one far exceeds the gap between models.</p><p dir=\"ltr\">We are building the advanced tooling necessary to make frontier models better. The most interesting question in agentic security isn't which model to pick. It's how quickly the scaffolding we build today becomes unnecessary. Until then, the advantage goes to teams that can operationalize AI effectively, and that means not just better prompts and tools, but better signal.</p><p dir=\"ltr\">The judgment that separates a fabricated report from a genuine critical finding is learned from what actually gets reported and confirmed across thousands of programs, not from pretraining. That’s the data moat that turns a capable model into a reliable validation system, and what allows us to close the gap between discovery and remediation as the stream of vulnerabilities continues to grow.</p><p dir=\"ltr\"><a class=\"cta-primary-wysiwyg\" href=\"https://www.hackerone.com/resources/pf/col/home/h1-validation-solution-brief\">See how we turn noisy reports into clear verdicts</a></p>",
  "hero_image": "https://www.hackerone.com/sites/default/files/styles/og_image/public/2026-05/Blog-Header-Beyond-Model-Selection-...-%281%29.png.jpg?itok=61q3GBQG",
  "listing_image": "https://www.hackerone.com/sites/default/files/styles/max_500x500/public/2026-05/Blog-Header-Beyond-Model-Selection-...-%281%29.png.webp?itok=34JlCk05",
  "listing_solutions": [],
  "listing_topics": [
    "AI",
    "Exposure Management"
  ],
  "modified_time": null,
  "taxonomy": {
    "blog_topic": [
      "AI",
      "Exposure Management"
    ]
  }
}

{
  "authors": [
    "Michiel Prins"
  ],
  "body_html": "<p dir=\"ltr\">For a long time, security programs had a built-in buffer. Vulnerabilities were discovered, then exploited later. That gap made risk manageable.</p><p dir=\"ltr\">Claude Mythos and other frontier models are a signal that the gap is closing. Discovery and exploitation are starting to happen on the same timeline, compressing the window teams once relied on.</p><p dir=\"ltr\">That shift changes the job. Finding issues isn’t the hard part anymore. The challenge is figuring out what’s real, what’s exploitable, and what actually matters before attackers get there first.</p><p dir=\"ltr\">That’s why validation has become the control point. With Continuous Threat Exposure Management (CTEM), when a finding is proven exploitable, prioritization becomes clearer, developers have the evidence they need, and remediation moves without the usual back-and-forth.</p><p dir=\"ltr\">That’s where HackerOne comes in. We help organizations validate what’s real, connect it to business impact, and move issues toward remediation faster.</p><h2>What’s Launching</h2><p dir=\"ltr\">We’re introducing new capabilities for Hai, our coordinated system of agentic workflows, designed to help enterprise teams turn validated findings into faster action.</p><p dir=\"ltr\">These capabilities support two ways teams reduce exposure: proving what matters, and moving to fix faster.</p><h4>Prove What Matters with Agentic Validation and Prioritization</h4><p dir=\"ltr\">This path focuses on helping teams quickly determine what’s real, what’s exploitable, and what actually matters before attackers get there first.</p><ul><li aria-level=\"1\" data-list-item-id=\"e759ce84780871d325ff0736cb484ce3f\" dir=\"ltr\"><strong>Agentic Validation: </strong>Receive one trusted recommendation for every finding, informed by your program history. Now enhanced with similar vulnerability analysis, attack path diagrams, priority determination, and exploitability signals.</li><li aria-level=\"1\" data-list-item-id=\"ec2e93b035cf125f7485813b39568d230\" dir=\"ltr\"><strong>Agentic Prioritization:</strong> Prioritize validated, exploitable risk based on business impact, with customizable business logic.</li></ul><h4>Move to Fix Faster with Agentic Exploitation and Linear Integration</h4><p dir=\"ltr\">This path focuses on turning validated findings into action without the usual friction between security and engineering.</p><ul><li aria-level=\"1\" data-list-item-id=\"e1dc944b3736a8ca64af47a26d625ebf2\" dir=\"ltr\"><strong>Agentic Exploitation:</strong> Accelerate triage with automated exploitation for credentials or sensitive information exposure, XSS, and other injection-type vulnerabilities. Screenshot-driven proof in every report, with broader coverage coming next.</li><li aria-level=\"1\" data-list-item-id=\"ec4bd8759cb6b57a791241f0eb6b38c66\" dir=\"ltr\"><strong>Linear Integration: </strong>Use context from Linear issues to help validate vulnerabilities faster and more accurately. Push validated findings into Linear for a seamless find-to-fix workflow and remediate faster.</li></ul><p>\n<div class=\"node node--type-cta-card node--view-mode-wysiwyg-card wysiwyg-cta-card not-prose flex flex-col\">\n<a class=\"wysiwyg-cta-card-link no-underline flex flex-col md:flex-row-reverse grow bg-white group-[.dark-bg]/c:bg-gradient-to-b group-[.dark-bg]/c:from-[#30344B] group-[.dark-bg]/c:to-blue-black-100 border rounded overflow-hidden border-blue-black-20 group-[.dark-bg]/c:border-blue-black-80 hover:bg-gradient-to-b hover:from-white hover:to-blue-black-5 group-[.dark-bg]/c:hover:brightness-125\" href=\"/platform/hai\">\n<div class=\"wysiwyg-cta-card-media mx-1 mt-1 md:mx-0 md:mt-0 rounded md:rounded-none border md:border-none border-blue-black-80 overflow-hidden md:shrink-0 md:[&amp;_.media--type-image]:h-full [&amp;_.field--type-image]:relative [&amp;_.field--type-image]:w-full md:[&amp;_.field--type-image]:w-50 [&amp;_.field--type-image]:h-56 md:[&amp;_.field--type-image]:h-full md:[&amp;_.field--type-image]:min-h-[158px] [&amp;_.field--type-image_img]:absolute [&amp;_.field--type-image_img]:w-full [&amp;_.field--type-image_img]:h-full [&amp;_.field--type-image_img]:object-cover\">\n<div class=\"wysiwyg-cta-card-image md:h-full field field--name-field-cta-card-image field--type-entity-reference field--label-hidden field__item\">\n<article class=\"media media--type-image media--view-mode-cta-card-image [&amp;.align-center_img]:mx-auto [&amp;.align-left_img]:my-0 [&amp;.align-left_img]:mr-[2em] [&amp;.align-right_img]:my-0 [&amp;.align-right_img]:ml-[2em]\">\n<div class=\"field field--name-field-media-image field--type-image field--label-visually_hidden\">\n<div class=\"field__label visually-hidden\">Image</div>\n<div class=\"field__item\"> <img alt=\"Hai\" height=\"500\" loading=\"lazy\" sizes=\"(min-width: 1280px) 450px, (min-width: 1024px) 400px, (min-width: 768px) 94vw, (min-width: 640px) 94vw, 100vw\" src=\"/sites/default/files/styles/max_500x500/public/2025-05/Hai-orb-with-logo.png.webp?itok=tv8yLJzA\" srcset=\"/sites/default/files/styles/max_325x325/public/2025-05/Hai-orb-with-logo.png.webp?itok=Id0CIsP5 325w, /sites/default/files/styles/max_400x400/public/2025-05/Hai-orb-with-logo.png.webp?itok=abFvFJeL 400w, /sites/default/files/styles/max_650x650/public/2025-05/Hai-orb-with-logo.png.webp?itok=LHHtn-Sl 650w, /sites/default/files/styles/max_800x800/public/2025-05/Hai-orb-with-logo.png.webp?itok=uF8k4xxD 800w, /sites/default/files/styles/max_904x904/public/2025-05/Hai-orb-with-logo.png.webp?itok=3w9OZuCR 904w, /sites/default/files/styles/max_1000x1000/public/2025-05/Hai-orb-with-logo.png.webp?itok=2FsaMZo3 1000w, /sites/default/files/styles/max_1200x1200/public/2025-05/Hai-orb-with-logo.png.webp?itok=TEcCPSdd 1200w\" width=\"500\"/>\n</div>\n</div>\n</article>\n</div>\n</div>\n<div class=\"wysiwyg-cta-card-content p-8 flex flex-col grow gap-2 justify-center\">\n<div class=\"wysiwyg-cta-card-eyebrow text-primary-innovative-pink text-sm font-medium leading-150 field field--name-field-cta-card-eyebrow field--type-string field--label-hidden field__item\">Hai: Your HackerOne AI Security Agent</div>\n<div class=\"wysiwyg-cta-card-headline h4 group-[.dark-bg]/c:text-white field field--name-field-cta-card-headline field--type-string field--label-hidden field__item\">Faster Fixes. Smarter Insights.</div>\n<div class=\"wysiwyg-cta-card-link-text flex flex-row items-center gap-1 text-sm font-medium leading-140 text-blue-black-100 after:content-icon-cta-secondary after:block after:leading-none after:w-3 after:h-3 group-[.dark-bg]/c:text-white\">\n          Learn more about Hai\n        </div>\n</div>\n</a>\n</div>\n</p><h2>Why Continuous Validation Matters</h2><p dir=\"ltr\">Security teams can only move as fast as their confidence in what’s actually exploitable.</p><p dir=\"ltr\">Without proof, prioritization slows down. Teams spend more time sorting, reviewing, and debating what matters. Developers often need to re-validate issues before acting. Important findings lose momentum across handoffs and competing priorities.</p><p dir=\"ltr\">Validation changes that.</p><p dir=\"ltr\">When a finding is proven real and exploitable, decisions get easier. Security teams focus faster, developers trust the signal, and remediation moves with less friction. </p><p dir=\"ltr\">As exploit windows move from days to hours, it becomes even more critical that validation is not only accurate, but fast.</p><h2>Validate and Prioritize Risk with Agentic Workflows </h2><p dir=\"ltr\">Not every validated finding carries the same business impact. The challenge is applying that judgment consistently and quickly.</p><p dir=\"ltr\">Agentic prioritization moves teams beyond a flat queue by tying validated risk to business context. That means clearer decisions earlier, stronger focus, and less time spent gathering context just to agree on what comes first.</p><p dir=\"ltr\">As programs scale and AI increases discovery volume, consistency becomes just as important as speed.</p><p dir=\"ltr\">Teams make constant decisions across incoming findings. What needs follow-up? What moves forward? What doesn’t? Over time, those calls can vary based on reviewer experience or sheer volume.</p><p dir=\"ltr\">Agentic validation reduces that variance by giving teams a reliable recommendation and a more repeatable way to work through validated findings. The result is less duplicate effort, more consistent decisions, and steadier quality as volume grows.</p><h2>Move from Finding to Fix with Agentic Exploitation and Linear Integration</h2><p dir=\"ltr\">Developer trust matters. Validation earns it.</p><p dir=\"ltr\">When a finding reaches engineering without strong evidence, the next step is often more investigation or it gets deprioritized. That slows triage and adds back-and-forth before remediation starts. Clear proof changes that.</p><p dir=\"ltr\">By adding evidence directly to reports, agentic exploitation helps teams move from possibility to action. Developers can understand impact faster and start fixing things sooner. For security teams, that means less time re-proving issues and more time getting them resolved.</p><p dir=\"ltr\">Even with validation, remediation can still slow down once work moves across systems.</p><p dir=\"ltr\">Security context lives in one place. Engineering context lives in another. Progress depends on how quickly those connect bi-directionally.</p><p dir=\"ltr\">Linear integration helps bridge that gap in two ways. It brings engineering context into the finding to improve validation accuracy, and it pushes validated findings directly into Linear so teams can move from discovery to remediation without unnecessary delays.</p><h2 dir=\"ltr\">Turning Proof Into Continuous Risk Reduction</h2><p dir=\"ltr\">Security leaders aren’t measured by how many issues their teams review. They’re measured by whether risk actually goes down.</p><p dir=\"ltr\">Validation turns a stream of potential issues into a path to action by proving what’s real and what’s exploitable. When teams have that proof, prioritization becomes clearer, developers get the evidence they need, and remediation moves without the usual back-and-forth.</p><p dir=\"ltr\">This launch reflects how we’re continuing to build the HackerOne Platform: not just to find more issues, but to validate what’s real, prioritize what matters, and fix it fast.</p><p dir=\"ltr\"><a class=\"cta-primary-wysiwyg\" href=\"https://www.hackerone.com/platform/hai\">Validate Faster with Hai</a></p>",
  "hero_image": "https://www.hackerone.com/sites/default/files/styles/og_image/public/2026-04/Blog-Header-When-Security-Teams-Can-Prove-Exposure-Risk%2C-They-Can-Reduce-It-Faster.png.jpg?itok=B5_UTWza",
  "listing_image": "https://www.hackerone.com/sites/default/files/styles/max_500x500/public/2026-04/Blog-Header-When-Security-Teams-Can-Prove-Exposure-Risk%2C-They-Can-Reduce-It-Faster.png.webp?itok=ym1JaUcd",
  "listing_solutions": [
    "Hai"
  ],
  "listing_topics": [
    "AI",
    "Exposure Management"
  ],
  "modified_time": null,
  "taxonomy": {
    "blog_topic": [
      "AI",
      "Exposure Management"
    ],
    "h1_solution": [
      "Hai"
    ]
  }
}

{
  "authors": [
    "Miray Mazlumoglu",
    "Willian Van Der Velde"
  ],
  "body_html": "<p dir=\"ltr\">The cybersecurity world lit up when Anthropic released Claude Opus 4.7. The initial reactions have been predictable and reasonable: people want to know if this model finds more bugs. Vendors are racing to publish discovery benchmarks, and the numbers look impressive. Visual reasoning is better, agentic coding workflows are faster, and the frontier moved.</p><p dir=\"ltr\">At HackerOne, we've been curious about something specific: how does Opus 4.7 perform when the task isn't finding vulnerabilities, but validating that they are exploitable and reachable?</p><p dir=\"ltr\">AI-powered vulnerability discovery is progressing fast, and that's a good thing. But as discovery gets better, the volume of findings landing on security teams grows with it at a much faster pace. Between bug bounty programs, scanners, SAST, DAST, penetration tests, and <a href=\"https://www.hackerone.com/blog/continuous-threat-exposure-management-remediation-crisis\" target=\"_blank\">now AI-powered discovery agents</a>, the pipeline of potential issues keeps expanding. The question that follows, as it always has in vulnerability management, is: which of these findings are actually exploitable?</p><p dir=\"ltr\">To answer that, we use an agent that reads source code, traces data flows, understands application logic, and produces a reasoned verdict with specific evidence. As discovery scales up, validation needs to scale with it at a much faster speed, reducing the exploitation window to a minimum.</p><p>We want to give our customers the best experiences possible, so when Opus 4.7 dropped, we ran it immediately through two validation benchmarks. The results tell a nuanced story.</p><h2 dir=\"ltr\">Benchmark 1: Validating Real Vulnerability Reports</h2><p dir=\"ltr\">Our first benchmark uses HackerOne's internal validation dataset, a curated set of findings from open source repositories that have been definitively marked as valid or invalid by human security analysts. The agent receives a finding, analyzes the relevant code, and must produce a definitive, evidence-backed verdict.</p><p dir=\"ltr\"><strong>The biggest improvement showed up in invalid finding detection, where Opus 4.7 improved by about 2 percentage points.</strong> For security teams running vulnerability programs, this matters. A significant portion of analyst time goes into evaluating reports that look severe, but on closer inspection, are not practically exploitable or are based on a misunderstanding of application behavior. A model that's better at confidently filtering those out gives security teams their time back to focus on the findings that actually matter.</p><p dir=\"ltr\">Opus 4.7 improved overall accuracy by ~2.5 percentage points over Opus 4.6 on definitive, code-backed validation calls. On a task this complex, against findings and actual codebases, that's a meaningful gain.</p><p dir=\"ltr\">Both models performed equally well at identifying valid reports. We haven’t observed a significant difference there.</p><h2 dir=\"ltr\">Benchmark 2: CVE Validation on Open-Source Code</h2><p dir=\"ltr\">Our second benchmark uses publicly known CVEs in open-source software, drawn from an <a href=\"https://github.com/Eshe0922/ReposVul\" target=\"_blank\">academic dataset of nearly 7,000 CVE records</a> across C, Python, Java, and C++ projects. For each CVE, we create two code snapshots: the vulnerable version (before the fix) and the patched version (after the fix). The agent receives the CVE description and the code, then must determine whether the codebase is vulnerable.</p><p dir=\"ltr\">This is where the story gets interesting, because the two models show fundamentally different validation profiles.</p><div align=\"center\" dir=\"ltr\"><table class=\"table\"><tbody><tr><td><p dir=\"ltr\"><span class=\"pink-text-wysiwyg\"><strong>Opus 4.7 is the precision model.</strong></span></p></td><td><p dir=\"ltr\"><strong>It delivered a ~14 percentage point improvement in precision over Opus 4.6, with roughly 3.5x fewer false positives.</strong> False positives are a major drain: the finder flags an issue, the validator confirms it, and now the burden shifts to the security analyst to prove it isn’t actually exploitable.</p><p dir=\"ltr\">When Opus 4.7 says a codebase is vulnerable, you can trust that verdict at a significantly higher rate. It also reduced verdict extraction failures by over 90%, meaning the agent was far more reliable at producing structured, usable outputs.</p></td></tr><tr><td><p dir=\"ltr\"><span class=\"pink-text-wysiwyg\"><strong>Opus 4.6 favors recall.</strong></span></p></td><td><p dir=\"ltr\"><strong>It catches nearly every real vulnerability, but at the cost of a high false positive rate mentioned above.</strong></p><p dir=\"ltr\">In a security triage pipeline where missing a real vulnerability is worse than over-flagging, that bias toward recall could be a deliberate tradeoff, but it shifts the burden downstream to security analysts.</p></td></tr></tbody></table></div><p dir=\"ltr\"><strong>On critical vulnerabilities (CVSS 9-10), the gap widens.</strong> Opus 4.7 achieved near-perfect precision on critical CVEs, while Opus 4.6 was only right 6 out of 10 times when it said a critical CVE was valid. For the findings that carry the most organizational risk, Opus 4.7 delivers higher-confidence verdicts.</p><p dir=\"ltr\">Overall accuracy improved by ~3.5 percentage points, while the F1 tradeoff reflects the precision-recall balance: Opus 4.7 is more precise and operationally cleaner, while Opus 4.6 casts a wider net.</p><p dir=\"ltr\">For security teams, the practical implication is clear. If your bottleneck is analyst time spent chasing false positives, Opus 4.7 is a direct improvement. If you're in an environment where you cannot afford to miss a single finding regardless of noise, the recall profile of Opus 4.6 still has value. We're exploring model-routing strategies that leverage each model's strengths based on severity and context.</p><p dir=\"ltr\"><em>Both benchmarks use the same code-backed validation agent, with the only variable being the underlying model. We'll continue publishing these results as new models become available.</em></p><h2 dir=\"ltr\">What We See in Production</h2><p dir=\"ltr\">Benchmarks measure capability in controlled conditions. Production tells you whether that capability holds up.</p><p dir=\"ltr\">We're seeing Opus 4.7 deliver gains that meet or exceed our benchmark numbers, particularly in more complex scenarios. A few patterns stand out:</p><ul><li aria-level=\"1\" data-list-item-id=\"ead64f8c2c42da9fef11def5a3bdf5b85\" dir=\"ltr\"><strong>Better instruction following.</strong> Our validation agents run multi-step workflows: clone a repository, search for relevant code paths, trace data flows, and produce a structured verdict with evidence. Opus 4.7 follows these workflows more reliably, with fewer deviations or hallucinated steps.</li><li aria-level=\"1\" data-list-item-id=\"e10ea41c8609dddff244956cb3c905a19\" dir=\"ltr\"><strong>Stronger coherence in long-running tasks.</strong> Validation isn't a single prompt-response cycle. Our agents regularly execute 10-20 tool calls per validation, reading multiple files and building up context across an entire codebase. Opus 4.7 maintains coherence across these extended interactions better than its predecessor.</li><li aria-level=\"1\" data-list-item-id=\"e85bfe54f3d552d6675408cb9c999db4b\" dir=\"ltr\"><strong>Improved multi-step reasoning.</strong> The hardest validation cases involve chained vulnerabilities that span multiple files and functions. Think an SSRF that leads to cloud metadata exposure that leads to credential theft or a stored XSS that chains into account takeover. Opus 4.7 handles these multi-step reasoning chains with more precision.</li><li aria-level=\"1\" data-list-item-id=\"e90daee968e729a804ac3ee0492215a3a\" dir=\"ltr\"><strong>Higher token efficiency.</strong> Consistent with what others have observed, Opus 4.7 is more efficient in how it uses its context. More validations per dollar, which matters at scale. In our benchmark, it achieved higher precision with fewer model calls per case, producing more thorough analyses per turn rather than spreading reasoning across many smaller steps.</li></ul><h2 dir=\"ltr\">Validation Is the Multiplier, Remediation is Next</h2><p dir=\"ltr\">The core challenge of identifying real, exploitable vulnerabilities hasn’t changed.</p><p dir=\"ltr\">What has changed is everything around it. More findings, finding real critical vulnerabilities is more accessible than ever, the exposure window needs to be shorter than ever. Security teams must operate at an unprecedented speed with an unprecedented amount of real valid security findings.</p><p dir=\"ltr\">Fix all the things! But here's even more things! Agentic validation is what makes this challenge manageable, turning a growing stream of potential issues into a smaller set of real, exploitable risks. It replaces uncertainty with evidence and gives teams the clarity they need to take action and fix what matters.</p><p dir=\"ltr\">At HackerOne, we see discovery and validation as closely connected. But as volume and speed increase, validation becomes the deciding factor. It determines whether more findings create more noise or lead to real security improvements.</p><p dir=\"ltr\">That’s what we’re focused on building: validation that can keep up with the pace of discovery and help teams move from findings to fixes.</p><p dir=\"ltr\"><a class=\"cta-primary-wysiwyg\" href=\"https://www.hackerone.com/resources/pf/col/home/h1-validation-solution-brief\">Make “is it exploitable?” a faster call with h1 Validation</a></p>",
  "hero_image": "https://www.hackerone.com/sites/default/files/styles/og_image/public/2026-04/Some-CISOs-Feel-Prepared-for-AI.png.jpg?itok=cS-QkU-P",
  "listing_image": "https://www.hackerone.com/sites/default/files/styles/max_500x500/public/2026-04/Some-CISOs-Feel-Prepared-for-AI.png.webp?itok=015jb-e6",
  "listing_solutions": [],
  "listing_topics": [
    "AI",
    "Exposure Management"
  ],
  "modified_time": null,
  "taxonomy": {
    "blog_topic": [
      "AI",
      "Exposure Management"
    ]
  }
}

{
  "authors": [
    "Luke Stephens"
  ],
  "body_html": "<p dir=\"ltr\">AI moved from “we should explore this” to “this is a core part of our business” in record time. That's exciting, but it's also one of the fastest ways to accidentally expand your organization’s attack surface, especially once AI systems start retrieving internal data, calling tools, chaining actions, or making key decisions. That’s why continuous security testing is becoming the default operating model for teams deploying AI at scale.</p><p dir=\"ltr\">Most hands-on security practitioners will tell you that AI adoption is fast outpacing security coverage, and this sentiment was backed by HackerOne’s latest enterprise research. In a survey of 303 security leaders (in January to February 2026), <a href=\"https://www.hackerone.com/report/security-testing-for-ai-coverage-gap\">almost every organization reported operating more AI or ML systems</a> than a year ago, but fewer reported formally testing most of those systems.</p><p dir=\"ltr\">In the same research, a clear maturity signal emerges: the teams that feel well-resourced for AI security skew towards breadth. They are not betting on a single control, a single scan, or a single red team exercise. Instead, they build continuity by combining multiple distinct methods, each covering different blind spots, and each feeding the next loop of validation and remediation.</p><p dir=\"ltr\">What follows is a practical breakdown of why the “seven method” approach works, what each method is best at catching, and how to stitch them together into a continuous security program that can keep pace with AI at scale.</p><h2 dir=\"ltr\">AI Adoption Is Scaling Faster Than Security Coverage</h2><p dir=\"ltr\">As AI systems proliferate, continuous security testing is the only way to keep coverage aligned with what’s actually in production. In HackerOne’s research, 94% of organizations reported adding AI or ML systems in the past year, but only 66% said that most of their AI or ML systems undergo formal security testing.</p><p dir=\"ltr\">That gap gets more dangerous when you add two more details from the same study.</p><ul><li aria-level=\"1\" data-list-item-id=\"e63139cbb8a637c7dfc01053bf76a1a18\" dir=\"ltr\"><strong>First, only 55% of security leaders said unsanctioned AI usage is fully tracked</strong>, 33% described it as only partially tracked and 10% said it is tracked informally. Put plainly: a meaningful slice of AI usage is not properly monitored, secured or even known about.</li><li aria-level=\"1\" data-list-item-id=\"ee54753ace425d6f41ee033e41d0da014\" dir=\"ltr\"><strong>Second, the “AI footprint” most enterprises are dealing with is not one chatbot tucked away in marketing.</strong> In production, respondents reported widespread use of agentic and embedded AI patterns: AI agents (78%), GenAI code assistants (72%), embedded AI in SaaS tools (66%), and autonomous workflows (55%).</li></ul><p dir=\"ltr\">Each of these patterns tends to increase the number of integrations, permissions, data paths, and tool calls you must reason about, which is exactly where AI security gets difficult. When AI becomes a layer inside many workflows, it becomes a multiplier for how many ways a system can be probed, steered, or abused. And that is the root reason security programs are moving from periodic testing to continuous validation. More on that later.</p><h2 dir=\"ltr\">Real Attacks Are Already Landing</h2><p dir=\"ltr\">A lot of AI security discussions are still being framed as hypothetical, but the data shows that these attacks are already taking place.</p><p dir=\"ltr\">In the survey, 84% of organizations reported experiencing AI-related attacks or vulnerabilities in the past 12 months. Even more telling is where those attacks show up. The most commonly reported AI-related attack types span multiple system layers: infrastructure weaknesses like insecure APIs, unauthorized access, and function or agent abuse (51%), model behavior failures like hallucinations or harmful and unsafe outputs (46%), and prompt and interaction attacks like prompt injection, jailbreaks, and guardrail bypasses (40%).</p>\n<article class=\"media media--type-image media--view-mode-media-embed-default [&amp;.align-center_img]:mx-auto [&amp;.align-left_img]:my-0 [&amp;.align-left_img]:mr-[2em] [&amp;.align-right_img]:my-0 [&amp;.align-right_img]:ml-[2em]\">\n<div class=\"field field--name-field-media-image field--type-image field--label-visually_hidden\">\n<div class=\"field__label visually-hidden\">Image</div>\n<div class=\"field__item\"> <img alt=\"The Top Three AI System Attacks Span Multiple Layers\" height=\"676\" loading=\"lazy\" sizes=\"(min-width: 1280px) 1200px, (min-width: 1024px) 904px, (min-width: 768px) 700px, (min-width: 640px) 600px, 100vw\" src=\"/sites/default/files/styles/max_1200x1200/public/2026-04/Source-HackerOne%27s-2026-Coverage-Gaps-in-AI-Attack-Surface-Testing-Survey-Q-What-is-your-organization%27s-primary-industry-n-303-security-leaders.png.webp?itok=GgA7xYE3\" srcset=\"/sites/default/files/styles/max_400x400/public/2026-04/Source-HackerOne%27s-2026-Coverage-Gaps-in-AI-Attack-Surface-Testing-Survey-Q-What-is-your-organization%27s-primary-industry-n-303-security-leaders.png.webp?itok=esbdamgk 400w, /sites/default/files/styles/max_600x600/public/2026-04/Source-HackerOne%27s-2026-Coverage-Gaps-in-AI-Attack-Surface-Testing-Survey-Q-What-is-your-organization%27s-primary-industry-n-303-security-leaders.png.webp?itok=syNaJvsJ 600w, /sites/default/files/styles/max_700x700/public/2026-04/Source-HackerOne%27s-2026-Coverage-Gaps-in-AI-Attack-Surface-Testing-Survey-Q-What-is-your-organization%27s-primary-industry-n-303-security-leaders.png.webp?itok=KrsR0Fz9 700w, /sites/default/files/styles/max_800x800/public/2026-04/Source-HackerOne%27s-2026-Coverage-Gaps-in-AI-Attack-Surface-Testing-Survey-Q-What-is-your-organization%27s-primary-industry-n-303-security-leaders.png.webp?itok=iBrvvrhX 800w, /sites/default/files/styles/max_904x904/public/2026-04/Source-HackerOne%27s-2026-Coverage-Gaps-in-AI-Attack-Surface-Testing-Survey-Q-What-is-your-organization%27s-primary-industry-n-303-security-leaders.png.webp?itok=EH_GIFhZ 904w, /sites/default/files/styles/max_1200x1200/public/2026-04/Source-HackerOne%27s-2026-Coverage-Gaps-in-AI-Attack-Surface-Testing-Survey-Q-What-is-your-organization%27s-primary-industry-n-303-security-leaders.png.webp?itok=GgA7xYE3 1200w, /sites/default/files/styles/max_2400x2400/public/2026-04/Source-HackerOne%27s-2026-Coverage-Gaps-in-AI-Attack-Surface-Testing-Survey-Q-What-is-your-organization%27s-primary-industry-n-303-security-leaders.png.webp?itok=xmkweTs1 1278w\" width=\"1200\"/>\n</div>\n</div>\n</article>\n<p dir=\"ltr\">This is the clearest argument against relying on a single testing technique, and moving toward layered, continuous security testing. If your risk surface includes both “classic” security failures (like API auth issues) and AI-specific failures (like unexpected tool execution paths triggered by prompt injection), then your testing needs to cover both deterministic code paths and non-deterministic behavioral paths.</p><p dir=\"ltr\">The cost signal in the research is equally hard to ignore. Among organizations that experienced AI-related attacks or vulnerabilities, about 72% reported at least $1 million in total financial impact over the last 12 months.</p><p dir=\"ltr\">HackerOne’s analysis also reports a median cost of about $803K per attack, underscoring that “AI incidents” are not a small inconvenience, they are events that blow out budgets and disrupt business operations.</p><p dir=\"ltr\">The most actionable (and sobering) insight is how risk scales with AI itself. The research highlights a directional pattern: as organizations move from a small AI footprint (around two AI systems) to a larger footprint (around eight to ten AI systems), they report materially more attacks and materially higher costs. The same pattern shows up even as organizations increase their number of testing methods, which is an important reminder that scale forces you to professionalize and operationalize, not just “add a test”.</p><p dir=\"ltr\">This is also the context behind another striking estimate in the summary: adding each new AI or ML system is associated with roughly $300K in additional risk, on average. Every new AI system should come with a repeatable, continuous security motion, not a one-off pre-launch checkbox.</p><h2 dir=\"ltr\">Continuous AI Security Is Not a Slogan</h2><p dir=\"ltr\">“Continuous security” is such a common phrase now, but the concept is stronger than ever if you can define it in more pragmatic operational terms. In practice, continuous security testing means a repeatable loop of discovery, validation, prioritization, and remediation that stays live as models, prompts, tools, and permissions change.</p><p dir=\"ltr\">The recommended path forward is described as continuous security across the AI lifecycle: continuously discovering new and evolving exposures, validating what is real and exploitable, prioritizing based on impact, and driving measurable remediation.</p><p dir=\"ltr\">If you want a framework for the same idea, HackerOne points to Continuous Threat Exposure Management (CTEM). CTEM existed as a concept before AI was popularized, but the concepts are still sound. AI tooling just needs to be added to the attack surface that is being managed. If you aren't familiar, CTEM is a continuous loop that discovers exposures, assesses exploitability, prioritizes by business impact, validates through real-world simulation, and remediates. The key difference compared to traditional vulnerability management is that CTEM is designed to stay live as systems change. It tests continuously.</p><p dir=\"ltr\">This matters specifically for AI because AI systems are not static. Prompts evolve, guardrails get tuned, tools get added, agent permissions expand, models get swapped. In other words, the attack surface changes at the same cadence as product iteration, sometimes faster. </p><p dir=\"ltr\">So the question is not “should we test?” The question is “how do we create a continuous testing cycle that stays trustworthy as the system changes?”</p><p dir=\"ltr\">That is exactly why the “seven method” pattern is so useful. Each method produces a different type of security signal. Some are best at catching known issues early. Some are best at surfacing emergent behavior pre-release. Some exist to constrain damage at runtime. Some exist to find the weird edge cases you only discover once real attackers and real users start poking at your system.</p><p dir=\"ltr\">\n<div class=\"node node--type-cta-card node--view-mode-wysiwyg-card wysiwyg-cta-card not-prose flex flex-col\">\n<a class=\"wysiwyg-cta-card-link no-underline flex flex-col md:flex-row-reverse grow bg-white group-[.dark-bg]/c:bg-gradient-to-b group-[.dark-bg]/c:from-[#30344B] group-[.dark-bg]/c:to-blue-black-100 border rounded overflow-hidden border-blue-black-20 group-[.dark-bg]/c:border-blue-black-80 hover:bg-gradient-to-b hover:from-white hover:to-blue-black-5 group-[.dark-bg]/c:hover:brightness-125\" href=\"https://www.hackerone.com/playbook/ai-security\">\n<div class=\"wysiwyg-cta-card-media mx-1 mt-1 md:mx-0 md:mt-0 rounded md:rounded-none border md:border-none border-blue-black-80 overflow-hidden md:shrink-0 md:[&amp;_.media--type-image]:h-full [&amp;_.field--type-image]:relative [&amp;_.field--type-image]:w-full md:[&amp;_.field--type-image]:w-50 [&amp;_.field--type-image]:h-56 md:[&amp;_.field--type-image]:h-full md:[&amp;_.field--type-image]:min-h-[158px] [&amp;_.field--type-image_img]:absolute [&amp;_.field--type-image_img]:w-full [&amp;_.field--type-image_img]:h-full [&amp;_.field--type-image_img]:object-cover\">\n<div class=\"wysiwyg-cta-card-image md:h-full field field--name-field-cta-card-image field--type-entity-reference field--label-hidden field__item\">\n<article class=\"media media--type-image media--view-mode-cta-card-image [&amp;.align-center_img]:mx-auto [&amp;.align-left_img]:my-0 [&amp;.align-left_img]:mr-[2em] [&amp;.align-right_img]:my-0 [&amp;.align-right_img]:ml-[2em]\">\n<div class=\"field field--name-field-media-image field--type-image field--label-visually_hidden\">\n<div class=\"field__label visually-hidden\">Image</div>\n<div class=\"field__item\"> <img alt=\"Ai Checklist\" height=\"363\" loading=\"lazy\" sizes=\"(min-width: 1280px) 450px, (min-width: 1024px) 400px, (min-width: 768px) 94vw, (min-width: 640px) 94vw, 100vw\" src=\"/sites/default/files/styles/max_500x500/public/2025-02/ai-checklist.png.webp?itok=8qVGsy5Q\" srcset=\"/sites/default/files/styles/max_325x325/public/2025-02/ai-checklist.png.webp?itok=HE-onpz9 325w, /sites/default/files/styles/max_400x400/public/2025-02/ai-checklist.png.webp?itok=4OT-Sj0C 400w, /sites/default/files/styles/max_904x904/public/2025-02/ai-checklist.png.webp?itok=Veh4--uw 589w\" width=\"500\">\n</img></div>\n</div>\n</article>\n</div>\n</div>\n<div class=\"wysiwyg-cta-card-content p-8 flex flex-col grow gap-2 justify-center\">\n<div class=\"wysiwyg-cta-card-eyebrow text-primary-innovative-pink text-sm font-medium leading-150 field field--name-field-cta-card-eyebrow field--type-string field--label-hidden field__item\">Playbook</div>\n<div class=\"wysiwyg-cta-card-headline h4 group-[.dark-bg]/c:text-white field field--name-field-cta-card-headline field--type-string field--label-hidden field__item\">Security for AI: Readiness and Risk Playbook</div>\n<div class=\"wysiwyg-cta-card-link-text flex flex-row items-center gap-1 text-sm font-medium leading-140 text-blue-black-100 after:content-icon-cta-secondary after:block after:leading-none after:w-3 after:h-3 group-[.dark-bg]/c:text-white\">\n          Download the playbook\n        </div>\n</div>\n</a>\n</div>\n</p><h2 dir=\"ltr\">The Seven Methods and What Each One Catches</h2><p dir=\"ltr\">HackerOne’s survey asked security leaders which AI security testing methods they currently use, and the answers are clear. Here they are, along with the percentage of security leaders that picked them.</p>\n<article class=\"media media--type-image media--view-mode-media-embed-default [&amp;.align-center_img]:mx-auto [&amp;.align-left_img]:my-0 [&amp;.align-left_img]:mr-[2em] [&amp;.align-right_img]:my-0 [&amp;.align-right_img]:ml-[2em]\">\n<div class=\"field field--name-field-media-image field--type-image field--label-visually_hidden\">\n<div class=\"field__label visually-hidden\">Image</div>\n<div class=\"field__item\"> <img alt=\"Seven Methods Used by Organizations to Safeguard AI Systems\" height=\"676\" loading=\"lazy\" sizes=\"(min-width: 1280px) 1200px, (min-width: 1024px) 904px, (min-width: 768px) 700px, (min-width: 640px) 600px, 100vw\" src=\"/sites/default/files/styles/max_1200x1200/public/2026-04/AI-Security-Chart-1.png.webp?itok=zo4JZZwH\" srcset=\"/sites/default/files/styles/max_400x400/public/2026-04/AI-Security-Chart-1.png.webp?itok=gsDB_wCr 400w, /sites/default/files/styles/max_600x600/public/2026-04/AI-Security-Chart-1.png.webp?itok=SoIR0YAU 600w, /sites/default/files/styles/max_700x700/public/2026-04/AI-Security-Chart-1.png.webp?itok=7GJNU2zC 700w, /sites/default/files/styles/max_800x800/public/2026-04/AI-Security-Chart-1.png.webp?itok=81IzMvvF 800w, /sites/default/files/styles/max_904x904/public/2026-04/AI-Security-Chart-1.png.webp?itok=eVU-KUq_ 904w, /sites/default/files/styles/max_1200x1200/public/2026-04/AI-Security-Chart-1.png.webp?itok=zo4JZZwH 1200w, /sites/default/files/styles/max_2400x2400/public/2026-04/AI-Security-Chart-1.png.webp?itok=etgN_Yb6 1278w\" width=\"1200\"/>\n</div>\n</div>\n</article>\n<p dir=\"ltr\">Those percentages are interesting, but what is more useful is what these methods do when combined. Together, these seven methods form continuous security testing for AI: different signals, one operating loop.</p><ol><li aria-level=\"1\" data-list-item-id=\"ef28e530f131b427328d75d38df3b2058\" dir=\"ltr\"><a href=\"https://www.hackerone.com/product/ai-red-teaming\"><strong>AI red teaming</strong></a> is targeted, scenario-driven adversarial testing that simulates real-world attacker behavior against models, agents, or pipelines. It is designed to uncover failure modes that do not show up in normal evaluation, including prompt injection paths, jailbreaks, tool misuse, and multi-step exploit chains across connected systems.</li><li aria-level=\"1\" data-list-item-id=\"ed1595f5b43b117d4fcbfffe9871e9e73\" dir=\"ltr\"><a href=\"https://www.hackerone.com/solutions/adversarial-exposure-validation\"><strong>Automated adversarial testing tools</strong></a> give you breadth and repeatability. They are how you scale adversarial probing across many prompts, languages, policies, and attack patterns, and they are especially valuable for regression testing after changes to prompts, models, tools, or policies. </li><li aria-level=\"1\" data-list-item-id=\"e3b75b071cf726456e260629cb5412576\" dir=\"ltr\"><strong>Model security scanning</strong> is the “known weakness detection” layer for your ML stack: configurations, dependencies, containers, endpoints, and unsafe defaults. It is fast, systematic, and good at preventing avoidable basics from shipping, particularly in the complex dependency chains that modern AI applications tend to inherit.</li><li aria-level=\"1\" data-list-item-id=\"e3ecd4d03a4c8e09a2586f969e3646f24\" dir=\"ltr\"><strong>Agent oversight and guardrail tools</strong> exist because agents can take actions. Oversight constrains permissions, tool access, and action boundaries, reducing blast radius when the model is manipulated, overconfident, or simply wrong. In a world where 78% of organizations report AI agents in production, guardrails are quickly becoming table stakes, but they are not a replacement for testing. They are your runtime seatbelt.</li><li aria-level=\"1\" data-list-item-id=\"e076af35011a5f3fd0abb7129bacab44c\" dir=\"ltr\"><strong>AI system monitoring</strong> is your real-world safety net: monitoring prompts, tool calls, outputs, and anomalies so you can detect abuse patterns and drift after deployment. In a CTEM-style operating model, monitoring is part of the continuous feedback loop that tells you where to focus the next round of validation and hardening.</li><li aria-level=\"1\" data-list-item-id=\"eec137d7ada5b74e1e52f11b7182d6e0f\" dir=\"ltr\"><strong>External AI-focused security testing</strong> provides independent validation and specialized expertise. It is especially valuable for high-stakes launches, regulated contexts, and scenario coverage you do not have time to build internally. In HackerOne’s survey, 54% of security leaders said they plan to begin using external AI-focused security testing over the next 12 months, which is a strong indicator that many organizations see external validation as the fastest way to close the AI security gap.</li><li aria-level=\"1\" data-list-item-id=\"e266227603b1bc88b7a9e87d59f19843d\" dir=\"ltr\"><a href=\"https://www.hackerone.com/product/bug-bounty-platform\"><strong>Bug bounty</strong></a><strong> or crowdsourced AI testing</strong> brings scale, diversity, and long-tail creativity over time. A researcher community will find edge cases and exploit chains that smaller, time-boxed teams miss, particularly as attacker tactics evolve. This is one reason bug bounty programs are often framed as continuous researcher-led testing rather than a single exercise.</li></ol><p dir=\"ltr\">To a security leader who is already overwhelmed by the onslaught of AI, this list is going to feel like “a lot”, but that is the point. Each method exists because the others have blind spots. Red teaming is deep but time-boxed. Automated adversarial testing is broad but not always context-aware. Scanning is fast but focuses on known issues. Guardrails help at runtime but can be bypassed or misconfigured. Monitoring tells you what is happening, not necessarily how to fix it. External testing adds independence, not continuity. Bug bounty adds continuity and diversity, but it needs clear scope, triage, and remediation workflows to convert reports into risk reduction.</p><p dir=\"ltr\">Combining all seven provides the best coverage.</p><h2 dir=\"ltr\">How to Stitch Seven Methods Into One Continuous Program</h2><p dir=\"ltr\">The biggest mistake I see teams make is treating these methods as separate procurement decisions. The better mental model is to treat them as a single system, where each method creates signal, and that signal flows into a single source for prioritization and remediation.</p><p dir=\"ltr\">A practical way to visualize the “continuous security testing” program is as three connected loops: pre-release prevention, pre-release adversarial validation, and post-release continuous discovery.</p><ul class=\"checkmark-list\"><li aria-level=\"1\" data-list-item-id=\"e1a06d7e29c2400db162314e3d9eb9b35\" dir=\"ltr\">In the <strong>prevention</strong> loop, model and stack scanning catches preventable issues early, before they become incidents. It is your baseline hygiene layer.</li><li aria-level=\"1\" data-list-item-id=\"e47fb151de8bfcb07de8af3901b0bda10\" dir=\"ltr\">In the <strong>adversarial validation</strong> loop, automated adversarial testing and AI red teaming pressure-test behavior and orchestration, with external testing providing independent scrutiny when the stakes are high or internal capacity is stretched. This is where you test the parts of AI that do not have fixed execution paths, and where you learn what “real exploitation” looks like in your specific architecture.</li><li aria-level=\"1\" data-list-item-id=\"ea529ed87607212a2e6170be2dca945e3\" dir=\"ltr\">In the <strong>post-release</strong> loop, monitoring plus crowdsourced testing create the continuous pressure you cannot simulate fully in a lab. Monitoring helps you spot emergent patterns and drift. Bug bounty helps you learn what creative attackers can do over time, across languages, threat models, and unexpected interaction patterns.</li></ul><p dir=\"ltr\">What makes this “one program” rather than “seven activities” is how each activity provides feedback to the others. A monitoring alert should become a new red team scenario. A bug bounty report should become a regression test in your automated adversarial suite. A red team exploit chain should become a guardrail improvement plus a detection. A scanning finding should become a build-time gate. That is the continuous motion: every signal becomes a test, a control improvement, and ideally a measurable reduction in exploitable exposure. </p><h2 dir=\"ltr\">A Note on Ownership</h2><p dir=\"ltr\">A slightly counterintuitive insight from the research is that ownership is necessary but not sufficient. The study reports broad formal ownership for offensive security of AI systems, often involving a mix of internal security teams, internal AI or MLOps teams, and external providers. Yet attacks remain widespread and costly. In other words, having “a team responsible” does not automatically translate into continuous, end-to-end security coverage. The operational loop is what converts ownership into outcomes.</p><p dir=\"ltr\">If you are looking for a pragmatic way to sequence this, do not try to “do everything at once” in a vague way. Instead, align the sequence to what you are actually deploying. For example, if your AI deployments are mostly embedded features in existing SaaS workflows, start by treating the AI layer as an extension of application security: scan the stack, pentest the end-to-end app and integrations, validate prompt and interaction pathways, and make sure monitoring is instrumented in production. </p><p dir=\"ltr\">For agentic systems, you might instead prioritize guardrails, tool boundary validation, and red team scenarios that reflect what the agent can actually do. Keep in mind that the more autonomy you ship, the more your security program needs to validate behavior, rather than just static code.</p><h2 dir=\"ltr\">What CISOs Should Take Away From the Data</h2><p dir=\"ltr\">Let’s bring it back to the simplest leadership question: what should you do differently on Monday? The survey data suggests three moves that are both practical and hard to argue with.</p><ul><li aria-level=\"1\" data-list-item-id=\"e53aa736aef0f3b310f7a3d6cc5dbc810\" dir=\"ltr\"><strong>First, close the coverage gap.</strong> If AI adoption growth outpaces formal testing, you're effectively leaving a huge gap in the attack surface.</li><li aria-level=\"1\" data-list-item-id=\"e55f9aed3f8730d41bd9a990f35605d6f\" dir=\"ltr\"><strong>Second, treat AI security as multi-layer.</strong> The most commonly reported AI attacks and vulnerabilities spanned infrastructure weaknesses, model behavior failures, and prompt and interaction attacks. There's no single tool or process that will fill the gap. There needs to be new multi-layered processes to effectively handle the change.</li><li aria-level=\"1\" data-list-item-id=\"ebf5dd6cbc3772cde40a39a09e7513e6c\" dir=\"ltr\"><strong>Third, operationalize continuity.</strong> Whether you call it continuous security across the AI lifecycle or CTEM, security must become a constant loop of discovery, validation, prioritization, and remediation.</li></ul><p dir=\"ltr\">On Monday, start by defining what continuous security testing means for your AI footprint, then assign ownership for the loop, not just the tools.</p><p dir=\"ltr\"><a class=\"cta-primary-wysiwyg\" href=\"https://www.hackerone.com/solutions/continuous-security-testing\">Validate Risk Continuously, Not Periodically</a></p>",
  "hero_image": "https://www.hackerone.com/sites/default/files/styles/og_image/public/2026-04/Some-CISOs-Feel-Prepared-for-AI%2C-Some-Don%27t-Here%27s-the-Difference-Header.png.jpg?itok=cuXlzlmW",
  "listing_image": "https://www.hackerone.com/sites/default/files/styles/max_500x500/public/2026-04/Some-CISOs-Feel-Prepared-for-AI%2C-Some-Don%27t-Here%27s-the-Difference-Header.png.webp?itok=CXQQNHpT",
  "listing_solutions": [],
  "listing_topics": [
    "AI",
    "Exposure Management"
  ],
  "modified_time": null,
  "taxonomy": {
    "blog_topic": [
      "AI",
      "Exposure Management"
    ]
  }
}