In-depth app sec analysis comes at a cost—but so does a breach

There's a cost for doing in-depth security analysis of an application's code, but a data breach is also expensive. The recently released 2021 Verizon Data Breach Investigations Report shows that, once again, web applications remain one of the top attack vectors, with 4,862 incidents reported, 1,384 of which were confirmed to have leaked data.

A typical example of how weaknesses in an application can result in a data breach was recently reported by KrebsOnSecurity. An API weakness in the website of an Experian partner let anyone with a name and a mailing address look up someone else’s credit score, a vulnerability that affected millions of Americans. You can find examples like this data breach in the news nearly every week.

Despite the high stakes of these data breaches, we're seeing a concerning development among organizations. One of the trends identified in the Application Security Top Trends for 2021 white paper is the increasing use of hyper-convenient security scanning tools that cloud platform and development tool chain vendors are offering. These lightweight static analysis security testing (SAST) tools are used by development teams to comply with security scanning requirements, many times as an alternative to using more robust SAST tools.

While exploits through application vulnerabilities are on the rise, less capable SAST tools are increasingly being used to try to identify these vulnerabilities and weaknesses. Is your team setting up your organization for a potential breach by taking shortcuts on thorough application security testing during development?

Why SAST?

The purpose of SAST is to help programmers detect vulnerabilities in their software as early as possible. They are managing application risks and need visibility into application weaknesses and vulnerabilities to properly manage that risk effectively. I don’t believe they should sacrifice quality SAST scans just to check a compliance box.

The allure of hyper-convenient scanning tools is that they minimize friction in the continuous integration/continuous delivery pipeline. If robust SAST tools that can deliver high-quality scan results are going to be embraced by programmers, then those tools, too, must be as low-friction as their lightweight counterparts.

How do SAST tools work? In their book, Secure Coding with Static Analysis, Brian Chess and Jacob West explain that SAST tools contain a large knowledge base of rules to model important attributes of the program under analysis. These security coding rules are expanded and updated regularly. Out of the box, the rules describe general secure coding idioms for popular languages and public APIs.

Hyper-convenient scanning tools, such as linting tools, can perform lightweight static analysis of code and have rudimentary defect detection capabilities, but SAST tools perform a more robust code analysis that includes:

• Data flow analysis: This analyzes the many ways data is designed to flow through an application. Through inter-procedural data flow analysis, advanced vulnerabilities can be discovered in the functions, modules, assignments and synonyms in which data travels.
• Flow control analysis: This validates the order of operations and looks for sequence patterns that can be detrimental to code, such as cookie transmission failures, uninitiated variables, or even race conditions.
• Structural analysis: This analyzes the code for the use of best practices in the language in which the application is written. It takes into account safe development techniques and practices and flags weaknesses in class creation, declarations, and use of variables.
• Semantic analysis: Using a framework that functions similar to grep, but in a limited way, this type of analysis can parse code for specific contexts, such as .executeQuery().
• Setup analysis: This checks application configuration files such as XML, or property files. It ensures that the app's config is aligned with good security practices and policies, such as setting a default error page for web applications.

What about noise?

One of the concerns leveled against SAST tools has been that scan results can include too much noise, or false positives. While false positives are certainly undesirable, there are ways of filtering them. Most often, false positives stem from the context in which they're found. However, from a security perspective, false negatives are much worse. As Chess and West point out:

“The penalty for a false positive is the amount of time wasted while reviewing the result. The penalty for a false negative is far greater. Not only do you pay the price associated with having a vulnerability in your code, but you live with a false sense of security stemming from the fact that the tool made it appear that everything was okay.”

All SAST tools are guaranteed to produce some false positives and false negatives. Simplifying the developer experience and providing an easy way of meeting security testing compliance requirements is why hyper-convenient SAST tools attempt to produce a low number of false positives and are more willing to accept false negatives.

Willingness to accept false negatives, though, creates a level of risk that many organizations will find intolerable. That's because the penalties for application-level security defects can be very high.

Don't take shortcuts

For example, in 2017, an application vulnerability led to Equifax exposing the financial and personal information of 150 million people and resulted in the company paying $1.4 billion in settlement costs, excluding legal fees. British Airways was fined $230 million in 2019 for a security breach that affected some 500,000 customers. Meanwhile, Uber was hit with a $148 million fine for a data breach in 2016 that compromised the data of 57 million users and 600,000 drivers. Such breaches can result in huge penalties.

None of the breaches cited above was caused by app-level vulnerabilities. However, you have to ask yourself: Are shortcuts in thorough application security testing worth the potential cost impact of breaches like these?