Veracode: How Third-Party Code Impacts Software Security

If it seems like each new day carries with it yet another announcement that threat actors have successfully launched cyberattacks using the vulnerabilities found in open source code — think Log4Shell — it’s not just your imagination.

The reality is that enterprises and governments are increasingly recognizing the challenges that open source can create if not managed correctly by software developers. As that awareness spreads, we can expect to see more companies and organizations trying to get ahead of those vulnerabilities in any number of ways.

But even as organizations make much-needed changes in how they handle open source code, it’s vitally important to understand how that third-party code impacts software development. By using open source code, developers gain access to innovation that’s been built upon by every developer who has contributed over time.

That sense of community is a considerable draw, as hundreds or even thousands of developers can contribute ideas for enhancing features, functionality and even security. Most importantly, leveraging open source reduces up-front costs and enables the business to innovate faster.

These benefits continue to drive adoption of open source, despite the negative attention generated by Log4Shell and other attacks. Indeed, according to the Open Source Initiative, use of open source across all organization sizes and industries increased 77% in the past year — with 37% saying they significantly increased the use of open source.

Nevertheless, a survey of 700 software developers and experts shows that security is a vital issue, with 57% saying that security is the most common challenge that application development teams face when building with open source. Likewise, 30% say security is also the most urgent challenge they face.

Our research featured in State of Software Security v12 likewise shows that open source is a key issue for organizations of all sizes and industries. As such, it’s worth delving into how challenges with open source are impacting developers and software development as a whole.

The Risks of Open Source Code

There are plenty of benefits to leveraging open source code in software development, making it well-liked universally by developers. That said, it’s also worth understanding its risks. Here’s what we know:

• Organizations generally do not keep an accurate, up-to-date inventory of all the open source code they are using. If they don’t know what code is in their software, how can they expect to know what needs patching?
• While development teams can benefit from using code that’s been contributed to by a community of developers, they don’t always consider that those contributions might contain vulnerabilities — despite the fact that applications built with open-source code contain an average of seven vulnerabilities. Even more concerning, 44% have critical vulnerabilities that can lead to major breaches.
• Third-party libraries are seen as a potential attack vector because many developers inadvertently skip updating libraries once code is written and in play. In fact, 79% of the time, developers never update third-party libraries after including them in a codebase. Not surprisingly, developers are looking to get code created as quickly and painlessly as possible and then move on to the next project, so there’s not a great deal of incentive to update libraries for code that’s already shipped. And that’s where the security risks lurk. The majority of today’s code originates from third-party libraries, but the vulnerabilities discovered in those libraries are widely ignored. Nevertheless, open source software libraries aren’t going anywhere. In fact, it’s estimated that more than 90% of code today may originate from open source libraries — a number that’s expected to continue growing.

How Developer Habits Have Changed

In the latest State of Software Security, we looked at historical data to determine the amount of code that’s third-party versus homegrown, and we learned that most applications are either composed almost entirely of third-party code or almost entirely of code created in-house.

SoSS v12 (page 21) shows that developers tend to use tried-and-tested libraries and rarely attempt to refactor their code base to assess the latest contributions. Nevertheless, developers now face changes that should be made to the process based on the Biden Administration’s Executive Order (EO) on Improving the Nation’s Cybersecurity, which outlines measures meant to improve the security of the software supply chain.

While the Executive Order specifically addresses software used by the federal government, there is no question that it will trickle down into the private sector sooner rather than later. The EO calls for rigorous mechanisms to ensure the security and integrity of the software supply chain, especially for critical software. Specifically, government agencies are now being asked for a Software Bill of Materials (SBOM), an inventory of all components and software dependencies involved in an application, open source included.

And while there’s no question that the recommendations and requirements laid out in the EO are desperately needed, developers can’t just snap their fingers and adhere to those changes without understanding what is required, their responsibilities, and how to ensure they’re in compliance.

Reducing Risk

Resources like our Veracode Security Labs help developers better understand how to fix flaws when they occur, as well as how to avoid creating new problems in the future. This training platform provides developers with hands-on experience both exploiting and fixing common vulnerabilities using real-life applications in a variety of programming languages.

As it turns out, experiential learning works! Our analysis showed that developers who have completed at least one of these lessons fixed flaws faster than developers who had no training. Specifically, organizations who use Veracode Security Labs training fix flaws about two months faster on average, a 35% reduction in remediation time.

Veracode’s Continuous Software Security Platform has been enhanced to further help developers reduce risk associated with open source code and meet new regulations for securing software supply chains. The platform now features an SBOM API in SCA (Software Composition Analysis), enabling developers to generate an SBOM in CycloneDX JSON format — one of the approved formats for compliance noted within the EO.

Veracode’s SBOM API provides an inventory of components in an application, with insight into relationships between components and identifying which are from third-party sources. Veracode’s SCA then offers remediation guidance and helps manage license risk.

Leveraging the SBOM API helps developers understand more about the “ingredients” that make up their applications to confirm that the code they are using, including open source code, is free from vulnerabilities.

As organizations and developers continue to utilize third-party code, there’s no question that we’ll continue to see cyberattacks that are made possible by vulnerabilities found in that code. No company wants to be the next cyberattack victim, but all companies are at risk of becoming so. Savvy organizations that understand the importance of third-party code must work with developers today to ensure they understand the potential dangers and how to mitigate them.