Knowledge graphs make security remediation actionable at enterprise scale

At a glance

What this is: This is a deep-dive on Cogent’s security knowledge graph approach, which links findings to environment context so agents can coordinate remediation and verify whether risk actually fell.

Why it matters: It matters because IAM, NHI, and broader security teams need evidence-backed decisioning when remediation spans assets, owners, and runtime context, not just a list of alerts.

Context

At enterprise scale, the core problem is not a lack of findings but a lack of connected context. Security teams often have scanners, registries, deployment records, and ownership data, but those records live in separate systems and cannot reliably answer which assets are affected, who owns them, or what should be fixed first.

Cogent’s answer is a property graph that turns those disconnected records into a durable operational model. The identity angle is real here because ownership, accountability, and delegated action are part of the remediation workflow, even when the primary subject is vulnerability management rather than IAM.

When the graph is complete enough to preserve evidence and provenance, remediation can move from repetitive lookup work to coordinated change management. That is atypical only in maturity, not in need: most large environments already have the data fragments, but not the connective tissue.

Key questions

Q: How should security teams handle remediation work items when findings arrive across multiple security tools?

A: Security teams should centralise triage around a single workflow that can deduplicate findings, prefill context, and preserve an audit trail as items move between owners. The goal is to reduce swivel-chair work and avoid duplicate tickets. Good practice is to route only confirmed, materially distinct issues into separate work items and keep escalation criteria consistent.

Q: Why does provenance matter in security operations and remediation workflows?

A: Because teams need to know not only what the system decided, but why it decided it. Provenance preserves source records, conflicting values, and resolution rules, which makes classifications explainable and auditable. That matters when remediation priority, ownership, or environment classification affects business risk and change sequencing.

Q: What breaks when security teams cannot assign asset ownership during remediation?

A: Remediation stalls because findings cannot be routed to an accountable team, which pushes work into manual coordination and informal follow-up. The result is slower closure, weaker auditability, and more time spent resolving responsibility than reducing exposure. Ownership must be treated as a required control, not an optional metadata field.

Q: Should organisations use one authoritative graph or separate data copies for security operations?

A: One authoritative graph is usually the better foundation, with separate serving projections for fast reads. That keeps source meaning consistent while allowing different consumer views for analysis, dashboards, and agent workflows. Separate copies create more refresh complexity and make reconciliation harder when source records change.

Technical breakdown

How a property graph turns findings into operational context

A property graph represents entities as nodes and relationships as edges, with attributes attached to both. In remediation workflows, that matters because a scanner finding alone rarely tells you what to do next. The same vulnerability may exist in many images, workloads, and environments, but the business meaning changes with ownership, runtime placement, and criticality. A graph lets tools ask structured questions across those dimensions instead of treating each alert as an isolated record. The result is not just better search. It is a reusable context model that supports scoping, deduplication, prioritisation, and downstream verification across the same data model.

Practical implication: Model findings, workloads, and owners as linked entities so remediation decisions are based on context, not on flat alert lists.

Why provenance matters in security remediation decisions

Provenance is the record of where a value came from, what rules resolved conflicts, and which source was ultimately trusted. That is critical when one system says a workload is development and another says production, or when the same image appears across multiple runtime records. Without provenance, agents can produce confident but uninspectable answers. With it, the system can show the evidence chain behind a classification or scope decision. This is especially important in large environments where remediation priority affects operational risk and service ownership. Provenance turns an answer into an explainable decision that can be audited later.

Practical implication: Preserve source evidence and resolution logic so every remediation decision can be traced back to its basis.

How ontology and projections make the graph usable at scale

An ontology defines what the entities, relationships, and attributes mean, while projections reshape the same authoritative graph for different query patterns. That separation solves a common scale problem: the source of truth must stay stable, but analysts and agents need different views for different tasks. In this model, the ontology keeps the semantics consistent across ingestion, storage, and tools, while projections optimise repeated reads for investigations, dashboards, and remediation workflows. The architectural benefit is that teams can keep one canonical graph and still support fast interactive use. The trade-off is more design discipline up front, especially around schema evolution and refresh timing.

Practical implication: Separate the authoritative model from the serving view so analytics and remediation can scale without duplicating source-of-truth logic.

