close search bar

Sorry, not available in this language yet

close language selection

How to win the application security arms race

Static application security testing helps you find and fix vulnerabilities earlier in the development life cycle, resulting in more secure software.

How to win the application security arms race

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.

Shift left with the right security testing tools

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.

2008 white paper [PDF] 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.

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.

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.

RELATED: How to “shift left” with application security tools, and how not to

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.

RELATED: Enterprise Application Security Buying Guide: How to Build a Powerful AppSec Toolbelt

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

  • Accuracy. Comprehensive code coverage; accurate identification and prioritization of critical security vulnerabilities to be fixed.
  • 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).
  • Speed. Fast incremental analysis results that appear in seconds as developers write code.
  • DevSecOps capabilities. Support for popular build servers and issue trackers; flexible APIs for integration into custom tools.
  • Scalability. Enterprise capabilities to support thousands of projects, developers, and over 10 million issues.
  • 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.
  • eLearning integration. Contextual guidance and links to short courses specific to the issues identified in code; just-in-time learning when developers need it.

Choosing the right development security tool is the first step toward winning the AppSec arms race.

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.

Learn more about SAST

Anna Chiang

Posted by

Anna Chiang

More from Security news and research