Much of the DevSecOps conversation revolves around “trust but verify” – and that verify part has become almost a drug. We keep buying new tools, adding new checks, and building up what feels like trust but is actually confidence. Confidence is historical probability: if the build passed 100 times, it will probably pass again. Trust is something fundamentally different.
Continuous verification – a term coined by Aaron Rinehart – never stops. CI, CD, and now continuous security all layer verification on top of verification. But John Allspaw’s thought experiment exposes the gap: how long can your systems run without human intervention? A day? A week? Eventually everyone admits the humans are part of the system. Remove them and it decays.
The cost of distrust is real and often overlooked. More tools means more cost. More meetings for approval means more delay. The biggest friction point is backlog prioritization – developer-first versus security-first versus ops-first. Professor Gunther Dueck calls optimizing for a single dimension “the definition of stupidity.” The blended backlog needs to mix features, architectural work, bugs, technical debt, and security, weighted by urgency and cost of delay.
Promise theory provides the framework: every agent makes promises, but cannot make promises on behalf of others. You cannot guarantee the system is secure. You can promise you ran these checks, you deployed these controls. When promises conflict, open discussion is the only path forward. Creating choices – multi-cloud, abstraction layers, redundant approaches – is how you keep your own promises when others fail theirs.
The Thin Book of Trust identifies four pillars: sincerity, reliability, competence, and care. These apply identically to evaluating an open-source library. We check competence (tests, CVEs, documentation), reliability (release cadence, community activity), sincerity (code of conduct, changelog transparency), and care (pull request responsiveness, time to fix vulnerabilities). What is interesting is that we generally think of others as less trustworthy than ourselves – we judge ourselves by intentions, others by behavior. The work of DevSecOps is becoming trustworthy to others, not just demanding trustworthiness from them. Trust builds slowly and breaks fast. There are no shortcuts.
Watch on YouTube – available on the jedi4ever channel
This summary was generated using AI based on the auto-generated transcript.