{"id":341,"date":"2024-02-12T00:00:00","date_gmt":"2024-02-11T22:00:00","guid":{"rendered":"https:\/\/blogit.metropolia.fi\/masterminds\/2024\/02\/12\/integrating-security-into-continuous-delivery\/"},"modified":"2024-10-01T12:54:56","modified_gmt":"2024-10-01T09:54:56","slug":"integrating-security-into-continuous-delivery","status":"publish","type":"post","link":"https:\/\/blogit.metropolia.fi\/masterminds\/2024\/02\/12\/integrating-security-into-continuous-delivery\/","title":{"rendered":"Integrating Security into Continuous Delivery"},"content":{"rendered":"

Adopting a DevOps strategy for software development aims to significantly increase the speed of software delivery process by working in small batches and ensuring software is always releasable. This way of working is often called Continuous Delivery. However, the increased speed in software delivery creates challenges for existing security processes and practices. To ensure security concerns are identified before the software is released, security must be integrated into the Continuous Delivery process. This was the topic of my Master\u2019s thesis that has just been completed as part of Metropolia Master\u00b4s studies.<\/em><\/p>\n

When working as a consultant helping organizations with all things around DevOps and Continuous Delivery, I have noticed that security is still often not integrated into the process as well as it could. For sure, most professionals try to think of security while implementing new features and automation. Yet, often I think we tell ourselves that there should be security experts in the organization that will be ultimately responsible for the security of the solution. Here, I can take myself as an example. Although I have discovered many great open-source security tools that could be used at various stages of the software development and delivery process, rarely did I feel like I have the time and mandate to take them into real use in projects. This is a mindset which, I think, should be changed; everyone who contributes to the software delivery should be responsible for security.<\/p>\n

Realizing it as a problem, I turned this challenge into a Master\u2019s Thesis topic when I started my studies at Metropolia. According to my initial idea, integrating the available open-source security tools into the Continuous Delivery processes would provide a fast feedback loop on security threats and vulnerabilities that developers might accidently introduce while working on projects (Vainio 2023). This is what the Master\u00b4s thesis finally achieved.<\/p>\n

What is Continuous Delivery?<\/h2>\n

In my experience, a successful DevOps strategy for software delivery revolves around the concept of Continuous Delivery which was popularized by David Farley and Jez Humble in their 2010 book called \u201cContinuous Delivery\u201d. (Farley & Humble 2010)<\/p>\n

More technical readers will know that continuous Delivery extends the earlier coined Continuous Integration concept and takes it to its logical conclusion: every change to the software should be followed by multiple stages of automated testing to verify that the software is releasable; and if the testing fails, everyone must work together to either rollback the change or fix the issue. These stages are arranged into what is called the deployment pipeline. It is easiest to understand the concept with help a diagram such as the one below:<\/p>\n

\"\"<\/span><\/p>\n

Figure 1. Example of a Deployment Pipeline (Vainio 2023, picture modified from Farley & Humble 2010).<\/p>\n

The deployment pipeline in Figure 1 is triggered by a change to the software\u2019s code base and is then followed by multiple stages of testing. Finally, if tests are successful, the software should reach a releasable state. Given that the team is already working with a deployment pipeline, it presents an opportunity to integrate automated security tests into this process.<\/p>\n

Integrating Security<\/h2>\n

Since Continuous Delivery aims for software that is always releasable, this means that the security posture of the software and the related deployment infrastructure must also be in a secure, releasable state. It might seem obvious by now, but the below diagram shows how security tests can be bolted onto the deployment pipeline:<\/p>\n

\"\"<\/span><\/p>\n

Figure 2. Example of an Enhanced Deployment Pipeline (Vainio 2023).<\/p>\n

As seen in Figure 2 above, security tests fit right into the deployment pipeline. Ideally, the security tests are run in parallel to the existing tests. This is the desired implementation that aims for security tests that don\u2019t slow down the pipeline execution and thus the delivery process. It seems obvious that security should be one of the characteristics of the software that is tested during the deployment pipeline. But as often happens, this simple idea can be tricky to implement in practice unless you are a security expert, and that\u2019s why I wanted to study and discover the practical ways for anyone working on the delivery process to find effective ways to integrate security tests into the process.<\/p>\n

My Master\u2019s Thesis describes a security framework based on these core ideas. Following the thesis, in my company we have internalized this approach and developed additional practical examples and information around the security tools and practices. It is still very early days for the full-scale adoption of the framework, but we have started the journey to fully embrace the idea that security has to be an integral part of everything that we deliver.<\/p>\n

References<\/h2>\n