Dvaro by UmaadiBook a pilot
How it works

Dvaro works in five steps, from raw report to proof.

Dvaro turns every scanner's findings into what actually matters for each asset: what is real, what to fix first, what blocks the next release, and the evidence behind each answer.

Before the steps

Each scanner sees one slice of your risk.

Dvaro brings their findings together, on the asset they belong to, and makes one decision for each asset.

  • Semgrep

    reads your code.

  • Snyk

    checks your libraries.

  • Nessus

    scans the network.

  • Burp

    tests the running web app.

  • Wiz

    watches the cloud.

01

Read

Dvaro reads the reports your scanners already produce: 50+ scanner formats, and the list keeps growing. It detects the tool from the file, from network and web scanners to code, container and cloud tools.

Every finding becomes one record format, whatever tool wrote it.

02

Account

Repeats inside a report are folded together. Every item is accounted for: kept, merged or rejected, with a reason you can read. Nothing disappears quietly.

Across tools, only dependency findings merge. When two dependency scanners report the same CVE (a published vulnerability id) in the same library on the same asset, they become one record. Findings from other tools stay as they are, each on its own asset.

03

Match: the rule engine

This is the heart of Dvaro. Findings are checked against a growing library of tested detection rules. A detection rule is a written definition of one weakness, in words a person can read and argue with. Nearly every rule is tested with positive, negative and edge cases.

  • Two steps to a matchFirst, Dvaro shortlists the candidate rules for a finding. Then it checks each condition of every candidate.
  • A match names its ruleWhen a rule matches, the finding names the rule it matched, so you can see exactly why Dvaro knows what it is.
  • No guessingWhen nothing accounts for a finding, Dvaro says so. The finding stays visible with its scanner severity, and the decision for its asset stays Incomplete instead of guessing. A labelled AI assessment can account for a finding no rule matches.
  • Nobody approves their own ruleA reviewer approves a new rule, and a different person promotes it to live.
  • The reviewer sees it firstBefore approving, the reviewer sees what the rule would have matched in real data. Nothing written by AI goes live by itself.

Read more on the detection rules page.

04

Decide

Each asset is checked against your own release policy. Every asset gets one decision: Pass with evidence, Hold or Incomplete, and the reasons are named. The findings that break your policy are named on the decision. Decision names are set per workspace.

Public exploit data sits alongside each finding as context: EPSS (Exploit Prediction Scoring System) and the KEV catalogue (Known Exploited Vulnerabilities) of CISA, the US Cybersecurity and Infrastructure Security Agency.

Inside a decision, AI can raise a severity or add a reason to hold. It can never lower a severity or lift a hold, and every AI input is labelled. A fix is closed only after a rescan or an approved retest confirms it.

05

Prove

Each decision comes with an evidence pack: the findings behind it, the rules they matched and your policy, hashed with SHA-256 so any later change shows. Export it as JSON or print it. It carries the sign-off when someone signs it.

Steps 03 and 04 together

Each finding meets its rule, then each asset gets its decision.

Example workspace · fictional data
Scanner findingAssetMatched rule
CProgress MOVEit Automation < 2025.1.7 Multiple VulnerabilitiesNessusFile transfer serverMOVEit Automation multiple vulnerabilities
MOpen redirection (reflected) on /oauth/callbackBurpNet banking web appOpen redirect on an OAuth callback
MIBM WebSphere Application Server 9.x < 9.0.5.29 Identity SpoofingNessusNet banking web appWebSphere identity spoofing
Ctomcat: remote code execution via partial PUTTrivyPayments APINot accounted for
File transfer serverHold1 critical open. Your policy allows 0.
Net banking web appPass with evidence2 findings, both matched, both within policy.
Payments APIIncomplete1 finding not accounted for. No verdict yet.
Three ways in

Dvaro runs in Umaadi's cloud.

Nothing is installed on your laptops or on your on-prem servers. Umaadi sets up your workspace, and your findings reach Dvaro in one of three ways.

01Connect your scanners

Connect Snyk, Mend, Invicti or GitHub and see your whole security posture on one Dvaro dashboard, instead of visiting each scanner's own dashboard.

02Upload reports

If you use a few scanners, or scanners that only produce reports, upload them in the browser and see your organisation's risk posture.

03One call in your CI pipeline

Your CI (continuous integration) pipeline sends a report, and pass or fail comes back in the same call.

Start with a paid pilot: credited to your first year, or your money back if the agreed results are not met. The cloud running costs of the pilot are not refunded.

In your pipeline

One call uploads the report and answers the gate.

Your build reads one field. "fail" stops it. The response also says why.

Example request
curl -X POST "$SIP_URL/api/v1/ci/import-and-gate" \
  -H "Authorization: Bearer $SIP_CI_TOKEN" \
  -F client_id="$SIP_WORKSPACE" \
  -F fail_on=hold \
  -F [email protected]
Example response, trimmed
{
  "gate": "fail",
  "decision": "HOLD",
  "reason": "Release is on HOLD (blocking): Critical findings open: 1",
  "report": {
    "status": "processed",
    "detected_tool": "trivy"
  }
}

Fictional values. The CI token needs only two rights: upload a report and read the gate. If the report is still being processed when the wait ends, the gate fails rather than passing.

Book a pilot

Every finding accounted for. Every decision with its evidence.

Bring one of your own reports and watch it go through the five steps. Tools find. People prove.

Book a pilot