Everything EchelonGraph does, and what each part is for
Most cloud security platforms own your environment and rent their vulnerability truth from somebody else. We built both halves — an agentless multi-cloud posture engine with an attack graph, and our own CVE pipeline that reads the CNA source directly. Below is every capability we ship, grouped the way you would buy it.
54 capabilities across 9 categories. Everything listed here is live in production as of August 2026 — nothing on this page is on a roadmap. Where something is partly shipped, the card says so.
No signup for the scanner. No API key for the CVE data. No third-party analytics on this site.
Free and public tools
Everything in this section works with no account, no key and no call. It is the same data the paid product runs on.
Surface Scanner
The problem. You cannot see your own public attack surface the way an attacker does without either buying a platform or running a dozen separate tools.
What you get. Enter a domain and get a graded report — TLS, headers, DNS, email posture, exposed files, technology fingerprints and more — in about twenty seconds. No signup, and the grade is withheld rather than guessed when coverage is too thin to stand behind.
CVE Pulse — public corpus
The problem. Vulnerability data sits behind vendor logins, rate limits and API keys, so the people who most need it cannot script against it.
What you get. A browsable, searchable feed of the full CVE corpus with our own risk score on every record, free to read and free to query.
Free CVE API — no key
The problem. Every commercial vulnerability API needs a key, a contract, or both, which puts basic automation out of reach for small teams.
What you get. A public JSON API over the same corpus, with no key and no signup, so you can wire CVE data into a script or a dashboard today.
MCP server
The problem. AI coding assistants answer vulnerability questions from stale training data and cannot look anything up.
What you get. A Model Context Protocol endpoint that lets an AI assistant query live CVE data directly instead of guessing from memory.
Am I affected? — version matcher
The problem. Knowing a CVE exists is useless without knowing whether the version you actually run falls inside the affected range, and naive matchers get range logic wrong.
What you get. Give a product and a version, get back the CVEs that genuinely apply — plus the candidates that were excluded and the reason each one was ruled out.
Compliance framework explorer
The problem. Framework control text is scattered across PDFs and paywalled portals when you just want to read what a control requires.
What you get. Every framework and control we score against, browsable and linkable, so you can check the wording before you commit to a programme.
Vulnerability intelligence
Most platforms license their vulnerability truth from someone else. We read the CNA source directly, score it ourselves, and publish the arithmetic.
Pre-NVD ingestion
The problem. Waiting for NVD to publish and then analyse a CVE means learning about it well after the people exploiting it do.
What you get. We poll MITRE's CNA feed every five minutes and score on arrival, so a CVE is live and rated here while NVD still shows it as awaiting analysis.
EG Score
The problem. CVSS says how bad a bug could be in theory and nothing about whether anyone is exploiting it, so a CVSS-sorted queue is not a work queue.
What you get. A single score combining severity, real-world exploitation signals and automatability — and every response shows the rule that fired, the sources that contributed and the weights, so an analyst can argue with it.
Multi-source reconciliation
The problem. Different authorities score the same CVE differently, and single-source feeds silently pick one and hide the disagreement.
What you get. We ingest several independent sources, keep them all, and show which one won and which ones lost rather than flattening them into one number.
Exploitation signals
The problem. Two per cent of vulnerabilities are ever exploited, but nothing in a CVE record tells you which two per cent.
What you get. Known-exploited status and exploit-probability scoring are attached to every record and drive ranking directly.
Vendor advisory aggregation
The problem. Vendors publish to their own customers days or weeks before a CVE ID exists, and NVD-derived feeds cannot carry what has no ID yet.
What you get. Ten vendor advisory sources in one feed — including advisories published before any CVE ID is assigned, which NVD-derived feeds do not carry at all.
Vendor security scorecard
The problem. There is no neutral public measure of how quickly a vendor ships advisories or how much of its CVE volume ends up exploited.
What you get. A cross-vendor comparison — volume, high-severity rate, exploited rate, median days to advisory — with industry medians to judge against.
Continuous re-scoring
The problem. A CVE scored at publication is wrong the moment exploitation signals change, and a fixed refresh cadence leaves most of a large corpus stale.
What you get. A tiered scheduler continuously re-enriches the corpus, so a newly-exploited CVE is re-rated without waiting for the next ingest cycle.
Lifecycle hygiene
The problem. Feeds measure freshness and never completeness, and they keep withdrawn CVEs alive as pages for bugs that do not exist.
What you get. A reconciler pulls in any CVE our own data references but the corpus lacks, and withdrawn records are marked rejected and suppressed from scoring.
Cloud posture — CSPM, CIEM, AI-SPM and IaC
Connect a read-only role. Nothing is installed in your account and no write permission is ever requested.
Multi-cloud posture engine
The problem. Misconfiguration is the dominant cloud breach cause, and every cloud has its own vocabulary for what 'public' or 'unencrypted' means.
What you get. One rule engine evaluates a normalised asset model and produces severity-ranked, category-tagged findings from a read-only role.
Live for AWS and GCP. Azure collectors and rules are written but not yet enabled in production — we would rather say so here than let you find out after connecting a subscription.
CIEM — privilege-escalation paths
The problem. An over-permissioned role is not visible in a resource list; the risk is the path from a low-privilege identity to an administrator.
What you get. Escalation-capable policies and role-assumption chains are detected and emitted as traversable identity edges in the attack graph, not as a separate report nobody reads.
AI-SPM — AI and ML service posture
The problem. Teams stand up managed AI and ML services far faster than security reviews them.
What you get. Dedicated collectors and rules assess managed AI and ML services alongside the rest of the estate, in the same findings table.
Cloud secrets detection
The problem. Hard-coded credentials in VM startup scripts, function source and image layers are invisible to resource-configuration scanning.
What you get. Text the scanner already reads is checked for credential-shaped strings, then passed through several precision layers — including structural checksum verification — before a redacted, fingerprinted finding is emitted.
Near-real-time change detection
The problem. Periodic scanning lets a misconfiguration sit undetected until the next cycle, but agentless customers will not install anything to fix that.
What you get. A service watches each connected account's read-only change log and pulls that account's scan forward the moment something moves.
Infrastructure-as-code scanning
The problem. Fixing a misconfiguration in a running account treats the symptom — the template regenerates it on the next apply.
What you get. Terraform, CloudFormation, Kubernetes manifests and Helm charts are scanned before deploy, with real HCL2 parsing rather than regex over templates, and can fail a CI build.
Configuration drift detection
The problem. A resource that was compliant last week and is not today is a different and more urgent signal than one that was always wrong.
What you get. Each scan's failing checks per resource are compared with the previous snapshot, and a change raises a drift finding.
CIS benchmark mapping
The problem. Auditors ask for coverage of a benchmark they recognise, not for a vendor's private rule identifiers.
What you get. Rules carry their CIS reference, so findings map straight onto the benchmark an auditor already accepts.
Attack graph and blast radius
A list of ten thousand findings is not a plan. The graph is what turns severity into an order of work.
Attack-path analysis
The problem. Severity tells you how bad a finding is in isolation and nothing about whether it is reachable from the internet or leads anywhere that matters.
What you get. Every asset, identity and network edge is held in one graph, and the paths from an internet-facing entry point to sensitive data are enumerated in plain English with the hop count and the worst CVE on the route.
Blast radius
The problem. After a compromise the first question is what else the attacker can now reach, and answering it by hand takes days.
What you get. Select any asset and see what it can reach and what can reach it, so the containment decision is a reading rather than an investigation.
CVE-to-asset matching
The problem. A vulnerability feed and an asset inventory in separate tools mean someone has to join them by hand, badly, under time pressure.
What you get. The corpus is applied to your live inventory automatically, so the ranked list is of the CVEs that are actually present on your assets — not of every CVE published this week.
Cross-cloud lateral movement
The problem. Federation between clouds creates paths that neither cloud's native tooling can see, because each only knows its own side.
What you get. Identity federation edges are modelled as first-class graph edges, so a path that starts in one cloud and lands in another is visible as one path.
Evidence provenance
The problem. A graph you cannot audit is a picture, and 'the tool said so' does not survive a review.
What you get. Each edge records how it was established, so a claimed path can be traced back to the observation that produced it — and a path built on weaker evidence says so.
Supply chain, containers and SBOM
You cannot patch what you do not know you are shipping.
SBOM generation
The problem. Customers and regulators increasingly require a software bill of materials, and producing one by hand per release does not scale.
What you get. Bills of materials are generated in the standard interchange formats from what is actually in the image, not from what the manifest claims.
Container registry scanning
The problem. Images sit in a registry accumulating known vulnerabilities long after the pipeline that built them has gone green.
What you get. Registries are scanned directly, so an image that was clean at build time and is not clean today is surfaced without rebuilding it.
Coverage ledger
The problem. A component inventory that silently misses a package type looks identical to a clean one.
What you get. We record which ecosystems were catalogued and which were not, so an absence in the inventory can be told apart from an absence in reality.
Runtime and network sensors
Optional, customer-hosted, and designed so that we never need to hold your raw data to be useful.
eBPF runtime sensor
The problem. Posture scanning describes how an environment is configured, never what a workload actually did at three in the morning.
What you get. A kernel-level sensor runs inside your own cluster and reports process, file and network behaviour without a sidecar per pod.
Encrypted traffic analysis
The problem. Almost all traffic is encrypted, and the usual answer is to break TLS — which most security teams rightly refuse to do.
What you get. Connections are characterised from their handshake and flow shape rather than their contents, so nothing is decrypted and nothing needs to be.
Shadow API discovery
The problem. Undocumented endpoints outlive the teams that shipped them and never appear in an API catalogue.
What you get. Endpoints are discovered from observed traffic rather than from documentation, so the catalogue reflects what is actually being called.
Behavioural anomaly detection
The problem. Signature-based detection only finds what someone has already written a signature for.
What you get. Statistical baselines per workload flag departures from a workload's own normal behaviour. This is statistics, not machine learning, and we would rather say which it is.
Kubernetes posture
The problem. Cluster permissions and network policy drift quietly, and a cluster is not covered by cloud-account posture scanning.
What you get. Role bindings, network policies and workload settings are audited against recognised Kubernetes benchmarks.
Internet exposure radars
Continuous passive research into what is exposed on the public internet. Published openly, and used to tell you when it is yours.
Shadow AI discovery
The problem. AI services are adopted faster than any approval process, and nobody can enumerate what the organisation is already sending to them.
What you get. Publicly reachable AI infrastructure is discovered and catalogued, so the conversation starts from evidence rather than a survey.
Exposed datastore radar
The problem. Databases end up reachable from the internet by accident, and the owner is usually the last to know.
What you get. Exposed datastores are identified from the outside. We read only what is needed to establish exposure — schema-level metadata, never record contents.
Exposed AI key radar
The problem. API keys leak into client-side bundles and public repositories, where they are billable to you until someone notices.
What you get. Publicly exposed AI provider keys are detected so they can be rotated before the bill or the breach arrives.
Email spoofability
The problem. Most domains are misconfigured in a way that lets anyone send mail as them, and the misconfiguration is invisible from the inside.
What you get. Sender authentication records are evaluated end to end and reported as whether your domain can be impersonated today.
Subdomain takeover
The problem. A DNS record pointing at a decommissioned service is a live takeover waiting for someone to claim the target.
What you get. Dangling records are detected and confirmed, so a hijackable subdomain is found before somebody else finds it.
Certificate transparency feed
The problem. New certificates are issued for your domains continuously, including by people who should not be issuing them.
What you get. Certificate transparency logs are watched for your names, turning newly-issued certificates into an early signal of shadow infrastructure.
Exposed MCP server adjudication
The problem. AI agent infrastructure is being deployed publicly at speed, usually with no authentication and no awareness that it is reachable.
What you get. Publicly reachable agent endpoints are found and adjudicated for whether they are actually protected, using the protocol's own authentication standard rather than a guess.
Findings operations, AI and integrations
A finding nobody can action is a finding nobody will action.
Security copilot
The problem. The person who has to fix a finding is often not the person who understands the finding.
What you get. An assistant grounded in your own findings and asset graph answers questions in context, rather than offering generic advice about a CVE number.
Remediation guidance
The problem. A finding that says what is wrong but not what to type is a ticket that sits.
What you get. Findings carry concrete remediation steps for the specific resource and cloud they were raised against.
Findings lifecycle
The problem. Without ownership and state, a findings list becomes an unread backlog that everyone stops opening.
What you get. Findings have status, ownership, suppression with a reason, and a full audit trail of who decided what and when.
Alerting and notifications
The problem. Security information that arrives only when someone opens a dashboard arrives too late.
What you get. Configurable alerting so the things you care about reach you where you already work.
SIEM and webhook export
The problem. A security tool that cannot export is a silo, whatever else it does well.
What you get. Findings export in standard formats and fire webhooks, so they land in the systems you already run.
Dashboards and scheduled reports
The problem. The board and the engineers need the same truth presented completely differently.
What you get. Configurable dashboards and scheduled reports so each audience gets its own view of one dataset.
Compliance, governance and enterprise controls
The questions that decide whether a security tool can actually be bought.
Continuous compliance scoring
The problem. Compliance evidence is gathered by hand at audit time and is stale before the auditor reads it.
What you get. Live cloud configuration is scored against 330 frameworks and 3,473 controls continuously, with a re-score completing in seconds after a change lands. Both counts are on a public endpoint you can check without an account.
Custom frameworks
The problem. Every organisation has internal standards that no published framework covers.
What you get. Define your own controls and score them alongside the published frameworks, in the same engine and the same reports.
AI governance mapping
The problem. AI-specific regulation is arriving faster than tooling for it, and the obligations are not the same as general security obligations.
What you get. AI-specific governance frameworks are mapped against your AI and ML inventory, so the obligation is tied to a real workload. Machine evaluation covers part of each framework; where a control needs a human judgement we say so rather than scoring it green.
SAML single sign-on
The problem. An enterprise cannot adopt a tool that sits outside its identity provider.
What you get. Standards-based single sign-on with signature verification hardened against known assertion-wrapping attacks.
Role-based access control
The problem. Not everyone who needs to see a dashboard should be able to change a suppression.
What you get. Roles separate what each person can see from what they can change, with tenant isolation enforced at the data layer.
Data residency
The problem. For many organisations where the data is processed decides whether a tool can be used at all.
What you get. Regional processing options so residency requirements can be met rather than argued about.
Questions we get asked
Is the Surface Scanner really free, with no signup?
Yes. Enter a domain and get a graded report in about twenty seconds with no account, no email and no credit card. It runs the same engine the paid product uses.
Do I have to install an agent?
No. Cloud posture, the attack graph, CVE matching and compliance all work agentlessly from a read-only role — nothing is installed in your account and no write permission is requested. The runtime sensors are optional, separate, and run inside your own cluster.
Which clouds do you support?
AWS and GCP are live in production today. Azure collectors and rules are written but not yet enabled, and we would rather tell you that here than after you connect a subscription. Kubernetes is covered separately by the runtime sensors.
Where does your CVE data come from, and is the API really free?
We read MITRE's CNA feed directly every five minutes rather than licensing a downstream feed, and we combine several independent sources. The public API needs no key and no signup.
Do you track me on this site?
No. There is no third-party analytics, no advertising pixel and no session recording on this site. That is a deliberate commitment, not an oversight.
How is this different from a CNAPP like Wiz or Orca?
Those products own your environment and license their vulnerability intelligence from a third party. Vulnerability-intelligence vendors own the data but have no environment to apply it to. We built both halves — our own CVE pipeline and our own posture engine and graph — so the ranking of a finding reflects both what the bug is and whether it is reachable in your estate.
See it on your own environment
Start with the free scanner — no account, about twenty seconds, and it will tell you what an attacker can already see. When you want the same treatment applied to your cloud accounts, talk to us.