DevSecOps is a practice that combines the efforts of the development (Dev), security (Sec), and IT operations (Ops) teams to produce the most efficient and successful software development processes. But why is it so uncommon? Let’s examine the challenges of implementing DevSecOps and the solutions to overcome them.
Why DevOps as opposed to DevSecOps?
When it comes to the software development lifecycle, DevOps is primarily intended to work in conjunction with agile approaches (SDLC). Delivering software in short, efficient release cycles is a crucial objective, as is streamlining and automating as much of the development process and the software delivery process as is practical. In order to have an agile software development process, the build and test processes must be fully automated. This is where DevSecOps’ CI/CD pipelines come into play.
If the build and test operations that are part of the development cycle were still done manually, DevOps would not be viable. However, no one appears to have considered the integration of security in the initial approach to DevOps. What makes you think that’s the case?
DevOps CI/CD pipelines often involve these steps:
- Establishing an environment that is already set up (e.g. a Docker container via Kubernetes)
- Initiating and maintaining the software
- Preconfigured red environment for deployment of the application.
- Confirming that the generated application’s functionality fulfils the criteria using automated tests (for example, Selenium UI tests)
It seems only logical to add an extra step to that pipeline:
- Verifying that the compiled program is secure using automated security tests
But this is not the case in most DevOps situations-that is why they are not DevSecOps processes.
Reasons for not adopting DevSecOps
DevOps implementations that are successful generally do not incorporate any security practices. Let’s look at why this is the case.
1. Insufficient security awareness
In our opinion, many firms don’t include security measures in their DevOps processes because they don’t believe that producing secure software is critical enough.
Cybersecurity is still largely a mystery to many firms, even those undergoing digital transformations, who see it through the lens of media attention given to ransomware and phishing. Ransomware and phishing are huge security threats, and there is nothing you can do in the development pipelines to reduce these risks, but that’s only part of what security is.
Black-hat hackers can also easily exploit a vulnerability in an application to gain access to sensitive data or even take control of the program or entire server. Organizations often fail to recognize this. Further attacks, such as the infamous ransomware, are possible as a result. For example, a black-hat hacker could use your cloud-native web application to install a reverse shell and, for example, deliver ransomware that would spread over your entire system and cause complete chaos. Moreover, a lack of application security is the main reason, and no ransomware or phishing protection would help you in this situation.
As a result, the first and most critical step in implementing DevSecOps is enlisting everyone and emphasizing shared accountability, especially among those in positions of authority. They need to understand the value of writing secure code. They must help you on your road to DevSecOps.
2. Lack of security knowledge
Because their work is so little understood, security teams frequently operate in isolation. The term “security” has a wide range of meanings. A deep penetration test is not the same as setting compliance monitoring methods and spreading awareness to secure your organization. It necessitates a different set of abilities. Furthermore, even seemingly unrelated fields of study, such as network and application security necessitate a separate set of skills, tools, and security regulations.
Because of a lack of awareness, security responsibilities are viewed as “that thing that we check at the end” instead of “that thing that we check as we create and deliver” because of a lack of awareness. Many security experts have a background in network security and therefore do not fully grasp the notion of application security. Since they only focus on network security, which is not something you need to care about when developing an application, DevSecOps is not possible for them.
That many firms prefer to keep their security policies under wraps is a disturbing concept, given the number of catastrophic security breaches that have occurred in recent years. Just have a look at the well-known Capital One hack of 2019.
3. Lack of expertise in security automation
Even today, many people think of information security as a purely manual endeavor. Many organizations believe that manual penetration testing is the most important component of testing an application’s security. Manual tools such as caching queries and sending payloads are frequently used by penetration testers in their job.
Security services have evolved much beyond manual testing, though. Modern application security engineers employ automated methods to uncover the most prevalent vulnerabilities, like how network security experts don’t submit manual instructions via Telnet but instead use automated scanners. For security engineers, it’s a no-brainer because they’ll be able to spend their time investigating more advanced flaws rather than sifting through yet another simple SQL injection.
Automated vulnerability scanning has largely supplanted manual penetration testing, save in rare circumstances. As with UI testing, manual penetration testing is still used to find issues that can’t be found automatically. It’s about as modern as manually navigating through the UI of an application instead of using Selenium to test the security posture.
4. A lack of trust in security software
Some solutions have limited capabilities, even when an organization is fully on board with DevSecOps, and the decision-makers are on board with the necessity of application security.
Imagine a DevOps pipeline with automated tests that frequently fail, even though the tested application is correct. It’s difficult to fathom the amount of time it would take for developers to return to the development environment. go through all the application code, and then contact the testing team to have the automated tests fixed (or simply, if possible, mark the tests manually as passed). Even more so if this situation persists.
This is a rare occurrence in automated unit testing. Static application security testing (SAST) is a common practice in the realm of application security testing, where code analysis tools are frequently used. And because the tool is typically a third-party product, the developer grappling with a false positive cannot ask the test development team to correct the tool.
Because of this, the introduction of DevSecOps methods typically fails. Introducing automated security testing into the pipelines may excite DevOps team members at first, but when they implement it using one of the many static analysis tools marketed as the best choice for DevSecOps, they discover that it doesn’t work because the number of false positives is simply not tolerable. It’s more likely that DevSecOps will not be considered again if the organization is large.
5. A lack of familiarity with the tools.
For several reasons (see Reason 3), DevOps teams tend to favor SAST over DAST as the preferred DevSecOps tool, and as a result, DAST is rarely considered for inclusion in CI/CD pipelines. This is due to the fact that most DAST solutions are not suitable for DevSecOps due to a lack of automation.
In the open-source community, DAST tools are still seen as the simple, one-time scanners they were just a few years ago. In the past, DAST was used to perform a security scan on a runtime application that was deployed in a staging or production environment, which is obviously not agile at all. A serious security vulnerability discovered during an app scan necessitates a complete rewrite of the app’s development process, requiring a restart of the entire agile cycle.
DAST tools, on the other hand, aren’t all just scanners. A number of these tools, can now be used directly in CI/CD workflows. In addition to being able to work directly with tools like Jenkins, you can configure them to pass or fail depending on the type of vulnerability found, and in terms of accuracy, performance, and scope, they considerably surpass SAST. They’re designed to function in a left-shifting environment.
DAST has a slight drawback as compared to SAST: code analysis tools can pinpoint the exact line of code where a security risk was discovered, whereas DAST cannot. As a result of the modest modifications and additions made to the source code in each build in a typical agile environment, developers may quickly pinpoint the cause of any problems they encounter. There’s a good chance the developer who originally made the changes to a build will be the one who receives a DAST security scan result. To top it all off, certain DAST provides an IAST option (AcuSensor) that combines the best of both worlds at the cost of a little more complicated deployment.
The future of application security can be found here.
How can you overcome the difficulties of incorporating security testing straight into your application development process?
- Ensure that everyone in your company is aware of the significance of application security. Do your best to make them understand that this issue deserves the same level of attention as ransomware and phishing.
- Teach your team that while network security has no place in DevOps, application security must be part of DevOps for your company to be really nimble.
- To prevent DAST tools from being used as simple security scanners, inform everyone in your business about their evolution. Keep in mind that DAST tools are built for inclusion in CI/CD pipelines, and they can do a better job than SAST tools in that function.
