Getting ahead of cyberattacks with a DevSecOps approach to web application security

Web applications are foundational to a company’s business and brand identity yet are highly vulnerable to digital attacks and cybercriminals. As such, it’s vital to have a robust and forward-leaning approach to web application security. With an estimated market size of USD $30B by 2030, the term “application security” takes on numerous forms, but one area of heightened relevance in today’s world is the DevSecOps space.

While the formal practice of DevSecOps dates back to the late 1970s, its adoption across the IT and infosec landscape has become much more prominent as the world has become more interconnected and “app-focused.” According to GitLab’s 2023 Global DevSecOps Report, 56% of organizations report using DevOps or DevSecOps methodologies, growing roughly 10% from 2022, for improved security, higher developer velocity, cost and time savings, and better collaboration. 

What is DevSecOps?

DevSecOps is used to describe the integration of security practices into the DevOps and application development processes. DevSecOps seeks to build security into applications, not just build security around an application.DevOps is a methodology that focuses on the collaboration between development and operations teams to create, test, and deploy software quickly and efficiently. By integrating security practices into the DevOps process, DevSecOps aims to ensure that security is an integral part of the software development life cycle (SDLC).

Benefits of DevSecOps

Identify vulnerabilities early: DevSecOps processes help to identify security vulnerabilities early in the software development process. GitLab’s report found that 71% of security professionals reported that at least a quarter of all security vulnerabilities are being spotted by developers, up from 53% in 2022, by incorporating this approach.

Grow budget and reputation: By integrating security testing into the development cycle, developers can identify and fix security issues before they become costly and damage the brand. According to IBM, a single data breach costs $9.4 million USD for an average business in the United States. As modern application programming can draw from a wide array of open source and commercial tools and libraries that will have varying degrees of vulnerabilities (published and unpublished), such as the high-profile Apache Struts, Spring4Shell or Log4j exploits – it’s critical that a well-defined security process be implemented in the SDLC to avoid supply-chain compromise.

Release faster with confidence: By making security a default part of the DevOps process, teams can ensure that security is not overlooked or forgotten in the rush to deliver software quickly. Traditionally, application testing was implemented during the last phases of development, before being sent to security teams. If an application did not meet quality standards, did not function properly, or otherwise failed to meet requirements, it would be sent back into development for additional changes. This caused significant bottlenecks in the SDLC and was not conducive to DevOps methodologies, which emphasize development velocity. 

By integrating security testing into the development cycle and working closely with the development teams, often other bugs and defects that may impact the quality of the software can be found. Nearly 74% of security professionals said their organizations have either shifted security into the earlier stages of development or plan to in the next three years. 

Implementing DevSecOps

Building an effective security program around software development in an organization is often less about the specific tools that are used and more about culture and process. Selecting amongst various Static and Dynamic Application Security Testing (SAST/DAST) tools is typically the purview of the DevSecOps team, just as development teams typically control their CI/CD and IDE tooling. 

While it’s important to choose the right tools that will deliver the most benefit, it’s critical to ensure that the right processes are set up to ensure collaboration and compliance. Friction can occur where some traditional Infosec teams may operate solely with a “red team” mindset that relies on scanning or discovery-only to call out problems. However, DevSecOps team should be invested in mitigation as well, and be useful in assisting with remediation of their findings. Not only does this help break down team silos by fostering better collaboration, but understanding the mitigation efforts or effects means that the Infosec or DevSecOps teams also better understand the impact their findings make.

As an example, an automated scan may produce a result that shows a vulnerability in a particular piece of code or software package. But if the security team doesn’t have the proper context about how and where the code or package is used, it limits their ability to help with remediation, and adds to a developer’s workload – plus slows dev teams’ velocity. Efficient workflows come when one team can identify system weaknesses, launch test attacks, conduct vulnerability scans, and implement a stronger defense system. Effectively, one team can play the red and blue team role, gaining buy-in from the development team while allowing the DevSecOps teams to ship code faster while still adhering to the proper security protocols.

Other best practices of DevSecOps include incorporating threat modeling into the process. Popular threat models and kill chains that have demonstrated effectiveness over time include the STRIDE framework and MITRE Att&ck matrix. In the web application space, a cloud or CDN-delivered advanced Web Application & API Protection (WAAP) solution, such as Edgio’s,  enables organizations to perform virtual patching for back-end systems that have underlying vulnerabilities or that may take time to fix or upgrade. 

For organizations that are new to embracing DevSecOps in their processes, starting small with a pilot project is often the best approach. While the multitude of automated tools and scanners are effective at identifying potential vulnerabilities, having similar automated methods of tracking and closing issues and providing measurability is equally important in reducing overhead and friction with development teams.

Wrapping up