DevSecOps: How to get there from DevOps | Acunetix

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 that is 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 as much of the development process and the software delivery process as possible. It is hard to imagine an agile software development workflow without extensive automation of the build and test processes, ie without the continuous integration / continuous delivery (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:

1. Providing a pre-configured environment (eg a Docker container via Kubernetes)
2. Building the application (or an API / microservice)
3. Deploying the application into the pre-configured environment
4. 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:

5. Running automated security tests on the compiled application to make sure 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 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.

Just as automated UI testing has almost completely replaced manual testing except for special cases, so automated vulnerability scanning has replaced the majority of manual penetration testing – but penetration tests are still performed for issues that cannot be discovered automatically. Testing the security posture manually in a silo is about as modern as manually clicking through the UI of the application instead of using Selenium.

Reason 4. Lack of confidence in security tools

Even if an organization appreciates the importance of application security and the decision-makers are fully onboard, there is still one problem that hinders DevSecOps: the limited capabilities of some of the tools.

Imagine a DevOps pipeline with automated tests that often fail even though the tested application is actually correct. Imagine how much time it would take for developers to go back to the development environment, review the application code, make sure everything is okay, and then contact the test development team to correct the automated tests so they do not fail (or simply, If possible, mark the tests manually as passed). And imagine the frustration if this keeps happening.

For automated unit testing, this is not a common situation. However, in the world of application security, where testing is often done using code analysis tools (SAST – static application security testing), this sort of thing happens every day. And the developer struggling with a false positive cannot simply ask for the tool to be corrected by the test development team because the tool is usually a third-party application.

This is why attempts to introduce DevSecOps practices tend to fail so often. DevOps team members may initially be excited about introducing automated security testing into the pipelines, but then they implement it using one of many static analysis tools that are marketed as the best choice for DevSecOps and find out that it does not work because the number of false positives is simply not tolerable. And the bigger the organization, the bigger the disappointment – and the bigger the risk that DevSecOps will not be considered again.

Reason 5. Lack of understanding of tools

Partly through lack of awareness (see Reason 3), DevOps teams often focus on SAST as the DevSecOps tool of choice and do not even consider DAST as something that may be included in CI / CD pipelines. And the reason for that is simple: most DAST tools are unfit for DevSecOps simply because they do not offer enough automation.

DAST tools are still perceived as the simple, run-once scanners that they were just a couple of years ago and that are still often developed in the open-source ecosystem. The traditional usage of a DAST tool was to run a security scan on a runtime application that has been deployed in a staging environment or production environment – and that is, obviously, not agile at all. Just imagine what happens when the scan finds a critical security vulnerability – to go ahead with remediation, the app must go back to the drawing board, and the entire agile cycle that it has gone through needs to be repeated.

However, not all DAST tools are simple scanners. Several, like Acunetix, are now made to be directly integrated into CI / CD pipelines. They can work directly with tools like Jenkins, you can set them up to pass or fail depending on the type of vulnerability detected, and – most importantly – they far outstrip SAST in terms of accuracy, performance, and scope of vulnerabilities detected. They’re made to work in a shift-left scenario.

There is a minor downside to DAST when compared to SAST: code analysis tools can pinpoint the line of code where a security issue was found, while DAST cannot do that. However, in a typical agile environment, the code changes and additions in each build are very small and therefore it is very easy for a developer to identify where the problem is in the source code. Very often, the developer that gets a report that a build failed a DAST security scan is the same developer who introduced the changes in the first place. And if that wasn’t enough, some DAST tools like Acunetix have an IAST option (AcuSensor) that combines the best of both worlds at the cost of a slightly more complex deployment.

The way forward for application security

How can you overcome the difficulties of introducing security testing directly into your application development?

• Educate everyone in your organization about the importance of application security. Make sure they realize that it must be given the same attention as more hyped threats such as ransomware and phishing.
• Educate everyone in your organization that network security and application security are two completely different things and while network security has no place as part of DevOps, application security must be part of DevOps for your organization to be truly agile.
• Educate everyone in your organization that DAST tools are no longer the simple security scanners they were just a couple of years ago. Make sure they realize that DAST tools are currently designed to be included in CI / CD pipelines – and they can do a much better job than SAST tools in that role.

THE AUTHOR

Tomasz Andrzej Nidecki
Technical Content Writer
LinkedIn

Tomasz Andrzej Nidecki (also known as tonid) is a Technical Content Writer working for Acunetix. A journalist, translator, and technical writer with 25 years of IT experience, Tomasz has been the Managing Editor of the hakin9 IT Security magazine in its early years and used to run a major technical blog dedicated to email security.