Suppose you told a bunch of scientists to make the most nutritious food item possible. There's a good chance it would look, smell and taste like dirt, but would contain every essential nutrient to sustain life.
Now imagine you told a second group to make the most delicious dish possible. After analyzing the chemistry of human taste, they might come up with something wonderful to eat but insufficient to live on. (And it would be chocolate, obviously.)
But if you let the two groups work together to make something both nutritious and tasty, you would end up with a product much better suited for the real world.
Okay, maybe a little more explanation is necessary. DevOps brings together development teams and operations teams to make sure the application doesn't just work, but works in the real world, with real customers. It also speeds up the software development life cycle because development and testing are done at the same time.
Now imagine you left the kitchen door unlocked and someone came in and stole the most delicious, nutritious item of food ever created…
Okay let's skip a bit here. Security is also an essential ingredient of application development and many smart companies are adding it to the DevOps recipe. This creates an even more comprehensive, streamlined process that results in a more secure application. And it's called DevSecOps, which sounds even cooler.
Just in case the whole bake-off metaphor hasn't fully explained DevSecOps to you, don't worry. Just remember that, at its core, DevSecOps is about integrating security at every phase of the DevOps development cycle, from initial design and coding to testing, deployment and running. This allows practitioners to identify and remediate security vulnerabilities much earlier in the DevOps cycle, creating better quality code and fewer fire drills in later stages.
The reason why that last paragraph sounded so much more business-like is because we stole it directly from our ebook, Six Pillars of a Successful DevOps Practice. You can download it for free, and we'll also give you a taste of it right now.
In the real world, silos perform an invaluable function, giving farmers a place to store grain. Sometimes they explode, which is costly and dangerous and also frightens the cows. But in general silos are considered good, and are often picturesque.
In the corporate world, nobody has anything good to say about silos. When it comes to implementing DevSecOps, you'd better not be some sort of secret silo-lover, because guess what?
Development teams, operations teams and security teams have gotten used to doing their own thing their own way. In order for DevSecOps to work, they need to work together. They can start by aligning on a common set of objectives and KPIs. This is obviously going to change the way each team works, and there may be some hiccups in the early stages. But for DevSecOps to truly work, everybody involved needs to be pulling in the same direction.
Let's just get this out of the way: If you're going to change the way you do application development, operations and security, you might need to buy some new stuff. While DevSecOps is primarily a change in mindset and a philosophy of cooperation, the tools you've been using and processes you've been following will probably need to be upgraded. In order for development, security and operations to move forward at the same pace, they all need an integrated view into the process that works with their particular specialty.
The good news is that making changes to give all the teams in the DevSecOps workflow the tools they need also means consolidating your data and its relevant insights in one view. If you choose the right tools, not only can they benefit your DevSecOps team, they will provide significant value across your entire organization.
Remember the unlocked kitchen, where someone left our perfect dish out on a table and it got stolen? There's a reason why security is such a large and important part of software and application development. Nobody wants to be the next company responsible for a major data breach that shows up on the evening news, or wherever it is people get news from these days. TikTok, possibly.
Traditional application security processes can seem slow and ponderous compared to the speed of development. But you can't speed up security if doing so will compromise safety. So how can you make sure your security process doesn't drag down your nascent DevSecOps practice?
The answer, as usual, is robots. Sorry, not robots. Automation. Some security teams have resisted the data-driven machine learning tools that other parts of the organization have embraced. Well if you want DevSecOps to work, now is the time to go out and give those data-driven machine learning tools a great big hug.
Just like DevOps, DevSecOps needs automation for speed and accuracy and to make sure that teams follow protocols and best practices. Automation also vastly speeds up response time when incidents do occur and provides greater visibility to help pinpoint and solve the problem.
Automation is not a panacea, but it is an essential element to ensure your DevSecOps practice has the best chance of succeeding.
There is an ancient parable about eight blind men each trying to describe an elephant based on what part of the elephant they touched. Nobody ever talks about how the elephant feels about this experience. Much like cows surrounded by exploding silos, the elephant probably felt anxious and irritable.
In a DevSecOps environment, everyone involved needs to have a clear and consistent picture and context, lest they also become anxious and irritable. The best way to accomplish that is by making end-to-end visibility a key goal of your DevSecOps practice from the beginning, and make sure all teams involved are able to get a dashboard view of not only the data that is most relevant to them, but what is going on with their counterparts.
It's probably a bad idea for us to go back to our perfect dish analogy, but let's do it anyway. If someone breaks in and steals it, that's a security problem. If somebody tries it and finds an unappetizing chunk of undercooked quinoa, that's a quality problem.
In the application world, security problems and quality issues are often treated as two separate things. Unfortunately that means that the security team and the quality team are not sharing information that would help them each see the big picture.
In a DevSecOps environment, it's extremely helpful to treat security vulnerabilities as quality defects. Not only does it increase visibility, it can prevent developers from unintentionally deprioritizing security defects. If both security and quality findings are shared in one view, it encourages the development team to treat both with equal importance.
In the event of a silo explosion, there's a lot that needs to be done right away. You have to figure out what caused it, where all your grain went and also calm down the cows. In the event of an issue with application security, development or operations, there's also a lot to be done and cows are usually not involved.
In DevSecOps, it's vital to include all groups in the post-incident response strategy. Learning from an issue and preventing it from happening again is obviously the most important goal, and each team can have a different perspective that needs to be considered. Tracking is also essential. Even if the issue is assigned to one group, other teams may sooner or later need to become involved. Having shared tools and visibility makes the job much easier and more efficient.
DevSecOps is one of those advancements that comes along at the right time and makes perfect sense. There's a reason why forward-looking organizations are adopting the process.