The Best Security Controls Don't Feel Like Security

Security succeeds when it changes the environment, not the developer.

For years, vulnerability management has followed a familiar pattern. A security scanner identifies an issue, a security engineer reviews the finding, a ticket is created, and eventually that ticket finds its way into a developer's backlog. If the issue isn't addressed quickly enough, we often conclude that the problem is prioritization, security culture, or a lack of developer awareness.

I don't think that's the real problem. We can look at research of human decision making in adversarial systems, particularly why intelligent people make predictable decisions under pressure. The research spans behavioral economics, organizational theory, cognitive psychology, and systems engineering, but one conclusion appears repeatedly: people don't make decisions in isolation. They make decisions within environments that shape what information they have, what incentives they respond to, and how much cognitive effort they can devote to a problem.

That principle applies just as much to software development as it does to help desk social engineering. Consider what happens when a developer receives a vulnerability ticket several days after writing the code. By that point they've mentally moved on. The architecture they were working on has faded from short-term memory, new features have taken priority, and the original design decisions must be reconstructed before they can even begin evaluating the reported issue. The ticket itself often contains pages of scanner output, compliance mappings, CVSS scores, and technical language intended for security professionals rather than software engineers.

Behavioral science predicts exactly what happens next. Herbert Simon's work on bounded rationality demonstrated that people rarely optimize decisions when operating under uncertainty or time constraints. Instead, they satisfice, choosing the first acceptable solution rather than searching indefinitely for the optimal one. John Sweller's research on cognitive load reached a similar conclusion from a different direction, showing that working memory is a limited resource. Every unnecessary interruption, context switch, and additional piece of information reduces our capacity for careful analysis.

A traditional vulnerability ticket creates both problems simultaneously. It forces the developer to reconstruct an abandoned mental model while simultaneously asking them to interpret information that often isn't necessary to fix the issue. The resulting friction is not evidence of poor engineering discipline. It's a predictable consequence of how human cognition works.

Organizational economics reinforces the same conclusion. Principal-agent theory explains that different groups naturally optimize for different objectives. Engineering organizations are generally measured on delivering reliable software, meeting release schedules, and creating business value. Security organizations are measured on reducing organizational risk. Those objectives overlap, but they are not identical, and neither side is behaving irrationally by responding to the metrics that define success within their own organization.

Holmström and Milgrom extended this idea even further by demonstrating that when people are responsible for multiple tasks but are primarily rewarded for one, effort naturally shifts toward the rewarded activity. Every engineering leader has seen this effect. If feature delivery dominates performance discussions, security work becomes something that competes with delivery rather than becoming part of delivery. Adding more vulnerability tickets doesn't eliminate that conflict. It often amplifies it.

This is why I believe we need to stop thinking about "shifting security left" and start thinking about shifting secure decision making to the moment when developers already possess maximum context.

The best security organizations I've worked with don't expect developers to become security analysts. They redesign the development environment so that secure decisions become the easiest decisions. Security findings appear directly inside the IDE while the code is still fresh. Build pipelines identify issues before a pull request is merged. Code review tools provide concise explanations of the problem, explain why it matters in the context of that specific application, and recommend practical remediation. Developers are not expected to interpret scanner output or navigate compliance frameworks. They simply receive the information they need to make the next correct decision.

Notice what changed. The security team didn't disappear. Their role became more valuable.

Instead of manually triaging thousands of findings and generating tickets, security engineers become architects of the decision environment. They build the detection logic, tune the rules to reduce false positives, improve remediation guidance, and create guardrails that fit naturally into the software development lifecycle. Developers remain focused on writing software, while security focuses on designing systems that make secure development the path of least resistance. Security also becomes the escalation path for the genuinely difficult problems rather than the mandatory stop for every vulnerability.

The outcome is a workflow that aligns with how people actually think and work. Vulnerabilities are discovered while context still exists. Developers receive only the information they need. Security expertise is embedded into the tools developers already use instead of being delivered later through an external process.

For decades we've tried to improve software security by changing people. We ask developers to learn more security, security teams to write better tickets, and managers to prioritize remediation more aggressively. Behavioral science suggests a different approach. Change the decision environment instead.

When the right decision becomes the easiest decision, secure software stops being something developers have to remember to do. It simply becomes part of how software is built.