The original version of this post was published on SecurityWeek.
As the use of open source continues to rise, many organizations are putting their toes on the line for a race they are ill-prepared to run, much less win. In this race, losing could put your organization squarely into some unwanted headlines.
When developers in your organization use open source, they are putting your toe on the line because that open source component may have vulnerabilities that put you at risk.
You see, the disclosure of a vulnerability kicks off an IT security race. Hackers seize on the new vulnerability and begin to ping externally facing websites to see whether they can find it. At the same time, IT security folks begin the process of determining whether any of their sites have that vulnerability and, if so, closing it before the hackers get there. If the hackers get there before the IT security people do, the result is most likely a breach.
A great example recently jumped to the headlines. In March, a vulnerability was disclosed for a popular and widely used open source web server, Apache. This vulnerability involved Apache Struts, a component of the Apache server that helps Apache users manage and deliver site content.
The disclosure of this vulnerability set off the race between IT security and the hackers. The hackers knew they had a 45- to 90-day window of opportunity, so they took off with a sense of urgency. In September, Equifax announced that it had been breached, and that the Apache Struts vulnerability was the entry point.
In the case of Equifax, the hackers won the race.
As open source usage continues to accelerate, it is not a stretch to believe that such scenarios will repeat with increasing frequency. Many studies now say most new software is made up of 60% open source components. As open source grows, it follows that vulnerabilities will increase proportionately.
Many organizations are ill-equipped to run the race because they do not have a handle on their use of open source. They don’t have the proper organizational policies, they don’t educate their developer teams, and they don’t deploy the proper tools to help secure and manage open source software.
This is too broad a subject to tackle in one sitting, so let’s get back to the race and how it could be affected by having the right tools in place. How many organizations track their use of open source? For the organizations who do, how do they do it?
Regarding the first question, the truth is that many organizations have no process for tracking open source, and even for those who do, it may not be a pretty picture. There are tools to help organizations track their use of open source components. These software composition analysis (SCA) tools—the name given such products by a leading analyst firm—are readily available and have progressed significantly to keep pace with the growing adoption of open source. But for many organizations, Excel is the tool of choice.
Somewhere in the development shop is one or more people tasked with keeping track of open source usage by logging it into a spreadsheet. The process relies on the other developers communicating with these folks when they use open source components and when they make changes to those components. What could go wrong?
A lot could go wrong. If the Apache Struts vulnerability were announced today and your organization had no process in place for managing open source, you would be forced to go through your applications one by one to determine whether they used the offending Apache Struts component. Until you did that, you would have no idea as to the risk to your organization.
If you at least had a spreadsheet, you might have some idea of where to look, but you would be at the mercy of the keeper of the record—and the communication of the developers—regarding the accuracy of the information. It might save you some time, but because you can’t trust that information, you wouldn’t be much better off than those with no management system.
What happens when software composition analysis enters the race?