After going through 24 seasons of cross-country, winter track, and spring track with my boys, I fully understand that if you put your toe on the line, you had better be prepared to race, or bad things happen.
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.
Responsibly disclosing vulnerabilities
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.
Acceleration of open source software
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?
Tracking open source
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?
Applying a software composition analysis (SCA) tool to the process changes the picture dramatically. An SCA tool should be able to perform some basic tasks for any development organization:
• Identify – An SCA tool should be able to scan an organization’s software and identify the open source components in the code.
• Catalog – Once the tool identifies open source components, it should catalog them in a digital repository that can be readily queried.
• Evaluate – There are multiple sources for open source vulnerability data. The most commonly used is the National Vulnerability Database (NVD). These data sources can be referenced to see whether any of the open source in use has known vulnerabilities.
With an SCA tool in place, you would be able to quickly scan the information repository and know where Apache Struts was used, as well as additional information about the version. Furthermore, anyone who tried to use the offending version of Apache Struts after the vulnerability was disclosed should get a warning about that vulnerability from the SCA tool, so the problem is addressed before the code is deployed.
Using open source software makes good sense and provides organizations development speed and agility. But organizations need to know the risks. If you are going to toe the line, be prepared to race.
