vedas-signatures publishes autonomously generated Suricata rules and Nuclei templates covering thousands of CVEs, offered for authorized detection engineering and validation work.

vedas-signatures is less a traditional tool than a detection-content factory with an open review floor. The repository, maintained under the ARPSyndicate organization, aggregates CVE detection signatures — Suricata rules for network-side detection of exploitation attempts and Nuclei templates for active, non-destructive exposure checks — with the bulk of the content generated autonomously by the Vulnerability & Exploit Data Aggregation System, or VEDAS. The interesting design decision is that the project treats AI generation as a starting point rather than a deliverable: everything is published openly precisely because the maintainers acknowledge that machine-generated detection logic needs human review and real-world testing before it can be trusted.

The scale is the first thing that stands out in the README. At the time of writing the repository claims 13,672 unique CVEs covered, with most CVEs carrying both a Suricata rule and a Nuclei template. The per-year coverage table spans 1999 through 2026, and its shape tells a story about vulnerability disclosure itself: thin in the late nineties, peaking around 2006 through 2008 with roughly 1,100 to 1,750 CVEs per year, dipping through the 2010s, and then climbing again from 2021 onward with 676 to 767 CVEs per year in recent counts. The fact that 2026 already shows 449 covered CVEs indicates the generation pipeline is actively tracking current disclosure rather than backfilling history.

One nuance in the coverage model deserves attention: 161 CVEs classified as destructive or denial-of-service issues are network-detection-only. These get a passive Suricata rule but no active Nuclei check, precisely because actively probing for a DoS condition is itself harmful. The README lists them in SURICATA_ONLY.txt, which is a thoughtful safety partition — it lets defenders detect exploitation of these issues on their own networks without handing anyone a convenient way to knock over someone else's systems. This is the kind of editorial gatekeeping you want to see in detection content, and it signals the maintainers have thought about the dual-use nature of their templates.

The repository layout is deliberately simple and scriptable. Suricata content lives in suricata//CVE-YYYY-NNNNN.rules, one file per CVE with one rule per line, where is the CVE year rather than the year the signature was written — a small detail that avoids ambiguity when you are diffing coverage across years. Nuclei templates follow the parallel convention nuclei//CVE-YYYY-NNNNN.yaml. A payloads/ directory holds self-hosted PoC payloads in formats like SVG, DTD, and CSV, so that active checks do not depend on any third-party host — the README explicitly frames this as on-prem friendly. The scripts/ directory contains the validation tooling that CI runs, and the maintainers encourage running it locally too.

Deployment on the Suricata side is straightforward. The README suggests concatenating the ruleset and test-loading it before going live, tested against Suricata 8.x: cat suricata/*/*.rules > vedas.rules followed by suricata -T -c /etc/suricata/suricata.yaml -S vedas.rules. Alternatively you can add the directory to the rule-files: stanza in suricata.yaml. The SID allocation is documented and collision-aware: VEDAS-generated rules use the 1000000-1999999 range, community contributions use 3000000-3999999, and neither overlaps ET Open — a practical courtesy for anyone already running the Emerging Threats ruleset alongside this content.

On the active side, the templates are built for Nuclei v3 and can be pointed at a target with nuclei -t nuclei/ -u https://target.example, with the README closing that section with an explicit instruction to only scan systems you are authorized to test. For a defender, the more interesting operational use is inverted: these templates double as a validation harness for your own detection stack. Running the template against a lab instance of a vulnerable product while watching your Suricata sensor lets you confirm both halves of the detection pair fire on the same behavior — template and rule are keyed to the same CVE, which makes them natural bookends for detection testing.

The contribution workflow is where the project's quality model actually lives. GitHub issue forms are templated per failure mode: false positives (a rule firing on benign traffic), false negatives (a rule missing real exploitation), broken signatures (rules that fail to load or perform poorly), and signature requests for uncovered CVEs. Every pull request is gated by automated checks that require the content to load in real Suricata and Nuclei engines, pass repository lint, and reference a CVE that actually exists on cve.org. Contributors are credited in each template's info.author field and in the pull-request history, which gives you a paper trail for distinguishing community-reviewed signatures from raw VEDAS output.

That distinction matters because of the disclaimer, which is unusually candid for this space. VEDAS-generated signatures are, in the maintainers' own words, syntactically validated only — logical testing has not been performed in most cases, and the README instructs users to validate every signature in their own environment before deployment. For a detection engineer, this reframes the repository from a drop-in feed into a raw material source. The prudent workflow is to treat it as a candidate pool: pull coverage for CVEs relevant to your asset inventory, regression-test rules against known-benign traffic samples, watch for the false-positive patterns the issue tracker is designed to capture, and feed findings back upstream so the community review layer compounds over time.

The provenance story is also worth reading closely. VEDAS aggregates openly available intelligence — vulnerability databases, advisories, exploit and PoC publications, existing detection rulesets, and research from vendors, CERTs, and independent researchers. Where detection logic was adapted from openly licensed projects, notably projectdiscovery/nuclei-templates under MIT, it is credited in the NOTICE file. This is good hygiene in a domain where ruleset licensing disputes are common, and it means the content is auditable if you need to justify its use in a compliance-sensitive environment.

From a defensive telemetry perspective, the two content types behave very differently. Suricata rules are passive — they inspect traffic already crossing your sensor and generate alerts without touching the endpoint, so their operational footprint is limited to alert volume and sensor load. Nuclei templates are active probes that generate distinct request patterns against whatever you point them at; when used in authorized internal validation, those patterns are themselves useful signal, since your own IDS should flag the scans and confirm end-to-end coverage. Blue teams running periodic authorized scans with these templates against their own lab mirrors get a two-for-one: exposure measurement and a live test of whether the corresponding network detections actually fire.

The repository's CI badges for both suricata.yml and nuclei.yml workflows, its SECURITY.md guidance to report tooling vulnerabilities privately, and its CONTRIBUTING.md with local validation instructions all point to a project that is run as infrastructure rather than a dump of generated content. At roughly 20 stars it is early in its community lifecycle, but the automated validation gates, the destructive-CVE exclusion list, and the honest disclaimer about logical testing give it a credibility structure that many larger feeds lack. For authorized detection engineers looking to extend CVE coverage quickly — with the professional obligation to validate before deployment — this is a repository worth monitoring and, if you run the checks, worth contributing back to.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• Snitch for real-time local network traffic visualization


• Inside splitting-the-email-atom: probing email parser discrepancies to test access controls


• H2SpaceX: low-level Scapy toolkit for HTTP/2 single packet research