Strategies for Winning the Application Security Vulnerability Arms Race

Thursday, January 17, 2019

Anna Chiang

E35eb0b731ef951516e38fd155abfdf4

As cyber criminals continuously launch more sophisticated attacks, security teams increasingly struggle to keep up with the constant stream of security threats they must investigate and prioritize. When observing companies that have a large web presence (e.g., retail/e-commerce companies), consider the broad threat landscape at play. Web application attacks were responsible for 38 percent of the data breaches examined in the 2018 Verizon Data Breach Investigations Report (DBIR).

To win the vulnerability arms race, security teams need to fight fire with fire by partnering with their own application development teams and enabling them to identify and fix security vulnerabilities in their code earlier in the development process. In doing so, organizations can resolve critical security vulnerabilities before applications move into production, greatly minimizing their risk for costly data breaches.

Catching and resolving vulnerabilities earlier in the software development life cycle (SDLC) makes life a lot easier for security teams further downstream. Shifting left enables security teams to avoid tedious and unnecessary review, greatly reducing their workload and allowing them to focus on the most important security threats to their organizations.

Benefits of shifting left in software development

Various studies from the past decade support the assertion that fixing a software vulnerability earlier in the SDLC is faster, is much less expensive to the organization, and requires fewer resources than fixing a vulnerability in an application that has been released to production.

A 2008 white paper issued by IBM states that “the costs of discovering defects after release are significant: up to 30 times more than if you catch them in the design and architecture phase.” While the white paper was issued a decade ago, this statement is just as significant today.

Obviously, the preferred approach is for developers to resolve security vulnerabilities while they’re coding rather than letting the same fatal issues propagate in countless other places in an application—and then having to return to the lengthy development phases of testing, quality assurance, and final production. Implementing a solution that aligns with development processes allows developers to nip vulnerabilities in the bud as they code, and creates a positive habit that is quick and painless.

Potential software security obstacles

If the solution is so obvious, then why aren’t more development organizations doing it?

  1. Development teams often lack security expertise, and security teams often lack development expertise. Consequently, these teams may feel as if they’re working at cross purposes.
  2. For many years, developers’ highest priority has been to get working software out the door as quickly as possible. If they perceive security testing tools as a roadblock in CI/CD workflows and stringent development schedules, they’ll refuse to adopt them, or they’ll find ways to work around them.

To address these issues, organizations should select the right security tools. These tools should provide developers with technical guidance and educational, contextual support to fix any security vulnerabilities flagged in their code immediately. These tools need to be fast and accurate, fit seamlessly into development workflows, and support developers in producing secure code while also enabling them to hit their release schedules.

What to look for in a static application security testing (SAST) tool

  1. Accuracy. Comprehensive code coverage; accurate identification and prioritization of critical security vulnerabilities to be fixed.
  2. Ease of use. An intuitive, consistent, modern interface involving zero configuration; insight into vulnerabilities with necessary contextual information (e.g., dataflow, CWE vulnerability description, and detailed remediation advice).
  3. Speed. Fast incremental analysis results that appear in seconds as developers write code.
  4. DevSecOps capabilities. Support for popular build servers and issue trackers; flexible APIs for integration into custom tools.
  5. Scalability. Enterprise capabilities to support thousands of projects, developers, and over 10 million issues.
  6. Management-level reporting and compliance to industry standards. Security standards coverage including OWASP Top 10, PCI DSS, and SANS/CWE Top 25; embedded technologies compliance standards coverage including MISRA, AUTOSAR, CERT C / C++, ISO 26262, and ISO/IEC TS 17961.
  7. eLearning integration. Contextual guidance and links to short courses specific to the issues identified in code; just-in-time learning when developers need it.

Security and development teams need to collaborate closely to ensure that enterprise web and mobile applications are free of vulnerabilities that can lead to costly data breaches. Choosing the right development security tool is the first step toward achieving this critical goal.

About the author: Anna Chiang is the Sr. Manager, SAST Product Marketing at Synopsys. She has also held lead roles in application security and platform product management at WhiteHat Security, Perforce Software, and BlackBerry.

Possibly Related Articles:
55107
Enterprise Security Breaches
Application Security Vulnerabilities static application security testing development phases
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.