We don’t have a system of record for security

GTM teams solved this with CRM decades ago. Security never built the equivalent.

We run a stack of tools. They tell us what we have... sometimes. They don’t tell us what we decided, what changed, or why.

Assets are in one place. Identities somewhere else. Vulns, tickets, comms, decisions, exceptions... all scattered.

So every request turns into a hunt for context about the thing involved. The asset. The identity. The repo. The vendor. Whatever the question is about.

A high-severity finding fires on a host. Where does it live? Who owns it? Is it in scope for compliance like SOC 2 or ISO 27k? Does it hold customer data? Is it actually exposed, or sitting on a private network behind two layers of controls? Has anyone looked at it before?

Five tabs and a few Slack threads later, you’ve got most of an answer.

Sometimes you don’t. Some of it isn’t written down anywhere. Some lives in someone’s head. Some never got captured.

The decision gets made anyway. Based on whatever we could find at the time. Not the full picture.

Next time a similar request comes in, we do it again.

GTM solved this

CRM isn’t impressive because of any specific vendor. It’s the model. Everything hangs off the customer.

One record. Every email, every call, every quote, every renewal, every lost deal. Every person who’s ever touched the account, with a timestamp and a note about what they did. Reasoning included.

A new rep can open an account, skim the timeline, and have the gist in a few minutes.

CRMs have been around for thirty-plus years. Every GTM function builds around the customer record. Sales. Marketing. Customer success. Support. And the CRM isn’t an island. It’s a hub. It integrates with hundreds of point tools. Marketing automation, sales engineering tooling, email, newsletters, custom integrations with the product itself. The CRM is the centralized platform. Everything else plugs in.

Security doesn’t have an equivalent.

Pick any entity in the environment. Try to reconstruct everything we know about it, every decision we’ve made, every conversation we’ve had, every exception we’ve granted. Good luck.

We’ve accepted this as normal

Two people on my team can talk to the same product or engineering person and get two slightly different answers. Neither answer gets captured anywhere reusable. Next time the question comes up, we ask again.

That’s not a tooling problem. The context lives in the conversation... then it’s gone. There’s nowhere to put it...so nobody puts it anywhere.

You could argue we have tickets. We do...but tickets are time-bound. They capture a moment, not the ongoing state of an entity. Searching across tickets related to an asset gets you fragments, not the full picture. Same scavenger hunt, different surface.

We don’t have the history. We don’t have the reasoning. We don’t have the “why we said yes” or the “why we said no last time.” Every conversation starts from zero. Every finding looks new. Every exception gets re-litigated.

A different model

I started thinking about the model GTM teams follow with the CRM at the center of it all, and wondered if we could apply similar logic to our stuff.

Not just assets. Identities. Systems. Services. Repos. Vendors. Anything that matters from a security standpoint, or anything in the business that touches security.

Each one is an entity. Everything ties back to it. Telemetry. Ownership. Compliance scope. Past decisions. Open and closed exceptions. The Slack thread where someone asked “should I worry about this?” two months ago. Basically anything that helps explain the who, what, when, where, why, and how.

This isn’t asset management. Asset management tells you what you have. This is the context and the relationships around it. What it’s connected to. What we’ve decided about it. What’s changed. Why.

It’s also not the source of truth for the underlying data. The systems that already own that data keep owning it. This is the source of context. The decisions. The reasoning. The conversations. The relationships we’ve inferred. Everything that lives between the records, not in them.

I think the pattern is similar to a CRM, at least from what I’ve seen of one. Central platform. Integrations into a lot of point tools. The difference is what each one is the source of truth for. A CRM owns the customer record. This owns the context layer.

“System of record” isn’t quite the right name for what this is. Source of context is closer. I haven’t landed on the right word for it.

So when something shows up and you ask “what is this thing... and should I care?” The answer is actually there. Without bouncing across five systems. Without guessing. Without making someone reconstruct context they shouldn’t have to reconstruct.

Most of our tools see one slice. EDR sees the host. IAM sees the identity. CSPM sees the cloud config. The scanner sees the CVE. None of them see the whole. And none of them see the human context. The decisions. The exceptions. The “we already looked at this and here’s why we didn’t act.”

That part doesn’t live in any tool today. It lives in someone’s head, or buried in a Slack thread nobody can find.

There’s a working model for this in another domain. AI coding agents and harnesses lean on simple markdown files for context. CLAUDE.md. AGENTS.md. Project READMEs. Plain text, tied to a directory or a repo. The agent reads the context before it does anything.

It works because context is what makes AI useful. Without it, the model is guessing. With it, the model can reason about the actual situation.

