I recently had a conversation with a CISO at a major automobile manufacturing company who uses a DevSecOps strategy and so I started inquiring about it. What I discovered was a definition of DevOps which was terribly unsecure. I later asked around and I discovered this was not a single case, most companies who claim to be DevOps or DevSecOps are defining it the same way. Now I may have homed in on the security area as it is one of my specialties but there are so many other pieces of the puzzle being missed here. So, let me tell you a bit about how the conversation went. We will call the CISO Ralph (not the real name, to protect the guilty)
When I found out they were DevOps I asked Ralph what their deployment procedure looked like. He said it’s simple, the DevOps team oversees everything, the write, test, deploy and maintain the systems and code. I asked what kind of QA they have, how they are testing for security flaws, bugs… etc. Ralph said that the developers oversaw all that. It was up to them to write secure code. If there was a security flaw it was their fault and they were required to remedy it.
At this point I was a bit confused. This was a major car company. They must have something in place. So, I assume they do cross checks between the developers in the department. Passing the code to a teammate to have them check it before it goes into production. Not only do they not do this, the culture they have built disallows it. Ralph
has pushed the “You are in charge of your own code” mantra so hard none of them will share what they write. I’m nervous for their company at this point. How do you check the code for bugs? security flaws? inefficient coding? Ralph responds, “We trust our DevOps team, they should know how to write code without those problems.” I can’t believe a “security professional” (the CISO) would let this happen to their company. At this point I must ask the big question. The one I hope will get Ralph to realize how dangerous this is. “So, you have no active security testing within your development cycle and you’re relying solely on your customers to find bugs and security flaws within your software. ” Ralph responded with “Well yes, that is how DevSecOps works after all”
After we chatted, I went online and did a little research of my own. It seems their software had been completely rooted, the private encryption keys they had “hidden” in the system were available on the dark web and there were even YouTube videos explaining how to get around almost every feature in the software (including how to break into other systems on the vehicle through their software)
The more I have noticed how companies are defining DevOps the more worried it makes me and those implementing DevSecOps are making it even worse. It’s great your company is saving money by not hiring multiple teams; however, that does not mean you get to skip testing and active security. You are just asking for trouble. At a minimum you need to have a second set of eyes look at every piece of code which goes into production. This can be a separate QA team, an outside service or just trading code and jobs among the department. Every person, no matter how smart or honest you think they are, makes mistakes. Just because you know who made the mistake does not make it go away. In addition, this practice is creating silos of knowledge. If one the person running the silo is removed, their knowledge goes with them.
I have been in companies and worked on projects where DevOps works. For it to work, basic security practices still need to be in place. Teamwork needs to be part of the culture. No piece needs to fall onto the shoulders of a single individual. I know companies are looking for ways to build things efficiently, but you also need to build it smart. Let’s not allow our want to save money on staff overshoot our need for a robust security department.