A vulnerability only matters when an adversary can use it against something you own. Most security programs still rank exposure by CVSS score, which measures severity in the abstract, not risk in your environment.
The result is familiar to every CISO: thousands of "critical" findings, a remediation team that cannot close them all, and no clear answer to the board's real question. Which of these would an attacker actually use against us, and what would happen next?
At RedRok we answer that question by triangulation. Instead of judging a weakness on its own, we locate it relative to three other fixed points: the attack technique it enables, the tools that execute that technique, and the threat actors who wield those tools. Where those bearings cross is the true risk.
What triangulation means
In navigation, you fix your position by taking bearings on several known landmarks. No single bearing tells you where you are; their intersection does. Exposure works the same way. Each data source on its own is a single bearing, and each one is incomplete.
| Bearing | Question it answers | Typical source |
|---|---|---|
| Exposure | What weakness exists on this asset or identity? | Internal, external and CTI collection |
| Technique | What does exploiting it let an attacker do? | MITRE ATT&CK techniques |
| Tool | What real-world code performs that technique? | ATT&CK software, malware and offensive frameworks |
| Threat actor | Who uses that code, and against whom? | ATT&CK groups and threat intelligence |
Known tooling adds context, but absence of known tooling does not establish safety. Prioritization also depends on exposure, reachability and evidence that the specific weakness can be used.
Beyond the CVE
CVEs are only one kind of exposure, and often not the one attackers reach for first. Real intrusions chain stolen credentials, hijacked sessions, open services and misconfigurations far more often than they rely on a single exploit.
The RedRok ontology treats each of these as a first-class exposure and maps it to the techniques it enables, exactly as it does for a CVE.
| Exposure type | Example | ATT&CK techniques it enables |
|---|---|---|
| Software vulnerability | Unpatched CVE in an installed application | T1068 Exploitation for Privilege Escalation, T1190 Exploit Public-Facing Application |
| Cached or exposed credentials | Credentials in memory, scripts or config files | T1003 OS Credential Dumping, T1552 Unsecured Credentials, T1078 Valid Accounts |
| Exposed sessions and tokens | Active admin sessions, reusable tokens or tickets | T1550 Use Alternate Authentication Material, T1563 Remote Service Session Hijacking |
| Exposed services | RDP, SMB or management interfaces reachable from the wrong network | T1133 External Remote Services, T1021 Remote Services |
| Privilege escalation paths | Excessive rights, abusable ACLs, nested group membership | T1098 Account Manipulation, T1484 Domain or Tenant Policy Modification |
| Misconfiguration | Weak service permissions, disabled controls, insecure defaults | T1574 Hijack Execution Flow, T1562 Impair Defenses |
Because every exposure type resolves to the same technique layer, they triangulate together. A cached domain-admin credential and an unpatched CVE on the same host are not two unrelated tickets; they are two steps in one attack path, used by the same tools and the same actors.
Agents that collect the evidence themselves
Triangulation needs complete bearings, and most exposure platforms inherit blind spots from the tools they ingest. If the scanner missed a host, the EDR is not deployed on a segment, or the identity tool never sees a cached credential, an aggregator cannot reason about what it was never told.
RedRok does not depend on that stack. Its AI agents collect the data directly, with nothing to install on endpoints:
- Internal agent: assets, installed software, cached credentials and sessions, local and domain permissions, services and configuration.
- External agent: internet-facing services, certificates, domains and exposed management interfaces, seen as an attacker sees them.
- CTI agent (RedPool): infostealer leaks, leaked credentials, access offerings and mentions of the organization on the dark web.
- Attack Path agent: walks the resulting graph to prove which chains actually reach a crown jewel.
Existing tools still add value as additional sources, but they are optional inputs, not a prerequisite. The ontology is built from first-hand observation, which is why its edges can record verification rather than trusting a third-party label. A mid-sized organization without a mature tooling stack gets the same triangulated picture as an enterprise with ten security products.
Inside the RedRok ontology
The RedRok ontology is a graph. Assets, identities, software, vulnerabilities, credentials, sessions, services, misconfigurations, techniques, tools and actors are nodes; the relationships between them are typed edges. Triangulation is not a report generated afterwards. It is the shape of the data itself.
Consider an illustrative endpoint running vulnerable software. AFFECTED_BY edges connect the software to applicable vulnerabilities. So far, this is what any scanner would tell you. The ontology then continues the chain:
- Vulnerability to technique. Each CVE is mapped to the ATT&CK technique its exploitation enables. Here the mapping is
T1068, Exploitation for Privilege Escalation, with the mapping retained as contextual evidence. - Technique to tools. The edge carries the ATT&CK software known to implement
T1068. The presence of tools associated with a technique provides context; it does not establish that those tools exploit a specific CVE. - Tools to actors. Each of those tools links to the groups attributed to it, which in turn carry their targeting profile by sector and region.
The finding now has richer context on a named asset. Whether it creates a usable privilege-escalation step still requires vulnerability-specific and environment-specific verification.
Every edge carries its evidence
Triangulation is only as trustworthy as its bearings. No edge in the RedRok ontology is a bare link. Each one records where it came from, how strong it is, and how it was verified.
| Edge property | What it tells the analyst |
|---|---|
| Lane | Whether the edge is evidence (context) or part of the attack-path layer |
| Sources | The feeds and indexes that produced the link |
| Strength and weight | How much confidence and scoring influence the link carries |
| Verification | How the link was established, for example by structural observation |
| Technique disposition | Whether the ATT&CK mapping is confirmed, inferred or pending |
| Traversable | Whether the attack-path engine may walk this edge |
| Scan and generation | Which mission and model generation produced it, for full traceability |
An evidence edge such as CVE to T1068 enriches the finding and raises its priority, but it is not treated as a proven step an attacker can take. Only edges that pass verification become traversable and feed attack-path analysis. The platform reasons boldly about context while staying conservative about what it calls exploitable. Every edge is also scoped to a single tenant, so intelligence is shared globally while exposure data never crosses organizations.
Why each bearing makes the decision more accurate
Each layer added to an exposure answers a question that severity scores cannot. Together they replace an estimate of how bad a weakness could be with evidence of how likely it is to be used against you, and what it would cost.
Techniques turn findings into capabilities. A CVE, a cached credential and an open RDP port look unrelated in three different tools. Mapped to ATT&CK, they become privilege escalation, credential access and lateral movement: steps that chain. Dozens of findings often collapse into a handful of techniques to close.
Tools prove the technique is weaponized. Known tool implementations help analysts assess how a technique is used. Technique-level associations do not prove exploitation of a particular vulnerability or establish a numerical probability.
Threat actors make it relevant to you. The same technique matters more when the groups using it target your sector, region or technology stack. Actor context filters global noise down to the adversaries realistically coming for this organization.
| Decision input | Severity score alone | Triangulated in RedRok |
|---|---|---|
| What the weakness enables | Not stated | Named ATT&CK technique and its place in an attack chain |
| Likelihood of use | Inferred from severity | Evidenced by the number and type of tools implementing it |
| Relevance | Same for every organization | Weighted by actors targeting this sector and stack |
| Combined risk | Each finding scored in isolation | Findings linked into proven paths toward crown jewels |
| Explainability | A number | Who, with what, through which weakness, to which asset |
From graph to decision
- Remediation teams get a short list ordered by adversary relevance, not CVSS: the few choke-point fixes that break the most chains.
- Detection engineers see which techniques are reachable in their estate, and which tools would execute them, so coverage gaps become concrete.
- CISOs and boards get an answer in business terms: which relevant threat actors can reach which crown jewels, through which weaknesses, and what closing them removes.
Because the ontology is rebuilt with every mission, the picture moves with the environment. A new CVE, a newly attributed tool or a newly active group re-weights the graph without anyone rewriting a rule.
Exposure management that thinks like the adversary
Attackers do not think in CVE lists. They think in capabilities: what can I run, what will it get me, and where does it lead next. Continuous Threat Exposure Management should reason the same way. The RedRok ontology holds exposures, techniques, tools and actors in one connected, evidence-backed model, so every finding arrives already placed on the map, at its true risk.