We can borrow the pattern. Per entity, captured in something humans and machines can read, tied to the thing it describes. Then humans and AI both have something to work from when a finding fires, a vendor question lands, or an exception gets requested.

This isn’t a new thought for me. I first kicked it around in 2016 or 2017. The barrier was always too high. Hiring developers for a months-long experiment wasn’t a tradeoff I could justify, and I never had the time to build it myself.

What changed is the cost of trying. AI lowers the barrier enough to actually run the experiment. Same lever I wrote about last time.

What I’m building

A rough version of this is already running.

We connect to the systems we already use through their APIs. Asset inventories. IAM directories. Vendor lists. GitHub. The scanners. The ticket systems. Anything that holds data about an entity or a relationship and exposes a way to read it.

Data gets pulled in. Relationships get inferred. Context gets layered on top. The conversation. The decision. The reasoning. Who owns it. What we’ve said before.

None of the source systems get replaced. We’re not building another asset inventory or another vendor list. We’re building the layer above them. The only hard requirement is that those systems have APIs we can read.

We’re still working out how to capture certain types of context, especially the human-in-the-loop kind. That’s a topic for a future post.

It’s messy. Not complete. We may scrap it. We may rebuild it from scratch. We don’t know yet what we’ll end up with. The idea is promising enough to keep building.

Even early... it’s already changing how we look at things.

Stuff that looked critical... isn’t. A “high” finding on a host that turned out to be deprecated, isolated, and unreachable from the internet is just noise. Stuff we would’ve ignored... probably matters more. A quiet permission change on an identity looks different when you can see what it’s actually connected to.

The relationships are doing a lot of the work. Take that same high finding on a host. From the host record, we can see who owns it. What business unit it belongs to. What team is responsible. Who works on it day to day. What other systems it depends on. None of that was sitting on the host record before. It comes from connecting data that already existed in different tools. With those relationships in place, “should I care, and who do I talk to?” has an actual answer.

The tools didn’t change. The findings didn’t change. We just have context now.

Why we create work

I wrote last time that security creates work. This is why.

When we don’t have context, we compensate with process. More tickets. More questionnaires. More “just in case” reviews. Every conversation starts from zero, so we treat every finding like it’s the first time we’ve ever seen it. We push the work onto engineering, compliance, IT... because we don’t have a way to internalize it ourselves.

A system of record is the foundation. AI on top of context is useful. AI on top of nothing is faster slop.

Every automation I’ve talked about gets better when there’s a single place to read from and write to. Intake. Triage. Scope decisions. Vendor reviews. All of it improves the moment context stops being a thing you reconstruct.

Some of the tools my team has built are going to change. The repo-tracking tool from the last post will get replaced entirely by this. Repo scope just becomes a relationship the system renders automatically. Other tools will either integrate to feed context in, act on context, or get replaced entirely.

There’s a longer list of unanticipated benefits we’re starting to see. More on those in future posts.

Not another tool

There’s no shortage of related categories. CMDBs. ASMs. Risk platforms. Exposure management. None of them claim to be a security system of record. Most of them aren’t built for it either.

CMDBs come closest in concept. An entity-centric record with relationships. But the name gives it away: Configuration Management Database. The unit is the Configuration Item. The relationships it tracks are operational. What runs on what. What depends on what. Optimized for change and incident workflows, not for capturing why decisions were made or what conversations produced them. The schema is opinionated and hard to extend. Adapting it for the kind of context security needs is a project of its own.

The rest each do something useful and narrow. ASMs discover external attack footprint. Risk platforms aggregate signals to support risk prioritization. Exposure management focuses on which weaknesses are actually reachable and exploitable. All useful. None of them sit at the center the way a system of record needs to.

The hard part isn’t storing the data. It’s modeling the relationships and capturing the human context. That part is specific to how your business runs. No two businesses do security the same way. Off-the-shelf doesn’t know that we treat ephemeral build infrastructure differently from production. It doesn’t know which engineer owns which repo. It doesn’t know which exceptions we’ve already approved, or what we said to the auditor last quarter.

This is one of those build-vs-buy calls where build wins. Commercial tools are generic by necessity. They have to work across thousands of customers. You end up using maybe ten percent of what they actually do, and you still pay to train people, stand it up, and keep it running. Building it for your own context gets you exactly what you need, configured the way you actually work. Nothing more, nothing less.

That’s not something I want a vendor to define for me.

This isn’t another tool. It’s a different model.

We need a system of record for context and relationships. Something that gives us the why behind what we’re protecting, not just the what.

Better, not perfect

That’s what I’m working on right now.

It doesn’t have to be perfect. It just has to be better than five tabs and a Slack thread.