Companies have for some time been focused on digitally transforming the business, especially in reaction to the COVID-19 pandemic. For developers, that means adopting an agile development methodology in a framework such as DevOps.
Yet DevOps teams have to move beyond the basic four categories of application security tools (static analysis, dynamic analysis, interactive testing, and software component analysis, or SCA), according to experts. The entire team—developers, application security professionals, and IT operations—should incorporate tools and processes that support the full DevOps lifecycle, said Guy Podjarny, co-founder and president of software security and services firm Snyk.
“Those classes of tools are no longer sufficient in the world of cloud-native applications. All of those tools—outside of SCA—are about finding vulnerabilities in your custom code, but increasingly that is only a portion of your overall application and only a small part of your risk.”
—Guy Podjarny
While recent recommendations for application security have suggested that more security processes be adopted by developers—in a move known as “shifting left“—companies need to find tools that support all the various functions inside a DevOps team, from developers to quality control to operations, as discussed in TechBeacon’s Buyer’s Guide for Application Security Tools 2021.
Developers should use software component analysis and in-pipeline static code analysis to reduce vulnerabilities in code, while IT operations professionals need to move beyond web application firewalls and focus on containers and other infrastructure, according to the report.
Here are five key trends shaping the shift to more secure development and deployment of software.
1. Security requires more than few classes of tools
Application security is often boiled down to four classes of tools: static analysis security testing (SAST), dynamic analysis security testing (DAST), runtime application self-protection (RASP), and software composition analysis (SCA). However, securing the entire application development and deployment pipeline requires a far greater set of tools and processes.
Unit tests and linters help keep errors from becoming vulnerabilities. Threat modeling and attack testing give DevOps teams insight into how their application could be attacked. Container security and infrastructure controls can help prevent vulnerabilities from affecting deployment. And ongoing analysis of actual attack data can keep teams updated on the latest attacker tactics.
The focus should be to incorporate security considerations during every step of the DevOps process, said Rohit Sethi, CEO of Security Compass, a security services firm.
“Software development still emphasizes and promotes the ‘find-and-fix model,’ which is one of the biggest perils of the security industry. Even if you shift left to scan for vulnerabilities earlier in the lifecycle, there is no substitution for building in security and compliance in by design.”
—Rohit Sethi
2. Threat modeling becomes more important
In November, a group of 15 cybersecurity professionals created the Threat Modeling Manifesto as a way to call attention to businesses’ needs to better understand their risks. The document, modeled after the Agile Manifesto that is the basis of the agile development movement, promotes security as an ideal goal that takes continuous work and threat modeling as a way to understand the journey.
Security needs to become more proactive, and threat modeling is one of the core tools that security teams and DevOps partners have to focus on understanding threats and create a secure architecture based on their risk profile, said Security Compass’ Sethi.
“Planning tools are underappreciated in this arena. Most of the tools—SAST, DAST, IAST/RASP—are reactionary tools focused on find and fix.”
—Rohit Sethi
3. Introduce security in simple ways to succeed
While the simple static code analysis tools known as linters that flag defects and code-quality errors to developers are widely adopted, they are not a replacement for the more in-depth, automated analysis provided by commercial SAST. That said, they are an excellent way to insert code-checking into the development process, allowing DevOps teams to adopt better technology as their processes and skills mature.
Don’t ignore the ability of linting to gradually introduce developers to security testing, said Dan Cornell, chief technology officer of software security consulting firm Denim Group.
Linting SAST tools and commercial-grade SAST tools have different enough characteristics that their deployment scenarios are potentially very different, he said.
“The linting-style SAST tools can be a great entry point into deploying SAST, especially for organizations looking to incorporate security testing into pipelines to give some visibility to developers.”
—Dan Cornell
4. More focus on open source and third-party suppliers
DevOps teams also have to expand their focus beyond their own code and look at the application and infrastructure components that create their software stack. While companies have increasingly adopted SCA, tools that measure the security of the containers used to host applications are only starting to take off.
Like open-source components that now make up more than 70% of the code in an average project, containers are the third-party infrastructure component that many companies rely on for deployment.
Companies should appreciate that. Since they require their development teams to also manage containers and infrastructure, they need to equip them with the tools to do so securely, said Snyk’s Podjarny.
“That means including container security in the context of software development, not just runtime, and infrastructure as code, such as securing Kubernetes configuration, Terraform clusters, and others.”
—Guy Podjarny
5. Mistakes continue to be the greatest threat
Cloud-native development teams can easily deploy their application, but also often find fewer checks in place to prevent mistakes. For that reason, tools that examine the security of cloud environments have become more popular, from checking the configuration of Amazon S3 buckets and MongoDB databases to finding insecure implementations of APIs and accidentally published development keys.
These tools can help teams developing cloud-native applications identify potential risks in the environments into which they’ll be deployed, said Denim Group’s Cornell.
“Cloud-native development teams need better frameworks to make sense of these disparate sources of potential vulnerabilities and weaknesses in order to prioritize remediation activities.”
—Dan Cornell
Focus on DevOps team maturity
The trends are different for every team. The approach a company should take to incorporating more security tools and processes into its DevOps pipeline is not determined by the tools, but by the DevOps team’s maturity, said Denim Group’s Cornell:
“Tool deployment priorities really aren’t tied to years or periods of calendar time. Instead, organizations should look at the level of maturity of their testing programs, their goals, and select next steps based on those criteria.”