DevSecOps Worst Practices – Artificial Gates

Photo by Alexei Maridashvili on Unsplash

The previous post in this series was Untested Tools.

The third bad practice we will examine is security professionals using a CI/CD to set up a gating process, artificially. No one agreed to the gating process, they have set it up this way in secret, pretending this is not the case. 

Back when I first started working in security we had gates. We had to approve every single thing that went to production. I remember being surprised by the attitude of security people I worked with, them saying that the developers had to jump through our hoops, or else. When DevOps came, things changed. The developers didn’t need to wait on us, and they just weren’t willing to anymore. The developers needed to move fast, release features quickly, and beat the competition. We couldn’t just make them wait for three weeks because we were busy, our tools were slow, or we couldn’t keep up. They were going to continue without us, whether we liked it or not.

When I started working in DevSecOps in more different places, a lot of security folks expressed concerns. I remember someone who I like very much, being extremely frustrated, and saying “They’re going too fast! They’re going way too fast! I don’t know what to do anymore! I can’t keep up! I want to stop them!” I explained that we had to work in different ways, use more modern tools, and adjust. The look on her face wasn’t anger, it was fear. She was upset because she was afraid she couldn’t keep up, and she would miss something important.

After a while, I started seeing organizations that would use the CI CD to create a pretend gate. The organization had agreed that there would not be a gating process anymore, and that things would be approved automatically, or with fast change management processes. But then one or more security people were intentionally configuring tools to break the pipeline, and stop the build. It took me a while to figure out what was happening, because they would tell me they had not created a gate and “we don’t do gates here”. But what it looked like they had done was break the build so they could add more time to the process, so that they could catch up to the software developers. They couldn’t keep up, and rather than letting things go out to prod anyway, they felt it was safer to stop them. Safer to wait. Or at least that’s how it looked to me.

The problem here is obvious, this one person decided to change the policy of the entire organization without permission. They decided on behalf of everyone else, silently, that if they didn’t have enough time, every other person on the entire team would wait. This is against the first way of DevOps, which is emphasizing the speed and efficiency of the entire system. Plus, it’s not OK for one adult to decide to control all the other adults and lie about it. And every time I’ve seen this, it looked like lying/hiding to me. 

What’s so bad about gates?

You might be thinking; what’s so bad about gates? What’s so bad about waiting a couple extra days? What’s so bad about the old way of doing things? Let me tell you!

First of all, someone adding artificial gates completely negates all of the hard work that all of the teams did in order to make DevOps work. So they have undone everyone else’s hard work, and obviously that’s not cool. Let’s continue!

• Artificial gates will create a slower time to market, which ruins the #1 advantage of DevOps.
• It can create bottlenecks within the development process, specifically waiting for the security team to get their acts together. If everyone has to wait on them, it slows everything down. That means the teams can’t be agile, which means they often stop innovation, and also negates any sort of competitive advantage.
• If one person is waiting on the security person, then they probably aren’t getting anything else done. And that means inefficiency and wasted time. This means that we’re wasting money, time, and quite frankly it probably also means people are less happy in their jobs.
• Generally most people agree that gated security systems cost more. Read the book Accelerate to learn more.  
• When we do a gated process, we create silos. The security team is the first silo, the development team is another silo, and sometimes the OPS team is yet another silo. This means a lack of collaboration, they share less information, and it certainly doesn’t build trust between teams.
• The last one is something I hadn’t thought of, but a friend suggested it to me. A gated system often shifts the security responsibility onto the security team. It makes the developers, DevOps folks, and operational people feel that the security team is responsible for the security of their products and systems. This can lead to a culture where it seems like the security of the products they build is not part of their responsibility, which it is. When we weave security through DevOps, it becomes part of the main value stream, which means that it is part of every single person’s shared responsibility. Gating reverses this culture change.

As you can see, there are several reasons why we do not want to go back to a gated security model. If someone on the security team expresses that they need more time to get something done, the answer is not to create artificial gates that no one else agreed to. The answer is that we need to work together, collaborate, and innovate. Perhaps we need to switch out our tools and get more modern tools that work better with our systems? Perhaps we need to do our work in a new way? Perhaps we need to drop some of the things we’ve been doing, and adopt different ways of doing security? The answer is brainstorming, working together, and making a decision as an entire team. The answer is never that one person decides in silence and secrecy, undoing the hard work of everyone else.

Up next we’re going to talk about missing test results!