CidraOpen the platform

Composition analysis · Exploit evidence · Explainable triage

Know what you run.
Know what needs attention today.

Upload the software you run and its versions. Cidra resolves every product, matches packages with OSV, and ranks findings with CISA KEV and FIRST EPSS evidence — not by severity alone. No agent. No repository access. No integration.

CSV, XLSX, CycloneDX and SPDX accepted. First result in about a minute.

3
operational inputs: OSV applicability, CISA KEV and FIRST EPSS
29,000
CVEs NIST will never enrich — and NVD-only tools will never see
6
version schemes compared natively: semver, PEP 440, Maven, RPM, deb, CPE
100%
concordance with OSV's own version filtering on the validation set

01 — The estate

Most of what you run, you did not write.

Appliances, vendor applications, firmware, licensed platforms. No repository to scan, no agent to install, and no reliable list of which version is actually deployed.

02 — Resolution

Every product, correctly named.

A cascade of decreasing certainty resolves each row to a CPE or PURL identity — and stops to ask when two candidates are too close to call, rather than guessing.

03 — What is actually exploitable

Thousands of components. A handful that matter this week.

Ranked by what is being exploited right now and what is likely to be next, not by severity alone. Every score shows the arithmetic behind it.

Every other tool needs your source code.

Software composition analysis assumes you can reach the repository. But most of what a bank or a hospital runs is software it did not write and cannot instrument — appliances, vendor applications, firmware, licensed platforms. For that estate the only honest input is a list of products and versions, and almost nobody serves it well.

The identity problem

The same product arrives as Apache Tomcat 9.0.65, tomcat9 9.0.65-1ubuntu0.1 and Tomcat(R) 9.0.65 [x64]. Two identifier systems exist — CPE and PURL — and neither covers everything.

The enrichment collapse

NIST stopped universally enriching CVEs in April 2026. Tens of thousands of records will never receive the applicability data that version matching needs. A product that says we compare against NVD now misses them silently.

The ranking problem

A CVSS 9.8 with a 0.04% exploit probability and no KEV entry is less urgent than a KEV-listed 7.5. Sorting by severity is how teams end up patching the wrong thing for a quarter.

Upload to answer, in five stages.

One pipeline. The same code runs whether a scan starts from the browser or from cron, because two paths that disagree are two paths nobody trusts.

  1. 01

    Parse

    Column roles inferred from any header, or read natively from CycloneDX and SPDX.

    CSV · XLSX · CycloneDX · SPDX
  2. 02

    Resolve

    Each row becomes a CPE or PURL identity, with a confidence value attached.

    6 resolution methods
  3. 03

    Match

    Version ranges evaluated per ecosystem. VEX and vendor backports applied first.

    6 version schemes
  4. 04

    Prioritise

    KEV, EPSS, exposure and asset tier produce a decision band and an SLA clock.

    act · attend · track
  5. 05

    Report

    One record feeds the ticket, the evidence pack and the board summary.

    no re-authoring

It tells you how sure it is.

Identity resolution is the part that has to make a judgement, and a wrong judgement is either a false positive that erodes trust or a false negative that misses a real exploit. So every answer carries a confidence value, and below the line it stops.

1.00A supplied PURL or CPETaken at face value.auto
0.95Constructed from ecosystemWe built it; slightly less certain.auto
0.92An alias someone confirmedNever asked twice.auto
0.97Exact CPE, vendor agreesAs certain as CPE gets.auto
0.88Exact CPE, no vendorNames collide across vendors.auto
0.71Best fuzzy candidateAccepted only if the runner-up is far behind.review
0.50Two candidates too closeRefuses to guess. Asks a person.review

The threshold is 0.85, and clearing it is not enough on its own — a candidate is only accepted when the runner-up is at least 0.10 behind. Two near-equal candidates mean the input is genuinely ambiguous, and picking one is how a plausible-but-wrong finding gets created.

The bug that makes other scanners cry wolf.

Distributions backport security fixes without changing the upstream version string. Check against the upstream range and every patched long-term-support machine in the estate lights up red.

CVE-2023-0286 · openssl on RHEL 8
What upstream ranges say
introduced1.1.1
fixed1.1.1t
installed 1.1.1k-12.el8_9
AFFECTED — and wrong

The version string still reads 1.1.1k, so any check against the upstream range flags it. This is why other tools light up every long-term-support box in the estate.

What the vendor advisory says
introduced1.1.1k-1.el8
fixed1.1.1k-12.el8_9
installed 1.1.1k-12.el8_9
NOT AFFECTED — correct

Red Hat backported the fix into their build. Cidra prefers the vendor’s own advisory for distro-packaged components, so a patched machine reads as patched.

The same twelve findings, ranked two ways.

This is real output from a scan of a mixed Maven, npm and PyPI inventory — actual CVSS, EPSS and KEV values. Watch what moves when the ranking stops being about severity.

