A scanner is only as good as the record it read
Vulnerability data is the input to every security decision an engineering team makes, and it is the part nobody owns. NVD enrichment slowed to a crawl and never recovered. CVE records ship without affected versions, without a fix, sometimes without a working reference. Vendors publish advisories that contradict the registries. Scanners inherit all of it and hand the mess to a developer who has forty minutes.
This was never good. It is measurably worse now. Every tool downstream is limited by it. An unenriched advisory gives a scanner an empty affected list, a null fix version and a dead reference, which leaves three options and all three are bad: flag every version and produce a queue nobody reads, flag none and carry silent risk, or guess from the description text and do both unpredictably.
Reconcile it, correct it, then publish it
Vulnetix aggregates 160 vulnerability sources, reconciles them against package registries, distribution advisories and upstream commits, and publishes the result as data anyone can query. Where a record is wrong, we correct it and say what we corrected. Where a fix version exists that no advisory names, we find it. Where a CVE has no patch, we ship the detection rule instead.
None of that is a feature we can hold back for a pricing tier. It is the substrate. A platform built on bad records produces confident, wrong answers faster. Explore the VDB or read every source we ingest.
Your data has to outlive your vendor
Every artefact Vulnetix produces is a standard file: CycloneDX and SPDX for inventory, SARIF for findings, OpenVEX for exception decisions, STIX for indicators. You can take them to a competitor tomorrow. That is deliberate. A workflow that survives on open files is a workflow you own, and a vendor that needs lock-in to keep you is telling you something about the product.
We take this far enough to write specifications. Cloud Resource Identifier Templates is an active IETF draft, draft-vulnetix-crit-02, because the question of which cloud resources a CVE actually affects has no standard answer and every vendor was inventing a private one.
- CycloneDX (OWASP / ECMA-424): inventory, plus the AI-BOM and CBOM variants
- SPDX (ISO/IEC 5962): inventory and licence disclosure
- SARIF (OASIS): findings, in and out, from any scanner
- OpenVEX (OpenSSF): exception decisions, minted when your team triages
- STIX 2.1 (OASIS): malware indicators for SIEM, CTI and EDR
- CRIT (IETF draft-vulnetix-crit-02): which cloud resources a CVE actually affects
Building the tools was never the hard part
The industry sells 15 categories of AppSec tool and a licence for each: SAST, SCA, DAST, MAST, container scanning, cloud security, IaC, secret scanning, network scanners, linters, SBOM generation, compliance engines, licence compliance, fuzzing and pentest platforms. We ship one binary under AGPL-3.0 that covers most of them, through vulnetix sca, sast, secrets, containers, iac, license, malscan, aibom, cbom and scan. No seat count, no licence key.
That was never the difficult bit. The difference between a tool that finds things and a tool that only produces false negatives was always the data underneath it, and as CVE quality declines that gap widens every quarter. Anyone can run the scanner against anything today without talking to us. What we sell is the intelligence it queries and the platform that keeps the answers current.
We would rather the whole field improve
Free means free. The Community tier is rate-limited, not trial-limited. It does not expire and it does not ask for a card. The code scanner is AGPL-3.0, the SSVC SDKs are MIT, the agent plugin is Apache-2.0, and the malware STIX feeds are public files with checksums beside them.
Better data as a component. Most security vendors are downstream of the same broken feeds we are. Rather than compete on who cleans them privately, we license the corrected data as a drop-in component. A scanner that ships better answers because it consumes better data is a win we are happy to fund.
Specifications, not moats. CRIT went to the IETF rather than into our schema. Our rule packs are OPA and Rego, readable by anything that speaks them. When we needed a format that did not exist, we wrote it down in public so the next tool can implement it too.
The goal is a field where this argument stops happening
Where an affected-version range is correct because correct is the default, not because someone paid for it. Vulnetix intends to be the reference other tools check against, and then intends for that to be unremarkable.