Threat narrative

Attacker objective: The attacker objective in this pattern is to exploit the gap between a known vulnerability and incomplete remediation before the affected workloads are consistently identified and fixed.

1. Entry occurs when a scanner or inventory system surfaces a vulnerable component, such as Log4Shell in a container image, but that observation is still disconnected from runtime and ownership context.
2. Escalation happens when the same finding exists across multiple deployments, yet each copy appears as a separate task, making prioritisation and coordination inconsistent.
3. Impact is delayed remediation, misdirected effort, and incomplete verification because teams cannot reliably prove which workloads were fixed and which still carry risk.

NHI Mgmt Group analysis

Security remediation now depends on context engineering, not just detection volume. The article shows that enterprise findings only become actionable when they are connected to ownership, runtime state, and business criticality. That is a governance shift, because the hard part is no longer collecting evidence but turning scattered evidence into a decision model that agents can safely use. The practical implication is that remediation programmes need structured context as a control plane, not as a reporting afterthought.

Provenance is the control that makes agentic remediation defensible. If a system cannot explain why it chose one environment classification over another, an agent can still act, but it cannot justify the action in a way a security team can trust. That creates a verification problem, not just a workflow problem. The practical implication is that remediation automation must retain source observations, rule outcomes, and conflicting values so analysts can audit the decision path.

Identity is embedded in remediation because ownership determines who can close the loop. The Billing example is not incidental. When a vulnerability spans images, workloads, and organisational ownership, the remediation path depends on who is accountable for change, approval, and verification. This is where application security guide style governance thinking becomes relevant even outside application code. The practical implication is to treat owner resolution as part of the remediation data model, not a separate ticket field.

Context reuse is the real scale problem behind security operations debt. Reconstructing the same environment knowledge inside every investigation session does not scale when the estate contains hundreds of millions of exposures. The article’s graph model is effectively a response to repeated context loss across tools and sessions. The practical implication is to build shared security context once, then reuse it across triage, prioritisation, and verification workflows.

From our research library:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Context engineering is becoming a security control. The operational challenge is no longer whether a vulnerability is known, but whether the surrounding identity, ownership, and runtime context is available in time to act. As environments grow, teams that cannot reuse context will keep paying the same correlation cost in every investigation cycle.

Security knowledge graphs will matter most where remediation spans machine identities and ownership boundaries. The article’s model is not only about faster querying. It is about making the remediation path intelligible across systems that each know a different part of the truth. That is the governance gap practitioners should expect to widen unless context, provenance, and ownership are designed in from the start.

For practitioners

• Build a canonical context model for remediation Link findings, images, workloads, environments, and owners in one queryable model so triage and fix sequencing do not depend on manual correlation.
• Preserve evidence for every resolved classification Store source observations, candidate values, and rule outcomes so analysts can inspect why a workload was classified one way instead of another.
• Separate authoritative data from serving projections Keep the source graph stable and publish optimised read models for dashboards and agent queries so scale does not force duplicated logic.
• Treat ownership as part of remediation scope Use organisational ownership records to route affected workloads to the teams that can actually rebuild, redeploy, and verify the fix.

Key takeaways

• Security remediation fails when findings are detached from the environment, ownership, and runtime context needed to decide what to fix first.
• The article’s graph model shows why provenance and explainability matter as much as detection when multiple records disagree about the same asset.
• Practitioners should treat shared context as a core operational control so they can scope, route, and verify remediation at enterprise scale.

Related NHI Mgmt Group resources: Application Security Guide · AI Agent Identity Security Buyer's Guide · Agentic AI Security Guide

Key terms

• Property Graph: A property graph is a data model that stores entities as nodes, relationships as edges, and descriptive attributes on both. In security operations, it lets teams connect findings to assets, owners, environments, and remediation status without flattening the meaning of those relationships.
• Provenance: Provenance is the traceable history of where a software artifact came from, who approved it, and what controls were applied along the way. In container security, provenance supports trust decisions because it links delivery steps to accountable identities and review points.
• Ontology: A structured model that defines what entities exist in a system and how they relate to one another. In connected mobility, ontology gives data shared meaning so telemetry, diagnostics and alerts can be interpreted consistently across platforms and teams.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control to the wider security operations programmes they run.