John Smith at Veracode looks at the risks associated with open source software and shares his insights on managing them
Open source software has been popular with developers for decades. That’s no surprise when you consider the benefits; free accessibility, malleability, and efficiency. Why spend time writing something someone else has already written?
As a result, almost all applications we use now contain some open-source components and most applications are predominantly comprised of them. The huge source code pool has enabled even non-software organisations, of all sizes and industries, to create software.
But, our recent State of Software Security v11: Open Source Edition highlighted some significant risks with how open source software is used, which business leaders and developers need to be aware of. While open source libraries enable developers to work faster and smarter, it’s important to remember they’re not static. Library popularity and usage changes and evolves, making it challenging for developers to keep up with the latest security updates to those libraries.
Now, more than ever, organisations are at greater risk of damaging data leaks and cyber-attacks due to poor management of the proliferation of open source.
Let’s look in more detail at the risks associated with open source and the problem with a ‘set it and forget it’ mentality.
The risks of ‘set it and forget it’
Developers often don’t realise they need to update a library. Our research found developers tend to ‘set it and forget it’, leaving most libraries in place without updates. I like the analogy that open source libraries age like milk – spoiling if not managed properly! Around 95% of IT organisations now rely on open source software, but 79% of the time third-party libraries are never updated after being included in a code-base.
So, what is preventing developers from updating vulnerable open source libraries? A lack of contextual information can be one roadblock. A lack of context could be something as simple as not understanding the severity or impact of a vulnerability.
For example, if a developer doesn’t understand why SQL injection is dangerous, they might consider it unimportant. Sometimes illustrating the code path – connecting the first-party code to the third-party vulnerability – can help developers understand how and why their application is vulnerable.
Developers who report they need more contextual information take more than seven months to fix 50% of flaws. On the other hand, for those who feel they have accurate background information, for example how a vulnerability impacts the security of their application, remediation time reduces to three weeks.
The good news is that, when alerted to vulnerable libraries, developers can act quickly. In fact, nearly 17% of vulnerable libraries are fixed within an hour of the scan that alerted the developer, and 25% are fixed within seven days. Moreover, most open source security flaws require only small fixes. In fact, 92% of library flaws can be fixed with an update, and 69% of these are only a minor version change or less.
Shifting security culture
A lot has been said about ‘shifting left’, the latest buzz phrase for pushing responsibility and functionality to the beginning of the software development lifecycle. Whilst this may be a good idea, more is needed – especially in DevOps situations. Software development moves very quickly and often through automated checks. Organisations with highly integrated security practices are well ahead with DevSecOps.
Training employees and teams to understand the importance of this shift in approach is key to making a change in company culture so that security education is not viewed as a drain on employees’ time.
DevSecOps adds security teams into the equation so they can collaborate seamlessly with developers and IT engineers. Whilst DevOps encourages continuous delivery, DevSecOps is all about continuous security – meaning the constant and holistic management of security across the software development lifecycle.
Similarly, DevSecOps encourages continuous improvement in the realm of security. This means that no matter how secure you believe your environment is, you should always be looking for ways to improve your security posture even further.
There are four key ways to integrate security into development:
- Good developer training is key. There are lots of tools available which offer real-world education developers can use while coding.
- Encourage continuous communication and collaboration between all teams in the existing DevOps processes. Understanding the pressures and workflows of your teams helps everyone operate with the same goals in mind.
- Make sure developers are checking the entire codebase (if you haven’t guessed by now, that means including open source code too) – not just your own.
- Automate wherever possible to speed up the development process and provide developers with clear feedback that they can action.
Leaders must act now to support developers
Open source software will remain an important and useful tool for developers, however we can no longer ignore the security risks that are being taken with this code. Security teams should work closer with development teams to change the ‘set it and forget it’ mentality and ensure the right processes are put in place so developers have access to any contextual information required to fix vulnerabilities upfront.
The integration of DevSecOps is a step in the right direction. Yet, more must be done by business and technical leaders to reprioritise time to work on vulnerabilities and reduce security debt, just as time is set aside to work on scalability, resiliency, quality, and so on.
Culturally, we need to place more emphasis and resource on allowing time for developers to address vulnerabilities, instead of filling their time with building new features. After all, that shiny new software will quickly be worthless if it can easily be hacked.
John Smith is CTO, EMEA at Veracode
Main image courtesy of iStockPhoto.com