- ARPSyndicate published Suricata and Nuclei rules for 12,466 CVEs, most generated autonomously by its VEDAS system and, in most cases, validated only for syntax.
- AI makes detection content cheap to write. Trusting it still takes human review and testing, which the project says it needs from the community.
- Before deploying any such rule, test it in your own environment and ask vendors what testing sits behind their AI-made content.
Writing a detection rule used to be slow, skilled work. The rule was the scarce thing. A new public repository suggests the scarce thing is now trust in the rule.
What ARPSyndicate published
ARPSyndicate has released vedas-signatures on GitHub. The README is dated October 5. The repository holds detection content for 12,466 unique CVEs. Each CVE gets two files: a Suricata rule and a Nuclei template.
Most of these are generated autonomously by VEDAS, ARPSyndicate's system for aggregating vulnerability and exploit intelligence. The project says AI lets it create detection content "quickly and at scale". It then asks the community to review, validate, fix and extend the content through issues and pull requests.
How the two rule types work
Suricata is a network engine. Its rules watch traffic for patterns that look like an attempt to exploit a flaw. The repository describes these as network detection of exploitation attempts.
Nuclei works the other way round. Its templates send requests to a system to check whether it is exposed to a CVE. The project calls these active, non-destructive checks. It also warns users to scan only systems they are authorised to test.
The project says every proof-of-concept payload a check needs is stored in the repository's payloads folder. Nothing depends on a third-party host, which suits on-premises networks.
Checked for form, not for truth
The README is candid about limits. Signatures generated by VEDAS are "syntactically validated only". It adds that logical testing "has not been performed in most cases".
A spell-checker is a fair comparison. It confirms every word exists. It cannot tell you the sentence is true. A rule that loads cleanly in Suricata has passed the spell-check.
Pull requests get automatic checks too. A rule must load in real Suricata and Nuclei engines and pass the repository's lint. The target CVE must exist on cve.org. These checks confirm the file is well-formed and the CVE is real. The README does not list testing against live exploit traffic.
The idea: AI moves the bottleneck
This is the pattern worth seeing. AI collapses the cost of producing security content. It does not collapse the cost of knowing the content works. The work shifts from writing to verifying.
That shift matters for anyone who relies on detection. A rule that never fires looks the same as a network with no attacks. A rule that fires too often wastes an analyst's night. Neither fault shows up in a syntax check. This is our interpretation, not a finding of the report.
To its credit, the project says this itself. It says reliable detection needs "transparency, human review and real-world testing". It publishes the content in the open so others can supply that testing.
What to ask your team
Treat the feed as a draft, not a control. The project asks users to validate every signature in their own environment before deploying it. It provides the content as-is, without warranty.
Four questions put that advice to work:
First, who owns validation before a rule goes live, and what counts as passing? Second, can your tools tell VEDAS rules from others? The README reserves SIDs 1000000-1999999 for VEDAS and 3000000-3999999 for the community, and neither range overlaps ET Open. Third, who has authorised the Nuclei scans, and against which systems? Fourth, what testing sits behind AI-generated content from your other vendors?
Cheap to write is not the same as safe to trust.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: github.com.
