Editor's Note: The chapter, "Question Everything" is included in Epic Failures in DevSecOps, Volume 2, which is available for free download.
In the early days of DevOps there was a saying: 'I wouldn’t want my life support system developed by DevOps.' That made sense. You can’t 'fail fast and roll back' a person who died because of bugs in the software. This lesson has much to teach us in DevSecOps too. -- Eliza May Austin in Epic Failures in DevSecOps, Volume 2
Host Justin Miller interviews Eliza May Austin to discover what DevSecOps teams should question.
Excerpt from the Chapter 1, "Question Everything" from the book Epic Failures in DevSecOps, Volume 2.
The biggest challenge with making changes is making those changes stick. I think that’s only one half of the problem. As a security professional, I’m concerned that some things “stick” too well, becoming unchallengeable, infallible, and immovable. They become the new paradigm and anyone who doesn’t “get it” is a heretic. That’s how it was for DevOps ten years ago, and it appears to be the case for DevSecOps today. Don’t get me wrong, I believe passionately in security and I can see the advantages of a DevSecOps approach. It’s just that what I see organizations do on the ground does not always line up with what I believe DevSecOps should be.
In the early days of DevOps there was a saying: “I wouldn’t want my life support system developed by DevOps.” That made sense. You can’t “fail fast and roll back” a person who died because of bugs in the software. This lesson has much to teach us in DevSecOps too. There are times when DevSecOps is the right thing to do. There are times when, despite the name, DevSecOps has delivered some horribly insecure code. We need to get to grips with this before someone outside of Development, Security, or Operations loses faith in us.
