Did SAST and DAST Fail Equifax?

Did SAST and DAST Fail Equifax?

On March 8, 2017, the U.S. Department of Homeland Security, Computer Emergency Readiness Team (“U.S. CERT”) sent Equifax and many others a notice of the need to patch a particular vulnerability in certain versions of software…. Equifax used that software, which is called “Apache Struts,” in its online disputes portal, a website where consumers can dispute items on their credit report.

Equifax online dispute portal image

We now know that the vulnerable version of Apache Struts within Equifax was not identified or patched in response to the internal March 9 notification to information technology personnel.<

On March 15, Equifax’s information security department also ran scans that should have identified any systems that were vulnerable to the Apache Struts issue identified by U.S. CERT. Unfortunately, however, the scans did not identify the Apache Struts vulnerability. Equifax’s efforts undertaken in March 2017 did not identify any versions of Apache Struts that were subject to this vulnerability, and the vulnerability remained in an Equifax web application much longer than it should have. 

~ Excerpts from “Prepared Testimony of Richard F. Smith before the U.S. House Committee on Energy and Commerce Subcommittee on Digital Commerce and Consumer Protection”

Reading between the lines of ex-CEO Smith’s prepared statement, it appears that the chain of events leading to the Equifax breach was a combination of human error and technological failures. 

“There was a protocol in place to fix the software flaw that led to Equifax being breached. It wasn't followed,” Smith said in testimony on October 3rd. "The human error was, the individual who was responsible for communicating the patch in the organization, did not," he said. “A few days later, there was a scan of the system, which also didn't reveal the vulnerability.”

Smith hasn’t elaborated so far on what was used to “scan” the Equifax systems, but given its failure to identify a known open source vulnerability, one could assume that it wasn’t a dedicated open source vulnerability management solution (or if it was, Equifax should seriously consider asking for its money back). It’s more likely that Equifax was using some combination of traditional SAST and DAST tools to protect itself.

8 Takeaways from NIST’s Application Container Security Guide

SAST, DAST, and Open Source Vulnerability Management

96% of applications scanned had open source components

The vast majority of security attacks target software applications. Not surprisingly, there is an array of application security tools on the market to help companies address security risks, varying in both approach and coverage. Traditional application security tools  Dynamic Analysis Security Testing (DAST) and Static Analysis Security Testing (SAST) – are very effective in finding bugs in the application code internal developers write. However, they aren’t as effective in identifying open source software vulnerabilities. Given that open source is an essential component in application development worldwide, effective open source vulnerability management is imperative.

Last year, Black Duck’s Center for Open Source Research & Innovation (COSRI) analyzed more than 1,000 applications that were audited as part of Merger & Acquisition transactions. The COSRI audit analysis found that 96% of the applications contained open source software and more than 60% of those applications contained known open source security vulnerabilities.

Are Vulnerabilities Found By SAST and DAST Tools?

Since 2004, more than 74,000 vulnerabilities have been disclosed by NVD, but only a handful of those were found by SAST and DAST tools. SAST is effective at finding many common vulnerabilities such as cross-site scripting, SQL injections, and buffer overflow vulnerabilities, but according to the National Security Agency (NSA) the average SAST tool can only find 14% of the problems in an application. Similarly, while a valuable tool for web application testing, especially for custom-built applications, DAST is weak at finding vulnerabilities entering code via open source.

The most effective way for companies to gain visibility into and control over open source in the applications and websites is to use automated processes to scan their applications for open source, create an inventory of their open source components and then map that open source to open source vulnerability databases. This enables them to identify any known vulnerabilities and then monitor the inventory for any newly reported open source vulnerabilities.

Where Are Your Vulnerability Identification Gaps

Traditional approaches to application security, involving only static and dynamic testing, can leave significant vulnerability identification gaps. Open source vulnerability management (OSVM) completes the picture, providing automatic identification and inventorying of open source software, mapping components to known vulnerabilities, and streamlining and securing CI/CD activities. A three-pronged approach, incorporating SAST, DAST and OSVM, ensures a comprehensive and in-depth assessment of security across the entire application landscape.

Nothing can fully protect against human error, and the Equifax employee’s failure isn’t the first instance of human error leaving an organization exposed to an open source vulnerability, and won’t be the last. But if Equifax’s March scans had been effective in identifying the Apache Struts vulnerability in its affected systems, they might have been able to stop — or at least, limit — the attack and close the backdoors the intruders had set up to protect the financial data — Social Security numbers, birth dates, addresses and more — of at least 143 million Americans.

Managing application security with a comprehensive toolkit

Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.


Who Owns Linux? TRITON Attack, App Security Testing, Future of GDPR

| Mar 16, 2018

We look at the three reasons you must attend the FLIGHT Amsterdam conference; how to build outstanding projects in the open source community; and why isn’t every app being security tested? Plus, in-depth into the TRITON attack; why 2018 is the year of open source; how open source is driving both

| MORE >

SCA for DevOps, DHS Security, Securing Open Source for GDPR, CVE Gap

| Mar 9, 2018

It’s an acronym-filled issue of Open Source Insight, as we look at the question of SCA (software composition analysis) and how it fits into the DevOps environment. The DHS (Department of Homeland Security) has concerning security gaps, according to its OIG (Office of Inspector General). Can the

| MORE >

AppSec for DevOps, Open Source vs Proprietary, Malicious AIs & GDPR

| Mar 2, 2018

Welcome to the March 2nd edition of Open Source Insight from Black Duck by Synopsys! We look at places you’d never expect to find GDPR data, as well as answers to your most-frequently-asked GDPR questions. Synopsys Principal Scientist Sammy Migues explores why enterprises must have a software

| MORE >