From DevOps to DevSecOps: A Guide on Implementing Security into your Development Processes
DevSecOps is a practice that merges the work done by development (Dev), security (Sec), and IT operations teams (Ops) to deliver the most efficient and effective software development practices. But why is it still so rare? Let us take a look at the difficulties of implementing DevSecOps and ways to eliminate them.
Why DevOps but not DevSecOps?
DevOps is a practice meant mostly to go along with agile methodologies for the software development lifecycle (SDLC). The key goal is to deliver software in short, efficient release cycles as well as streamline and automate much of the development and software delivery processes. It is hard to imagine an agile software development workflow without extensive automation of the build and test processes, i.e. without CI/CD pipelines that form the basis of DevSecOps.
It would not be possible to have DevOps if the build and test processes that are part of the development cycle remained manual. However, in the original approach to DevOps, nobody seems to have thought about the integration of security. What could be the reason?
A typical DevOps CI/CD pipeline includes the following steps:
- Providing a pre-configured environment (e.g. a Docker container via Kubernetes)
- Building the application (or an API/microservice)
- Deploying the application into the pre-configured environment
- Running automated tests on the compiled application to make sure that its functionality meets the requirements (for example, Selenium UI tests)
It seems only logical to add an extra step to that pipeline:
- Running automated security tests on the compiled application to make sure that it meets security requirements.
But this is not the case in most DevOps environments – that is why they are not DevSecOps processes.
Reasons for missing out on DevSecOps
Let’s examine the reasons why organizations that successfully implement DevOps often do not include any security practices in their DevOps processes.
Reason 1. Lack of security awareness
It is a scary thought, but we believe that many organizations do not include security controls in their DevOps processes simply because they do not think that delivering secure software is important enough.
Even in the world of digital transformation, many organizations have limited awareness of cybersecurity and perceive it from the perspective of the media hype around ransomware and phishing. While it is true that ransomware and phishing are major security threats and there is nothing you can do in the development pipelines to mitigate such security risks, this is not everything that security is about.
Organizations sometimes do not realize that in addition to social engineering, black-hat hackers can very easily exploit a vulnerability in an application to access sensitive data or even take control of the application or the entire server. This can lead to further attacks, including the dreaded ransomware. If a black-hat hacker is able to, for example, execute remote code using your cloud-native web application and install a reverse shell, they are able to execute commands on a server and, let’s say, deploy ransomware that will spread to your entire environment and wreak total havoc. And in such a case, the root cause is a lack of application security and no ransomware and phishing protection will help you.
Therefore, the first and the most important step towards DevSecOps is getting everyone on board and promoting shared responsibility, especially among the decision-makers. They must realize that secure code is of utmost importance. They must support you in your DevSecOps journey.
Reason 2. Lack of security understanding
Security teams often work in silos simply because their work is not understood at all. The term security encompasses an incredibly wide scope. Securing your organization by implementing compliance monitoring procedures and spreading awareness is very different from securing your applications through deep penetration testing. It requires completely different skills. And even seemingly related areas such as network security and application security are completely different, demand different skills, tools, and a different approach to security policies.
The lack of understanding leads to security tasks being perceived as ”that thing that we check at the end” instead of ”that thing that we check as we develop and deliver”. Many security professionals in current organizations come from a network security background and do not truly understand the concept of application security. They do not see DevSecOps as achievable simply because they mainly think about network security – not something you need to consider during application development.
Again, it is a scary thought that many organizations prefer to stay in the dark about security, with no thought to the main cause of so many major security breaches. Just take the famous 2019 Capital One hack as an example.
Reason 3. Lack of security automation knowledge
Information security is still often perceived as a manual process. Many organizations believe that the core part of testing the security of an application is manual penetration testing. The work of penetration testers is often associated with purely manual tools that help them, for example, cache requests and send payloads.
However, software security services have gone way beyond manual testing. Just like network security engineers do not send manual commands via Telnet but use automated scanners, modern application security engineers use automated tools to discover the most common issues. It is the logical choice for them because then they can focus on digging deeper into advanced vulnerabilities – which for most security engineers is also much more satisfying than checking for yet another basic SQL injection.
