Security people live in a world of “trust no one.” The same thing happened with ops a decade ago – nobody trusted them, shadow IT was born, and people went to the cloud just to get around company policies. Now security is experiencing the same dynamic, with developers finding creative ways around security policies. The default DevSecOps response is “trust but verify” – more tools, more checks. But I am hoping there is a better way.
Promise theory helps frame the problem. Everybody in the system is an agent making promises. Promises should be verifiable, but the guarantee is not there. Just like ops learned that building perfect-uptime architectures was futile, we need to learn that perfect security is similarly impossible. Being resilient and dealing with what we did not anticipate matters more than preventing every possible failure.
The absence of evidence is not evidence of security. If you do not know something is insecure, that does not mean it is secure. CI pipelines build confidence – historical probability that things work – not trust. John Allspaw’s thought experiment (how long without touching your systems?) and John Willis’s degrees-of-freedom question (rigid versus loosely-coupled systems surviving unknowns) both point to the same conclusion: humans are part of the system.
Building a team across dev, sec, and ops requires fundamental trust. The Lencioni model puts trust at the foundation of team effectiveness. Not trusting people is costly – meeting after meeting for approvals, permission-seeking that slows everything down. The Thin Book of Trust gives us four dimensions: sincerity, reliability, competence, and care. What security folks really want from developers hits all four: be on the sprint planning (sincerity), make it part of definition of done (reliability), learn security practices (competence), and make it shared responsibility (care).
The Etsy example is powerful: replacing a five-person blocking approval with a non-blocking notification that trusts the engineer. It is a mindset shift from controlling to enabling. We evaluate libraries the same way we evaluate people – through sincerity, reliability, competence, and care. The work of DevSecOps is becoming trustworthy yourself, not just demanding trust from others. As Deming said, the first step of transformation is the individual.
Watch on YouTube – available on the jedi4ever channel
This summary was generated using AI based on the auto-generated transcript.