Reference Delivery Pipeline
Monday, 21 November 2016
One of the pieces of work I’ve been focused on recently is building a strong software security capability for one of my clients. They want to ensure that the services they build and operate in production are secure, but they aren’t able to embed security experts into each team. This is a common theme across the industry as suitably skilled security engineers are hard to come by. In light of recent news about cyber security breaches and attacks, many organisations are looking to invest more heavily in protecting themselves from these kinds of threats. Given the interest from across the industry, I thought it would be useful to share some of my thinking in this space and the work I’m doing.
One of the dangers in writing on this topic is that some may say this is a bit excessive. They’d be right if I was suggesting that everyone adopt all these practices and principles. That’s not at all what I’m suggesting. My objective is to provide food for thought and some practical steps that can be followed to improve the security of your own delivery pipeline. You need to assess your organisation’s risk appetite and identify the threats you’re concerned about in order to drive out your own requirements for a secure delivery pipeline. For example, you’re likely to adopt many of these practices if you’re building software for government systems, air traffic control or the military; but some of these steps are probably unnecessary if you’re building a simple calculator app for mobile phones. Regardless, I hope you find this interesting and helpful in thinking differently about producing secure software.
I’ve used the word pipeline quite a lot already, and in my current situation I happen to be applying this within Continuous Delivery. However, much of what I’m describing does not require Continuous Delivery at all. It maps neatly onto a CD pipeline, but could equally apply to a more basic Continuous Integration workflow or even a less ‘continuous’ environment.
I’ve heard some people talk about building a ‘security pipeline’, but I’m not personally a fan of that term. The reason being that I don’t see security as an additional or parallel sequence of actions that happens alongside other stages in the pipeline. It’s not something you simply add on to an automated process. It’s an attribute of the pipeline itself as well as of the software that is produced by the pipeline.
That’s it for now. Starting with the next article in this series, we’ll take a look at various areas where security can be applied and some of the tools and techniques you can use to tackle various kinds of threats.