Series 1 · Security is a group project · Part 1 of 4 · Site + LinkedIn

The bet

AI has gotten very good at finding problems in software. In the wrong hands, it's getting good at making them too. More findings, in every layer: the code teams write, the open source it depends on, operating systems, containers and platforms, even hardware. And less time to act on each one.

There are plenty of ways to respond: better tools, more automation, faster patching, tightening the processes you already have. My bet is that the biggest gain is easy to miss from inside any one team, and much clearer when you step back and look from the outside in. It's in getting the teams that each hold part of the answer to share it, earlier and continuously, so decisions are well informed from the first look to the last.

It isn't all or nothing. It's a spectrum, and the first decision is how far along it you can go. Everything else is optimization within that choice. Here's why I think that, and what it could look like.

The problem

A scan runs. Security gets a long list of findings. Lists go out to whichever teams own the affected pieces, whether that's an application team, the operating system team, or someone else entirely, often as a spreadsheet, with the expectation that each finding gets closed by a deadline and doesn't show up in the next scan. Then everyone waits to see what's still there.

That was the natural design when the process took shape, and for a long time it worked. Nobody in it is doing their job badly. Security is handed a flood and a deadline, and a spreadsheet is the tool the process gives them. Processes like this harden over time and are hard to unwind. But the first look at each finding happens without the context that would make sense of it. A scan can tell you a flaw might exist. It often can't tell whether it's already been dealt with. A fix may have been applied to the exact version you're running without changing its version number, so it still looks vulnerable on paper, or something else may already be blocking the way in. And it can't tell you whether anyone can reach it, what it would cost the business or its reputation if it went wrong, whether the system can be changed safely and how fast, whether the better answer is to retire it, or who would even do the work. That information exists. It just lives with other people. Exactly what that information is, who owns it, which systems it sits in, and how much of it is shared today deserves its own deep dive, and it'll get one.

Any one of those groups can make a good enough decision on its own, and today that's mostly what happens. But what was good enough a few years ago probably isn't now, when a known flaw can be turned into a working attack so much faster, and the list keeps growing.

My hypothesis

It has three parts.

The more you share, the more you can do. This may seem obvious, but it still needs to be said. The more you can safely relax the boundaries between security, the business, and the teams that build and run the applications and platforms, the further left you can push each decision and the faster it gets solved. You also have more to hand to automation, agents, or whatever comes next, in the right places, over time.

The friction grows faster than the sharing. This one is obvious too, once you think about it for a minute. Each step toward fewer boundaries is harder than the one before it. That's partly because organizations resist it, and partly because the most open versions don't end once they're set up. They need continuous shared refinement across teams that work very differently, long after day one.

The pressure is finally big enough. Not long ago, reorganizing how these teams work together would have seemed foreign, maybe impossible. The environment has changed enough that the pain of standing still may now outweigh the pain of unwinding what worked before. That's the unlock. BJ Fogg's behavior model puts it simply: a hard change happens when the motivation to make it is high enough to clear how hard it is. For a long time it wasn't. I think it is now.

I know where that points, and it's the hard version. So here's how I think about the options.

Three ways it can go

The traditional model has walls with no windows. Findings go over the wall, and a closed ticket comes back. It was conceived and built in a very different era. I see three steps beyond it, each building on the last, from the least change to the most.

Get smarter in your own space. Some organizations will decide the walls and the handoffs need to stay exactly as they are. That's a legitimate choice, and it's still a real change from the traditional model. Each team works with urgency in response to the threat and improves what it controls: which data it uses, where that data comes from, and how the work flows inside its own area, with better tools along the way. It's still siloed, but it's genuinely better. It brings the least organizational friction and probably the smallest gain, and for some organizations it's the right answer.

Add a one-way mirror. The walls stay, and so does security's independence. Security has to be able to make its calls without being talked out of them. But the platform, application, and business teams share their objective context early and often, so security sees in. Instead of waiting to hear that something is closed, security can make better decisions earlier, using facts that only exist in those other teams.

Put doors in the walls. Treat it as a thought exercise first. The walls don't disappear, and each team keeps its own rules, its own decisions, and things it still needs to guard. What changes is the interface. The teams agree on a shared goal and a shared charter. More flows across, in both directions, at two levels. On each finding, the teams stay in conversation from the first look until it's resolved, instead of handing it off once. And on the process itself, they keep refining how they work together as they learn. This is the biggest change from the traditional model. What it buys you is room. We can't reshape the problem. It changed, and it will keep changing. What we can reshape is the solution space, and doors draw the constraints so that space is as wide as it can be. That makes it the setup most likely to find the best answer.

It also asks the most of everyone. It's the most cross-functional of the three, and it has to be maintained. That means ongoing shared work across teams with very different incentives and ways of working, and continuous improvement long after the charter is written. It isn't free, it isn't a one-time project, and it will be the most controversial of the three. I think the gain is worth that cost, but I hold that as a bet, not a certainty.

The further right you go, the less comfortable it gets, and the bigger the levers you get to pull, earlier.

All three can work, for different reasons. The difference is how far each one can take you.

One distinction matters here. Better tools, more automation, and eventually agents will make any of these paths faster. That's what Clayton Christensen called sustaining innovation: doing the current thing better. Redesigning the process itself, who owns what, and how teams work together is a different kind of change. It's harder, and it's where I think the real step forward is.

The catch

I'd start by testing the doors: can we convince ourselves to solve this together? If the answer is no, the other two still work, and I'd pursue them. I just don't think they get you there as well or as fast, or leave you as ready for what comes next.

Taking that leap is a leap, and I won't pretend otherwise. But most innovation comes from releasing a constraint, and the constraints in how we organize and work together are as real as the ones in technology, even in the most regulated industries.

There, the test is whether we can convince ourselves the change still serves everyone it has to, including regulators and the markets and customers they protect. I think it can. It's still a leap of faith. Ben Horowitz would call that the hard thing about hard things, and his books changed how I think about exactly this kind of call.

So what information are we actually talking about sharing? In my experience it comes down to about seven questions, and the answers are spread across more people than you'd think. That's part 2.

I work for a vendor. This series names no products, including my employer's.