After going through the differences between DevOps and DevSecOps from the secure software supply chain approach (part I) and stating the automated verification aspects that DevSecOps can help enable (part II), it’s time to move on to a new perspective. This article is going to reveal how DevSecOps can standardize security within an organization and come up with the first steps for starting your transition from DevOps to DevSecOps.
DevSecOps empowers security through guardrails
Following the automated verification, the second capability a DevSecOps-related platform gives to security staff is the ability to put in place guardrails that make developers’ work easier. The notion of “guardrails” means providing baseline templates for secure applications and including code and image scanning tools in your supply chain to enforce the inclusion of secure code and frameworks.
Another good example of a security feature that can be baked into a platform is logging. There are many cases where teams come up with their own logging format and practices for each application. Several clusters of teams could follow the same scheme, but in an organisation with thousands of developers, the security staff would encounter different logging cultures. In this context, centralised platforms are used to standardise the way logs are created, stored, and retrieved. This allows to the security staff to save the time spent on learning and adapting to each application’s logging scheme, on coming up with clever regular expressions to search for errors, or on figuring out how to get a hold of the logs in the first place.
Zero-trust networking is another major set of capabilities to build into your security-as-a-product platform for developers. Most application designs rely heavily on communicating with other components and services over a network. Traditionally, these connections were mostly secured because the network was also considered being so. This isn’t viable anymore as developers are using more and more third-party services over a network, and it would be better for you to make sure that they are applying protocols like requiring Transport Layer Security (TLS) for connections.
All the above mentioned is just one area that security can start standardising. A DevSecOps approach to platforms can also be used to standardise controls like:
- Image signing;
- Data classification;
- Secrets management;
- Input/output validation;
- And more.
Transitioning from DevOps to DevSecOps
Putting into practice everything that was related into this series of articles might sound tricky. Of course, it would be simpler to say that you just need to install the right tools, create, and automate secure supply chains, and hire a security product manager. But it is not enough, even though there is no missing ingredient, or hidden knowledge. The simple secret is to actually implement the DevSecOps approach on a daily basis. And because changing habits might be challenging, here is a set of three steps to help you to start.
Understand your goals
Hopefully, the above has given you an idea of the goals you should have beyond “being more secure.” However, as Chief Information Security Officers and other security geeks will tell you, it is good to start with understanding the trade-offs between capabilities and security policy, your risk management strategy and plans, and the ongoing threats to security. Security is much more than just bugs and hackers and understanding it deeper in the context of DevSecOps should revolve around the goals of the software you are building and the business that software is running.
Map your end-to-end process
This audit should start with looking at the complete, end-to-end lifecycle that takes to get software out the door. Take a hypothetical case of adding a new feature to an existing application and whiteboard out everything that needs to happen, going through all the steps of the process: idea – coding – securing – deploying – running in production – feature testing by a final user. Note the time spent for each activity and the time assigned between them. The waiting time in the between is usually determined by passing off the responsibility from one group to another, for example, from security compliance to audits.
Mapping out your end-to-end process helps get over the local optimisation existing in most organisations. Each team is typically optimised, but the handoffs and coordination across the end-to-end lifecycle are often mixed up. Take this end-to-end stream and ask yourself “how can we improve the security tools and processes at every stage to speed up the release cycle and put in more security controls and policy?”. This is where you can start your transition from DevOps to DevSecOps.
Good luck out there!