01Act nowRemote code injection in Log4j10.0>99.9%KEV
02AttendDeserialization of untrusted data in jackson-databind9.826.6%
03AttendDjango Trunc() and Extract() SQL injection9.873.3%
04AttendSQL injection in Django9.844.4%
05Act nowIncomplete fix for Apache Log4j vulnerability9.0>99.9%KEV
06AttendLog4j2 uncontrolled recursion8.6>99.9%
07TrackInsufficiently protected credentials in Requests7.57.4%
08AttendResource exhaustion in Django7.562.6%
09AttendDjango denial of service in UsernameField7.549.8%
10AttendImproper input validation in Apache Log4j26.697.9%
11AttendDeserialization in FasterXML jackson-databind5.945.2%
12TrackVerbose error discloses framework version5.3<0.1%

Sorted by severity, the two vulnerabilities actually being exploited in the wild sit at positions 4 and 9. A CVSS 9.8 with a 26% exploit probability outranks a KEV-listed 9.0.

Not a mockup.

Every screen below is the running platform against a live database. The exposure index opens into its own arithmetic; every finding shows the derivation behind its rank.

The Cidra findings ledger, showing decision band, rank, CVSS, EPSS and KEV columns with Log4Shell ranked first
The ledger. EPSS and KEV sit beside CVSS as first-class columns, and the default sort is the composite.
A Cidra finding detail page showing the priority derivation: each factor, its weight and its contribution to the composite score
Every score shows its arithmetic. An index nobody can interrogate is one they discount.

Built for the person who has to decide what to fix on Monday.

Not for a dashboard nobody opens. Every finding arrives with the evidence behind it, the reason it ranks where it does, and an honest statement of what the platform could not determine.

It tells you what it could not decide.

The last line of a scan matters as much as the first. Products no advisory source recognises are named, not folded into a clean result.

› cidra scan northwind-production inventory.csv --exposure=internet_facing
  rows         9 parsed, 0 skipped
  resolved     8 matchable  1 need review, 3 unidentified
  components   8 distinct
  findings     132 new, 0 updated, 0 closed
  no source    3 identities — no advisory source could answer

› cidra findings northwind-production
  ACT        100  CND-0005  Remote code injection in Log4j
                       KEV · EPSS >99.9% · CVSS 10.0 · due in 3 days

Questions worth asking

Do I need to install an agent or give access to my source code?

No. Cidra works from a list of products and versions — a CSV or spreadsheet export from a CMDB, an asset agent or a licensing tool. It also reads CycloneDX and SPDX software bills of materials. Every other composition analysis tool needs your repository or registry; that leaves out the appliances, vendor applications and firmware that make up most of what a regulated organisation actually runs.

Is comparing against the NVD still enough in 2026?

No. The current build uses OSV for package-native applicability and enriches findings with CISA KEV and FIRST EPSS. CPE-only products are reported as unanswered unless this deployment has a populated applicability mirror; they are never presented as clean simply because a source could not answer.

How does Cidra decide what to fix first?

CVSS filters the corpus but ranks nothing. Cidra layers the 2026 consensus on top: CISA KEV states what is being exploited right now, EPSS forecasts the next thirty days and covers CVEs that have no CVSS at all, and SSVC turns those signals into an act, attend, track-star or track decision. Your own context — internet exposure, asset tier, compensating controls — is the final input. Every score shows its arithmetic: each factor, its weight and its contribution.

Does this help with the EU Cyber Resilience Act?

Directly. CRA Article 14 reporting obligations began on 11 September 2026: manufacturers must notify ENISA of actively exploited vulnerabilities in their products with a 24-hour early warning. That clock is unmeetable without knowing your component inventory. Cidra maintains that inventory, watches the KEV catalogue against it, and can answer the reverse question — which of my products contains this newly exploited component.

How do you avoid the false positives these tools are known for?

Three ways. Version comparison is done per ecosystem using faithful ports of rpmvercmp, dpkg and Maven ComparableVersion rather than a generic dotted-number compare. Distro packages are matched against the vendor's own advisory, so a backported fix in openssl-1.1.1k-12.el8_9 is not reported as unpatched merely because the upstream version string is unchanged. And VEX statements suppress a match before a finding is ever raised. Where the platform cannot decide, it says indeterminate and asks a person rather than guessing.

What happens to software Cidra cannot identify?

It is reported, never silently dropped. An upload row that resolves below the confidence threshold goes to a triage queue with ranked candidates and the reason each was proposed. Confirming one writes it back as an alias so the same question is never asked twice. Products no advisory source recognises are listed explicitly, because a blind spot presented as a clean bill of health is the most dangerous output a security tool can produce.

Cidra

Start with a spreadsheet.

No agent to deploy, no repository to connect, no procurement cycle to start. Upload what you run and see what comes back.