Enhanced Detection Engineering at Scale in the Agentic Era

Resolving detection coverage gaps is a universal problem across the security industry. Before joining GreyNoise, I led Elastic’s Endpoint Protections security research team which was tasked with building visibility and detection capabilities in their Endpoint Detection and Response (EDR) solution. Researchers, red teamers, and attackers alike would constantly poke, prod, and reverse engineer our EDR’s detection capabilities then broadcast their evasions and bypasses to the masses. However, I always saw this as a unique challenge; iron sharpens iron, after all, and resolving these issues led to an improved product with expanded coverage. I believe this experience suits me well as I transition into my new role as the Head of Adversary Engagement at GreyNoise and lead our detection and deception engineering efforts.

‍

Generative AI’s Impact on CVE Reporting

When GreyNoise was founded in 2018, 16,510 entries were added to the Common Vulnerabilities and Exposures (CVE) system. The number of entries (48,162) added in 2025 shot up to almost triple the number from 2018. Part of this astounding increase in CVEs can be attributed to the sharp rise in the number of CVE Numbering Authorities over the last decade from 23 in 2016 to over 500 by 2026. However, generative AI has had an undeniable impact on the annual number of reported CVEs over the past few years (130% growth from 2022 through 2025) which speaks to an existential crisis currently facing the security industry.

Large language models (LLMs) have lowered the barrier of entry for aspiring vulnerability researchers and exploit developers while significantly enhancing the capabilities of more experienced researchers and attackers. The mean time to exploit CVEs has sharply dropped to the point where it is now slightly negative, meaning that the average vulnerability was likely exploited in the wild before it was reported and assigned a CVE number.

In the face of impactful vulnerabilities and exploits popping up at rates faster than ever, we saw a critical need to revise our approach to threat detection. Our goals are the following:

• Counteract CVEs by rapidly producing and deploying high efficacy GreyNoise Tags which have been evaluated against an extensive store of recent packet capture data collected from sensors operating on the GreyNoise Global Observation Grid (GOG).
• Constantly evaluate and revise our tag corpus as needed to ensure accuracy and resilience against false positives.
• Expand the GOG beyond the edge and build the infrastructure to support Deception Sensor coverage of a wider range of hardware and software platforms.
• Coerce higher quality interaction with attackers through robust Deception Sensors spanning across multiple resources, which will provide deeper insight into more complex behavior and allow us to deploy tags across all stages of MITRE ATT&CK.
• Proactively hunt for high confidence signs of previously unknown threats and deploy tags where appropriate.

This article will primarily focus on the first item above, with subsequent articles to come in the following months to highlight the other facets of our evolved threat detection approach.

‍

Traditional Detection Engineering

The typical workflow for a detection engineer after CVE publication may resemble the following:

• Review the CVE summary and any provided references.
• Determine whether or not we have the infrastructure in place to capture exploitation of this vulnerability. If we do not, then we will need to research the relevant platform(s) and build new Deception Sensors before we push out tags.
• Determine the likelihood of exploitation and potential for critical impact to our users.
• Read any reputable research blogs or vulnerability write-ups (if available).
• Locate and analyze relevant PoC exploit code (if available).
• Reverse engineer the vendor patch (if available) and associated binaries or source (if available) to gather further context around the vulnerability and how it may be exploited.
• Query the GreyNoise dataset for previous reconnaissance and / or exploitation from non-benign entities based on gathered indicators.
• Craft detection logic which captures associated activity while taking extensive measures to ensure resilience against false positives.
• Build a GreyNoise Tag, including all relevant metadata and references, and deploy to production.
• Confirm that relevant Deception Sensors are actively deployed in the GOG to ensure proper data capture.
• Tune the detection logic at a later point if data volumes become a concern or CVE is trending and we need to refine our detection logic.

As you can see, this is a lot of effort for a lone detection engineer to undertake even for a single CVE. With annual CVE additions on track to hit the hundreds of thousands starting in 2027, it is simply not feasible to continue down this path and provide accurate, up to date intelligence on the most critical emerging threats to our users. Evolving our approach is essential to keep pace with a rapidly shifting threat landscape.

‍

Enhanced Detection Engineering

Allocating the research and development resources required to design, implement, and refine an efficient pipeline accelerated by agentic workflows is a necessary first step towards proactive threat detection at scale. We aim to leverage frontier large language models to reduce friction and remove onerous mental load bottlenecks for our detection engineers, which will allow us to focus on refining detection logic for the most pervasive threats and quickly provide accurate intelligence to our customers.

Agentic workflows will be critical to delivering real world impact in our revised approach to detection engineering. Agents are currently being designed and implemented to carry out the following tasks for a given CVE:

• Pull down the CVE summary, associated metadata, and ingest data from each linked reference
• Assess the CVE’s criticality (e.g. CVSS, KEV, operational impact) and whether or not we currently are capable of capturing exploitation
• Locate and analyze references from trusted third party sources (e.g. vulnerability write-ups, exploit PoC code, patches, firmware samples)
• Assess the objective quality of all ingested data and determine if sufficient context can be derived to proceed with drafting detection logic
  
  • If the data is currently lacking, this CVE will be inserted into a queue for re-assessment in the near future
• Assuming the ingested data exceeds a predetermined quality threshold, an agent will proceed to build a packet query to filter through GreyNoise’s data to identify any recently observed relevant activity, with measures taken to reduce the likelihood of false positives
• Refined detection logic will then be drafted by an agent which reflects both the key indicators derived from earlier research data ingestion as well as analysis of GreyNoise operational data

‍

At this point, our detection engineers will step in to review the draft detection logic and a detailed summary of all tasks the agents carried out along with key indicators associated with exploitation of the given vulnerability. If further refinement of detection logic is needed, changes can be made at this point and reevaluated against our data to ensure sustained precision.

After a GreyNoise Tag is published, agents will continue to monitor for additional references to collect which may be relevant to a given CVE. These periodic collection tasks will similarly assess the quality and relevance of the data and determine whether it is additive in nature and thus necessitate further revision of our detection logic. Proposed tag updates will be drafted and our detection engineers will be notified for further review and to determine if an update needs to be published.

‍

Moving Forward

This is the first step in a bold new direction for GreyNoise and our capability to assess and detect the most pervasive and critical threats. We look forward to sharing more with you in the coming months!

‍