Stop counting vulnerabilities. Start removing risk.
Zenxecure VM unifies every scanner, cloud account and asset inventory you already own, then uses AI to decide what actually threatens your business — and drives the fix to closure.
Your scanners are not the bottleneck. Your queue is.
Detection has been a solved problem for a decade. What has not been solved is the gap between a scanner emitting a finding and an engineer merging a fix — and that gap is where breaches happen.
open findings in a mid-size estate
A 2,000-asset environment running four scanners typically carries a five-figure open backlog. A security team of six can meaningfully triage a few hundred items a week. The arithmetic never closes.
are exploitable in your environment
Severity is a property of the vulnerability. Risk is a property of your deployment. Most high-CVSS findings sit on hosts with no network path, no running service, or a compensating control already in place.
is the real exploit window
Once a vulnerability lands on CISA's Known Exploited list, weaponisation is usually measured in days. A 30-day patch SLA is a policy, not a defence.
tools claiming different truths
Network scanner, cloud posture tool, container scanner and SAST each maintain a separate inventory. Nobody can answer 'how many assets do we have' without reconciling spreadsheets.
What changes when the queue is honest
The value is not a better dashboard. It is engineering hours returned to the business, and a shorter window in which an attacker can use something you already knew about.
Shrink the exploitability window
When the top of the queue reflects what is genuinely reachable and weaponised, the things that can actually hurt you get fixed first — typically within days rather than at the end of a 30-day SLA clock.
Stop paying engineers to triage noise
Triage is the most expensive and least valuable work in a security programme. Removing 97% of it converts your most senior people from ticket sorters back into engineers.
One fix, hundreds of closures
Root-cause clustering means a single base-image bump or library upgrade closes the hundreds of findings it caused. Remediation effort stops scaling with finding count.
Audit evidence as a by-product
SLA attainment, risk acceptances and closure verification are recorded as the work happens. Quarterly audit stops being a two-week evidence-gathering exercise.
A risk number the board can use
Residual risk by business unit, burn-down over time and SLA attainment — expressed in terms an executive committee can act on, not a count of open CVEs.
Accountability that holds
Every asset resolves to a named owner and team. Findings route to the person who can merge the fix, so escalation is a fact rather than an argument.
What Zenxecure VM does
The complete risk-based vulnerability management surface — built as one product, not assembled from acquisitions.
Unified findings pipeline
Normalise and de-duplicate results from network, cloud, container, SAST, DAST and agent-based scanners into one asset-centric model.
Business-context asset graph
Every asset is scored with its owner, environment, data sensitivity, internet exposure and blast radius — not just a CVSS number.
Exploit-aware prioritisation
EPSS, KEV, threat-intel chatter and exploit maturity are weighted live so the top of your queue reflects today's reality.
Automated ownership routing
Findings reach the engineer who can actually fix them, with Jira, ServiceNow and Azure Boards sync that stays two-way.
SLA and exception governance
Policy-driven SLA clocks, risk acceptance workflows and audit-ready evidence for every deviation.
Executive risk reporting
Board-ready views of risk burn-down, SLA attainment and residual exposure by business unit.
Six situations this actually changes
Not feature descriptions — the specific moments where the difference between having this product and not having it shows up in someone's week.
Patch Tuesday without the panic
Microsoft ships 60 CVEs. Four scanners each re-report them across 1,800 hosts, generating roughly 9,000 new findings overnight. You spend three days deciding what to do.
The 9,000 findings collapse to 22 actionable items, ranked by whether the affected service is running and reachable. Six are flagged for same-day action; the rest enter the normal SLA clock.
How it works
De-duplication happens at the asset-and-component level, so the same CVE reported by three tools on one host is one item. Suppression decisions are recorded with their rationale and can be reversed if intelligence changes.
Cloud sprawl after an acquisition
You inherit 14 AWS accounts and two Azure subscriptions with no consistent tagging, no owner mapping and no idea which workloads handle regulated data.
Agentless discovery enumerates every account in hours, infers ownership from deployment metadata and IaC provenance, and produces a single risk-ranked view across the combined estate.
How it works
Ownership inference uses commit history, resource tags, IAM principals and deployment pipeline identity. Confidence is scored, and anything below threshold is queued for human confirmation rather than silently guessed.
Container base image rot
Every one of your 340 container images inherits the same outdated base layer. Your scanner faithfully reports the same 47 CVEs 340 times, and the backlog reads as 15,980 findings.
Root-cause clustering identifies one base image as the origin of 15,980 findings and opens a single pull request to bump it. Merging closes the lot and re-verification confirms it.
How it works
Clustering walks the image layer graph and the SBOM to attribute each finding to the layer that introduced it, so the fix is applied once at the right level rather than 340 times downstream.
A new KEV entry lands at 02:00
You learn about active exploitation from a news article, then spend the morning working out whether you are affected and which systems to patch first.
The KEV feed update re-scores your entire backlog automatically. Affected, reachable assets are escalated, owners are paged, and you open the morning with a list of 11 hosts instead of a question.
How it works
Threat intelligence is evaluated continuously rather than at scan time, so a finding scored low last week is re-ranked the moment its exploit maturity changes. No rescan required.
PCI DSS 4.0 quarterly evidence
Two weeks of screenshotting scanner consoles, chasing engineers for patch confirmations, and reconciling exception spreadsheets against the last assessment.
Export a scoped evidence pack for cardholder-data-environment assets: scan coverage, SLA attainment, remediation timestamps, verification results and every approved exception with its justification.
How it works
Scoping is driven by the asset graph's data classification, so CDE assets are identified by their actual role rather than a manually maintained tag list that drifts.
The quarterly board update
You present open-CVE counts because that is what the tool exports. The board asks whether the number is good, and there is no honest answer.
You present residual risk by business unit, the trend over four quarters, SLA attainment against policy, and the three specific exposures carrying the most potential impact.
How it works
Risk is expressed as expected impact weighted by exploitability and asset criticality, with the methodology documented so it survives scrutiny from audit and the risk committee.
Where the 97% actually goes
Suppression is not a filter someone tuned. Every stage below is a separate, recorded decision with its own evidence — and any of them can be inspected or overruled.
Across four scanners, three clouds and 1,842 assets in one sync cycle.
The same CVE on the same component on the same asset becomes one record.
No network path, or the vulnerable code is never loaded at runtime.
Virtual patching at the WAF, an EDR rule, or segmentation breaking the path.
Clustered to the base images, libraries and IaC modules that introduced them.
Illustrative figures from a design-partner environment of 1,842 assets. Your ratios will differ — the stages will not.
Where the AI actually earns its place in Zenxecure VM
Four concrete jobs the model does on your data — each logged, each explainable, none of it guesswork.
Reachability reasoning
The model evaluates whether a vulnerable component is actually loaded, routable and exposed before it escalates severity.
Fix synthesis
Generates the precise patch, config change or IaC diff for the detected stack, with a rollback note.
Duplicate and drift collapse
Clusters thousands of findings into a handful of root causes so one action closes many tickets.
Analyst copilot
Ask in plain language: "what is internet-facing, exploitable and unpatched past SLA in payments?"
What this satisfies, clause by clause
Vulnerability management is named explicitly in almost every framework an Indian enterprise is assessed against. This is where Zenxecure VM produces the evidence each one expects.
| Framework | Requirement | How Zenxecure VM addresses it |
|---|---|---|
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | Continuous identification, documented evaluation and risk-based treatment of vulnerabilities, with evidence of timeliness against defined SLAs. |
| PCI DSS 4.0 | 6.3.1, 6.3.3, 11.3.1, 11.3.2 | CDE-scoped scan coverage, ranked vulnerability treatment, patch timeliness records and rescan verification, exportable per assessment period. |
| SOC 2 (TSC 2017) | CC7.1 — Detection of configuration changes and vulnerabilities | Demonstrable monitoring, evaluation and remediation workflow with immutable timestamps for auditor sampling. |
| RBI Cyber Security Framework | Annex I — Patch/Vulnerability & Change Management | Documented VA cadence, risk-based patch prioritisation, exception register with approvals, and board-level reporting. |
| SEBI CSCRF | Vulnerability assessment and penetration testing controls | Periodic assessment records, tracked closure of findings and evidence of re-validation for regulated market entities. |
| CERT-In Directions, 2022 | Incident reporting within 6 hours; 180-day log retention | Exploitation-linked findings raise an incident candidate with the evidence bundle pre-assembled; audit logs retained to the required horizon. |
| NIST CSF 2.0 | ID.RA-01, ID.RA-05, PR.PS-02 | Vulnerability identification, risk prioritisation incorporating threat intelligence, and managed platform patching. |
This mapping is provided to help scope an assessment. It is not legal advice and does not certify compliance — your auditor, assessor or counsel makes that determination.
Everything below this line is for the person who has to make it work.
How findings get in, how they are resolved to assets, exactly how the risk score is computed, what each connector reads, and the limits you will want confirmed before an architecture review.
How the data actually flows
Five stages from a scanner emitting a finding to a verified closure. Nothing runs on your hosts and every connector is read-only.
Ingest
Read-only connectors poll or receive webhooks from every source of truth you already run. Nothing is installed on your hosts.
- Scanner APIs polled on a configurable interval, or push via webhook
- Cloud inventory read through a scoped, least-privilege role per account
- SBOM and IaC state pulled from your CI artefacts and repositories
- CMDB and identity directory read for ownership and criticality context
Normalise and resolve
Findings are mapped onto a canonical schema and attached to resolved asset entities, collapsing the same host reported four different ways into one.
- Entity resolution across hostname, FQDN, cloud resource ID, MAC and agent UUID
- Component-level identity via CPE, PURL and SBOM coordinates
- Finding fingerprinting so one CVE on one component on one asset is one record
- Historical lineage retained, so an asset keeps its risk history across renames
Enrich
Each resolved finding is joined against live threat intelligence and the environmental context that determines whether it matters here.
- EPSS probability and CISA KEV membership, refreshed continuously
- Exploit maturity from public proof-of-concept and exploit-kit signals
- Network reachability derived from security groups, NACLs, WAF and load-balancer config
- Runtime signal: is the vulnerable package actually loaded by a running process
- Data classification and business criticality inherited from the asset graph
Score and cluster
AI Core produces a single risk score per finding, then groups findings by the root cause that introduced them.
- Deterministic scoring model with recorded inputs — reproducible, not a black box
- Root-cause attribution across image layers, dependency trees and IaC modules
- Suppression with mandatory recorded rationale and an expiry date
- Every score change is versioned so you can explain last quarter's decision
Act and verify
Work is pushed to the systems your engineers live in, and closure is confirmed against evidence rather than a ticket status.
- Two-way sync with Jira, ServiceNow and Azure Boards, including status and comments
- Generated remediation: package pin, config diff, or Terraform/Helm patch
- Automatic re-verification on the next ingest cycle before a finding is closed
- Reopen with history if a fix regresses, rather than creating a duplicate
How the risk score is calculated
Zenxecure VM replaces CVSS-as-priority with a composite score in the range 0–100. The model is deterministic and every input is recorded on the finding, so any score can be explained to an auditor or overruled by an engineer.
Exploit availability and maturity
Weaponised exploit in a public kit scores highest; proof-of-concept only scores lower; no known exploit code scores near zero on this axis.
Network reachability
Derived from actual security group, NACL, WAF and load-balancer configuration — not from an 'internet-facing' tag someone set in 2023.
Asset criticality and data class
Regulated data, revenue-path systems and identity infrastructure carry more weight than a developer's test instance.
Threat intelligence velocity
EPSS probability and KEV membership, re-evaluated continuously rather than frozen at scan time.
Blast radius
What an attacker reaches next from this asset, computed over the asset graph's trust and network relationships.
Compensating controls
Virtual patching at the WAF, an EDR rule covering the technique, or network segmentation that breaks the path all reduce the score.
Runtime reachability
The largest single reduction. If the vulnerable function is never loaded by a running process, the finding is suppressed rather than ranked.
Weights are the platform defaults. Every factor is tunable per environment, and changes are versioned so historical scores remain reproducible.
Every connector, and exactly what it reads
Zenxecure VM sits above the tools you already own. Every connector below is read-only, and we publish the exact IAM policy or API scope required so your team can review it before granting anything.
Vulnerability scanners
| System | Method | What we read |
|---|---|---|
| Tenable (Nessus / io / sc) | REST API, read-only | Findings, asset inventory, scan coverage and cadence |
| Qualys VMDR | REST API, read-only | Detections, host assets, QID metadata |
| Rapid7 InsightVM | REST API, read-only | Vulnerabilities, assets, remediation projects |
| Trivy / Grype | CI artefact or SBOM upload | Image and dependency findings with layer attribution |
Cloud and infrastructure
| System | Method | What we read |
|---|---|---|
| AWS | Cross-account IAM role, read-only | EC2, ECS, EKS, Lambda, S3, security groups, Inspector findings |
| Microsoft Azure | Entra ID app registration, Reader | VMs, AKS, App Service, NSGs, Defender for Cloud findings |
| Google Cloud | Service account, viewer role | Compute, GKE, Cloud Run, firewall rules, SCC findings |
| Kubernetes | Read-only service account | Workloads, running images, network policies, admission config |
Code, build and artefacts
| System | Method | What we read |
|---|---|---|
| GitHub / GitHub Enterprise | GitHub App, read-only | Repositories, Dependabot alerts, code owners, SBOM |
| GitLab | Project access token, read-only | Dependency and container scanning results, CODEOWNERS |
| Azure DevOps | PAT, read-only | Repos, pipelines, artefact feeds |
| Container registries | Registry API, pull-scope token | Image manifests, layer digests, SBOM attestations |
Workflow and ownership
| System | Method | What we read |
|---|---|---|
| Jira / Jira Service Management | OAuth 2.0, two-way | Issue create, status sync, comments, custom field mapping |
| ServiceNow | OAuth 2.0, two-way | Incident and change records, CMDB CI reconciliation |
| Slack / Microsoft Teams | App install | Escalation, approval and SLA-breach notifications |
| Entra ID / Okta | SCIM + OIDC | User and group directory for ownership and RBAC |
Not listed? A documented REST API and signed webhooks cover the rest, and we build priority connectors with design partners. Tell us what you run.
The answers your architecture review will ask for
Written down here so you do not have to raise a ticket to get them. Anything not covered, ask us and we will put it in writing.
Deployment
- Models
- Multi-tenant SaaS · single-tenant dedicated · private cloud in your VPC
- Primary region
- India (ap-south-1 / Central India) by default
- Agents required
- None — all ingestion is API-based and read-only
- Network requirements
- Outbound HTTPS only; optional static egress IPs for allow-listing
Access and identity
- Single sign-on
- SAML 2.0 and OIDC
- Provisioning
- SCIM 2.0 with group-to-role mapping
- Authorisation
- Role-based, scopeable to business unit, environment or asset tag
- API authentication
- Scoped API keys and OAuth 2.0 client credentials
- Audit
- Immutable administrative and data-access log, exportable
Data and scale
- Ingestion throughput
- Designed for 5M findings per sync cycle
- Asset capacity
- No hard ceiling; tested to 250,000 resolved assets per tenant
- Finding retention
- 24 months hot, 7 years cold archive (configurable)
- Audit log retention
- 180 days minimum, aligned to CERT-In directions
- Encryption
- TLS 1.3 in transit; AES-256 at rest with per-tenant keys
Interfaces
- API
- REST, JSON, OpenAPI 3.1 specification published
- Rate limit
- 600 requests/minute per tenant, burst to 1,200
- Webhooks
- Signed payloads on finding created, escalated, closed and SLA breach
- Bulk export
- CSV, JSON Lines and Parquet to your own object storage
Query your risk from anywhere
Everything in the interface is available over a documented REST API. A common first integration is pulling the SLA-breaching, internet-reachable queue into an internal engineering dashboard.
OpenAPI 3.1 specification published
Signed webhooks with delivery receipts
Scoped API keys and OAuth 2.0 client credentials
The same filters drive scheduled exports and webhook subscriptions, so an integration you prototype with curl can be promoted to a push feed without rewriting the query.
curl -s https://api.zenxecure.com/v1/findings \ -H "Authorization: Bearer $ZX_API_KEY" \ -G \ --data-urlencode "filter[risk_score_min]=80" \ --data-urlencode "filter[reachable]=true" \ --data-urlencode "filter[sla_state]=breached" \ --data-urlencode "sort=-risk_score" \ --data-urlencode "page[size]=50" # {# "data": [# {# "id": "fnd_01JQ8M2K9B",# "risk_score": 94,# "cve": "CVE-2025-41782",# "asset": { "name": "api-payments.prod", "owner": "team-payments" },# "reachable": true,# "kev": true,# "epss": 0.87,# "root_cause": "rc_base_image_alpine_3_18",# "remediation": { "type": "package_pin", "pr_url": "..." },# "sla": { "state": "breached", "due_at": "2026-09-01T00:00:00Z" }# }# ],# "meta": { "total": 11 }# }What the first month actually looks like
Including the parts that need your people, and roughly how much of their time it takes. We would rather set the expectation now than discover it in week three.
Connect
Create read-only credentials for your scanners and cloud accounts. We provide the exact IAM policies and API scopes — you never share a privileged key.
Baseline
First full ingest, entity resolution and ownership inference. You get your true asset count and the size of the real backlog after de-duplication.
Tune and route
Confirm ownership mappings, set SLA policy by asset class, tune scoring weights to your environment, and wire the ticketing integration.
First burn-down
Root-cause clusters are actioned in priority order. Most teams close their largest single cluster in this window and see the backlog drop sharply.
Operate
Continuous re-scoring against live threat intelligence, automated verification on closure, and quarterly evidence packs generated on demand.
The things buyers actually ask
Including the awkward ones. If your question is not here, ask it — we will answer it directly rather than route you to a brochure.
Do we have to replace our existing scanners?
No, and we would usually advise against it. Zenxecure VM is a decision layer that sits above detection. Your Tenable, Qualys, Wiz or Trivy investment keeps running and keeps its renewal; we make its output actionable. If you have no scanner at all we can discuss options, but most customers arrive with three or four already.
How does suppression avoid hiding something real?
Suppression is never silent. Every suppressed finding records the model's inputs, the specific reason, a confidence value and an expiry date. Suppressed items remain fully searchable and are re-evaluated whenever the underlying intelligence or environment changes — a finding suppressed as unreachable is automatically resurfaced if a security group opens. Any engineer can overrule a suppression, and the override is logged.
What does 'reachability' actually mean here?
Two distinct things, both measured. Network reachability is computed from your real security group, NACL, WAF and load-balancer configuration — whether a packet can arrive. Runtime reachability is whether the vulnerable code path is loaded by a running process, derived from container image analysis, SBOM data and runtime signals where available. A finding that fails both tests is suppressed; one that passes both is escalated.
Can generated fixes be applied automatically?
They can, but auto-apply is off by default and we recommend leaving it off outside non-production. The default flow generates a pull request or change record with the patch, a plain-language explanation and a rollback note, and a human merges it. Customers typically enable auto-apply for low-risk dependency bumps in development environments first.
Where is our data stored, and is it used to train models?
Primary storage and processing are in Indian data centres by default, with single-tenant and in-your-own-VPC deployments available. Your telemetry is never pooled into a cross-tenant training set. Model improvements come from our own research corpus and public threat intelligence.
How long until we see value?
Connectors take about two hours of your team's time. A de-duplicated baseline typically lands within the first week, and most teams action their largest root-cause cluster in weeks three to four. The first measurable drop in backlog is usually visible inside a month.
How do you handle assets no scanner covers?
They are surfaced as a coverage gap rather than silently assumed clean. The asset graph is built from cloud inventory, CMDB and identity sources as well as scanner output, so an asset that exists but has never been scanned appears explicitly as unscanned. Pairing Zenxecure VM with Zenxecure ASM closes the outside-in half of the same problem.
What happens to our historical data and SLA clocks?
Historical findings can be imported from your existing tools during onboarding so SLA clocks and trend lines do not restart at zero. Asset lineage is preserved across renames and re-provisioning, which means quarter-on-quarter reporting stays continuous rather than resetting.
The rest of the platform
Every Zenxecure product writes to the same asset graph, so adding the next one compounds what you already have.
Zenxecure ASM
External Attack Surface Management
Continuous, outside-in discovery of every domain, IP, certificate, cloud bucket, API and exposed credential connected to your brand — including the assets no one told you about.
Explore Zenxecure ASMZenxecure Consent
Consent & Privacy Management
A Consent Management Platform engineered for India's Digital Personal Data Protection Act, 2023 — and flexible enough for GDPR, CPRA and every market you expand into.
Explore Zenxecure ConsentConnect one scanner. See your real backlog.
A 30-minute working session against your own environment. You will see how many of your open findings survive reachability analysis — which is usually the moment the conversation gets interesting.
No agents to install · Read-only connectors · Data residency in India