8 More Struts Breaches

Earlier today, Robert Hackett at Fortune published an eye opening report on the number of organizations who continue to download known vulnerable open source components.  His focus for the article was specifically on the Struts web application framework.  Why?

We've Seen This Before

When using vulnerable versions of the framework, organizations are breached.  Everyone knows the Equifax story, but for folks like me who have been paying closer attention, the story also includes the Canadian Revenue Agency, Okinawa Power, the Japanese Post, the India Post, AADHAAR, Apple, University of Delaware, and the GMO Payment Gateway.

In our 2018 DevSecOps Community Survey of 2,076 IT professionals, 30% of respondents claimed that they had or suspected a breach due to the use of vulnerable open source components.  This figure was up 55% since we asked the same question last year.  In many ways, this figure is not surprising.

Use Protection

The same survey revealed how many organizations were governing their use of open source components.  For organizations without DevOps practices, 58% had an open source policy in place -- meaning 42% had no policy.  Furthermore, at 46% of the organizations with a policy, developers ignored the rules.  This means, only 1 in 4 organizations had a policy that was followed.

Tracking Matters

Shortly after the story broke at Fortune, @misfir3 asked me how organizations would know what open source components they were downloading and more importantly deploying into production.  He specifically wanted to know about the known vulnerable components.

The monthly vulnerable download statistics tied to Struts are daunting.  The sheer volume of consumption ranges between 80,000 - 100,000 downloads across thousands of organizations.  As you can see from the chart below, downloads of vulnerable versions are -- for the most part -- indiscriminate.

Understanding which components you are using is relatively easy to determine when creating a software bill of materials.  An SBOM is simply a manifest that lists all of the components in a build artifact or deployed application.  Any organization creating an SBOM can then use it to assess known vulnerabilities in the components; assessments can be manual, but to scale the processes I would highly recommend an automated approach.  Manual reviews of open source components in a single application could take 400 hours, but automated reviews can be completed in as few as 10 seconds.

Our 2018 DevSecOps Community survey revealed that only 38% of organizations produce a complete software bill of materials.  This is disheartening.  When thousands of new open source vulnerabilities were announced last year alone, how could a firm determine their impact if no track and trace mechanisms were in place?  If you can't track it, you can't fix it.

For those of you interested in reading Robert Hackett's article, you can find it in Fortune here.