Vexta ASPM: Asset Criticality Levels and SLA Bands

Vexta's ASPM module decides how urgent a finding is by looking at what it can reach, not just how severe it looks on its own. ASPM stands for Application Security Posture Management; inside Vexta, VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, it classifies every asset in the attack graph by criticality level and uses that classification to sort findings into SLA bands, so the same technical bug can land in a very different priority bucket depending on what sits behind it.

What does ASPM add on top of a findings list?

A flat findings list treats every SQL injection the same regardless of what database it touches. Vexta's ASPM pipeline works differently. First it classifies every node in the attack graph, hosts, services, web apps, URLs, and more, by criticality using signals like open ports, URL paths, and technology fingerprints. Then, for a given finding, it runs a breadth-first search from that finding's source node outward to see whether a path exists to a sensitive-data asset or a crown-jewel asset. Finally it scores exploitability on a 0 to 1 scale and buckets the result into an SLA band. The stated goal of that pipeline, in Vexta's own words, is turning a flat findings list into the 3% that actually matter.

This sits on top of the attack graph that already models a target's infrastructure: 15 node types (host, service, web app, URL, parameter, finding, credential, user, domain, cloud account, cloud resource, secret, out-of-band callback, IP, and ASN) connected by 12 edge types describing relationships like hosts, exposes, vulnerable_to, leaks, authenticates_to, and chains_into. ASPM reuses that same graph to answer a specific question: does this finding sit near anything that actually matters.

How does Vexta score asset criticality?

Every asset lands on a five-level scale. Level 0, Unclassified, means there isn't enough data yet to score it. Level 1, Public Marketing, covers something like a brochure site with no sensitive functionality. Level 2, Operational, covers app delivery and login surfaces, the machinery that keeps a product running day to day. Level 3, Sensitive Data, covers assets handling PII, payment information, or health data. Level 4, Crown Jewel, is reserved for the assets an attacker would actually be after: databases, identity and access management systems, admin planes.

That scale gives a hunter or a security lead a shared vocabulary for asset importance that doesn't depend on guessing from a hostname. A login form and a marketing landing page might both throw off similar-looking findings, but ASPM's criticality classification is what tells you which one is worth chasing first.

How does an SLA band get assigned to a finding?

Three bands cover the output of the pipeline. act_now applies when a finding's exploitability score is 0.7 or higher and it can reach a crown-jewel target. sprint applies when the score is 0.4 or higher and it can reach a sensitive-data target. Everything else falls into backlog. Because the band depends on both the exploitability score and what the finding can actually reach, two findings of identical technical severity can land in different bands purely based on network position and asset classification.

That's a deliberate correction for a common failure mode in flat vulnerability lists: a critical-severity finding on an isolated, low-value asset competing for attention against a medium-severity finding that has a clear path to a crown-jewel database. ASPM's SLA bands push the second one up the queue even though its raw severity label looks less alarming on paper.

Where this fits in a hunter's workflow

For an engagement covering a large environment with dozens or hundreds of assets, working straight down a severity-sorted list means spending real time on findings that, on inspection, sit on assets nobody would prioritize protecting. ASPM's SLA bands give you a starting order that already accounts for blast radius: work the act_now band first, since those are exploitability-scored findings with a live path to something classified as a crown jewel, then sprint, then backlog if time allows.

This pairs naturally with the attack graph's path-chaining capability, since both draw from the same underlying graph of hosts, services, and relationships. A finding that ASPM flags act_now because it reaches a crown-jewel asset is also a natural candidate for tracing the exact attack path that gets there, using the graph's breadth-first shortest-path search and its Cytoscape.js-based visual export. ASPM tells you which finding matters most; path chaining shows you why, edge by edge.

See plans on the pricing page for which license tier includes ASPM and attack-path chaining.

Reading the criticality scale during scoping

The five-level criticality scale is also useful before a scan even starts, not just after findings come in. Walking a target list and giving each asset a rough criticality expectation, a marketing site at Level 1, a customer login at Level 2, a billing system at Level 3, a core database or identity provider at Level 4, gives you a sanity check against what ASPM actually classifies once the scan runs. If an asset you expected to score as Sensitive Data or Crown Jewel comes back Unclassified or Operational, that's worth a manual look; it usually means the classifier didn't have enough signal yet, whether from port exposure, path naming, or a technology fingerprint, rather than the asset genuinely being lower value than you thought.

That same scale also gives a security lead a quick way to explain scan priorities to a client without walking through the technical details of the attack graph. Saying a finding got flagged act_now because it has a live path to a Crown Jewel asset, plainly meaning a database, identity system, or admin plane, communicates urgency in terms a non-technical stakeholder can follow immediately.

Key takeaways