Have you ever seen one of those old cartoons where the character starts pulling at a loose thread on a blanket or a shirt? It usually ends up with them pulling apart the whole thing, and they are ultimately left with a big mess of string. That big mess is what many businesses are afraid of when they are looking at the security of their environment. They know that they need to make sure they are locked down, but they are afraid of what kind of mess they will end up with after they start investigating. When they start exploring, will they ever be able to stop pulling at the thread? Will the whole fabric become unraveled? Will they be left with a big pile of problems in the end that is nearly impossible to fix?
One of those dreaded threads that has been around a long time–but one that is new or even unknown to many organizations–is the use of open source code in applications. In today’s high-speed, digitally-driven world, software needs to be developed and deployed quickly and constantly, but the speed that is needed to stay competitive is impossible to reach with completely original code. As Set Solutions partner Veracode points out, development teams “frequently incorporate pre-built, reusable open source software components” in their applications for the purpose of accelerating the development of software. If not for open-source components that perform certain repeatable, commonly-used functions, development and innovation would be dramatically slowed.
But for all of its usefulness, the risk of open source code can be extremely high. Consider that open source developers, unlike most modern development shops, are completely free to develop and deploy code without the use of any kind of security testing. While some people have said that “many eyes” looking at open source code means that there are fewer security flaws, that argument is easy to dismiss in the light of the high-profile issues with open source software in the last few years (Apache Struts in the Equifax breach, HeartBleed from OpenSSL, and ShellShock from Bash are a few examples). The lack of pointed testing for security flaws in open source development is a real and important concern for organizations.
So how do you get the open source problem under control, especially when the sheer volume of total code (original and open source) is likely high in your organization? The problem is comparable to the asset management problem experienced in a typical IT scenario, only often much larger in scale. Sprawl in typical IT assets (desktops, laptops, servers, etc.) can cause security to throw their hands up in frustration. Sprawl in code can get much larger in a much shorter period and can make it extremely difficult to contain.
So yes, the pile of thread can get very big very quickly. It’s the age-old question: “Do we really want to know?” It is certainly a fair question to ask, but we all know that burying your head in the sand is not good in the long run. Getting started on the open source problem is essential to your organization’s security posture; here are some high-level ideas for getting your open source security project built:
- Realize that it’s a problem: If you have developers, then you have an open source issue. There is no doubt about it. Now do something about it.
- Engage your developers: Work with your development teams to get a list of open source components in use. This seems obvious, but many security teams do not interface nearly enough with development teams. If you reach out in the spirit of improving the security of the organization (instead of saying you need to make sure their code is secure), then you can hopefully start off on the right foot and begin making progress.
- Trust but verify: Going back to the asset management point above, don’t assume that the open source component list that your development team gives you is complete. In fact, it most likely is well short of being complete. Use a tool like Veracode’s SourceClear product to do a software composition analysis of your code. This will take a good amount of time and effort (getting code from the development team can often take a while), but it will be worth it to make sure you have a solid understanding of the use of open source components.
- Put a quick dent in the problem: With a little work and investigation, many flaws can be fixed very quickly by replacing or updating open source components that are vulnerable. By using tools like those mentioned above, you can determine fairly quickly which components are bad and get those knocked out. Showing a quick reduction in risk will deliver you a quick win with management, which will help garner more support for the program.
- Set and enforce policy: If you know which open source components are bad, you can also ban those and enforce policy for use of them by your developers.
- Don’t stop: While it is tempting to get some big things knocked out and hang back, realize that development is a continuous process. Developers are looking for ways to hit their delivery deadlines, so more open source will be used. Setting and enforcing policies does not mean all open source components will be safe. Stay vigilant.
- Work hard to make work easier: Make sure to cultivate and improve relationships with your development team. Recognize that they are working hard, just like you. Do what you can to make their life easier; explore integration into their tools and automation of code testing to help speed up security.
***
This blog was written by Michael Farnum, Director of Solutions Architects – South, at Set Solutions.