A findings table is not a security knowledge graph
Why we model security knowledge as relationships rather than rows, and what becomes possible once the connections are the data.
Most application security tools store findings in a table. It is the obvious design and it works fine right up until someone asks a question that spans more than one row.
The questions that break the table
Consider four questions a security analyst asks in an ordinary week:
- Is this finding reachable from the internet?
- Would upgrading this one package close anything else?
- Do these three medium findings combine into something critical?
- Why was this severity downgraded eight months ago?
None of these can be answered by looking at a finding record. Each requires moving from the finding to something else: to the service topology, to the dependency structure, to other findings, to a decision history.
In a table-oriented model, every one of those is a lookup someone anticipated in advance. Questions nobody predicted have no answer until the schema changes.
Relationships as first-class data
The alternative is to model the connections themselves. A rule detects a weakness class. That class belongs to a risk category. A vulnerability expresses that weakness and affects particular package versions. A fix resolves the class. A finding is an instance of a rule, found in a service, which may or may not be exposed.
Once those connections are the data rather than something reconstructed on demand, the four questions above stop being special cases. Reachability is a question about paths. Blast radius is a question about what shares a package version. Attack chains are a question about findings that connect through common services. Decision history is a question about what is attached to a finding.
None of those required anticipating the question. They required modelling the domain honestly.
Where the leverage shows up
The payoff is not query elegance. It is that explanation becomes derivable.
When a developer asks why a finding matters, the answer assembles itself: this detection fired, it indicates this class of weakness, that class falls under this risk category, these fixes are known to resolve it, and this service is internet-facing. Every claim in that explanation has something behind it.
That is the difference between a tool that tells you something and a tool that can show its work. It is also what makes an answer safe to act on: you can check the reasoning rather than trusting the output.
Two bodies of knowledge
The shared knowledge is the same for everyone: weakness classes, vulnerabilities, risk categories, packages and fixes. Your context is yours alone: services, ownership, exposure, environments and decisions.
Reasoning happens across both. That is why the same finding can be critical in one organisation and accepted risk in another, and why the platform can explain which it is for you rather than reporting a generic severity and leaving you to work it out.
The offline constraint
Knowledge that only works when connected to a live service is not deployable in the environments that need this most. Disconnected deployments run against a signed, versioned snapshot carrying the same structure: the reasoning is identical, the knowledge is simply frozen at a point in time.
Same explanations, no network.