Composition analysis
Every other scanner needs your source code.
Cidra needs a spreadsheet. Upload the products and versions you run and it resolves each one, matches package identities with OSV and ranks findings with KEV and EPSS. Products no active source can answer stay visibly unanswered rather than reading clean.
What goes in
CSV and TSV
Any column names. The parser infers the schema and shows you what it inferred.
CycloneDX
JSON. Nested assemblies flattened, the SBOM's own subject excluded.
SPDX
JSON. PURLs and CPEs read from externalRefs, NOASSERTION handled.
PURL or CPE
A file of identifiers is a complete inventory — each carries its own version.
Where version matching goes wrong
False positives in this category are not bad luck. They come from three specific places, and each has a specific fix.
Ecosystem ordering
1.0~rc1 < 1.0 in RPM. 1-foo > 1 in Maven. 1.0.2k > 1.0.2 but 9.0.0-M1 < 9.0.0. Cidra ports rpmvercmp, dpkg and Maven ComparableVersion and tests against their own published vectors.
Backported fixes
A distro build keeps the upstream version string after the fix is applied. Cidra defers to the vendor advisory for distro components, so the patch is seen.
Unreachable code
A VEX statement saying the vulnerable path is not in your execute path suppresses the match before a finding is raised, not after it has already reached someone's queue.
And when it cannot decide
It says so. A version that cannot be ordered against a published range is marked indeterminate and routed to a person. A product no source recognises is listed explicitly. A blind spot presented as a clean result is the most dangerous output a security tool can produce.
Questions
What file formats can I upload?
CSV and TSV with any column names, CycloneDX JSON, SPDX JSON, and files containing only a PURL or CPE column. The CSV parser infers which column holds the product, version, vendor and host, reports the confidence of each inference, and lets you correct it before the scan runs.
What happens to rows the parser cannot read?
They are recorded with the reason — no product name in any recognised column, or no version found — rather than dropped. The count appears in the scan summary so you always know how much of your upload was actually assessed.
Why do other tools report vulnerabilities in patched Red Hat packages?
Because they compare against the upstream range. Red Hat backported the fix for CVE-2023-0286 into openssl-1.1.1k-12.el8_9, but the version string still reads 1.1.1k, so an upstream check that says 'fixed in 1.1.1t' flags it. Cidra prefers the vendor's own advisory for distro-packaged components, so a patched build reads as patched.