The Significant Threat of Software Supply Chain Attacks and How to Reduce Risk

Contact Us

The Significant Threat of Software Supply Chain Attacks and How to Reduce Risk

Software supply chain attacks have reached epidemic levels. In a 2023 study, 90 percent of IT professionals said their organizations had been affected by software supply chain threats in the past year. Additionally, 88 percent said these threats created risk for the entire organization. However, just 60 percent believe they have adequate defenses.

A Capterra report found that 50 percent of IT security professionals consider supply chain attacks to be an “extreme” or “high” threat. Another 41 percent say the risk is “moderate.”

Many supply chain threats come from open source software. The Capterra report notes that 94 percent of organizations use some form of open source software in their applications, with 57 percent using multiple open source platforms. A 2022 report from Sonatype found 88,000 malicious packages in open source software, a mindboggling 742 percent increase over 2019.

Organizations can “immunize” themselves against this threat with proper DevSecOps practices. The key is to take control of open source code so that it goes through the same rigorous security checks as internal software.

Interested In Learning More?

Code on a computer screen

Why Open Source Creates Risk

Often, the threats introduced by open source are known vulnerabilities. The Sonatype report found that 96 percent of open source Java downloads had known vulnerabilities, and DevOps failed to use the patched version. Developers struggle to identify these threats due to application sprawl and complex software dependency. Sonatype estimated that the average Java app contained 148 dependencies and was updated 10 times per year, creating 1480 opportunities for a bug to be introduced.

Another problem is that developers often reference third-party libraries in public code repositories. The thinking is that these public repositories are more secure because everyone can see the code that’s in them. In many cases, however, nobody is reviewing the source code because nobody is responsible for it. Developers generally don’t like source code review, and if they’re not getting paid for it they don’t do it.

Many organizations are also operating under a false sense of security. Sonatype tested a random sample of enterprise applications and found that 68 percent had known vulnerabilities. However, 68 percent of survey respondents felt confident that they weren’t using vulnerable open source code.

Person typing on a computer with a screen that says "Open Source Software"

Taking Control of Open Source

A better approach is to download all open source libraries from public repositories into an internal artifact repository. That tends to make the artifact repository large. Once the source code is in there, however, your developers can use their testing tools to find bugs and vulnerabilities. This also enables you to hot patch the open source code without directly contributing to the public library. If you find a flaw or need to modify the code in any way, you can do that while it is sitting in your artifact repository.

In addition, you’re no longer chained to the changes made in the public repository. Often there are changes in public repositories that can break your software builds. It happens all the time. When you’re running on your own artifact repository, you’re always building from a known working source. If something changes that breaks your build, you can go back to a prior version of the source for your deployment.

Person typing on a computer with code on the screen.

Using DevSecOps to Reduce Risk

Finally, this approach enables security teams to decide which open source libraries are acceptable. The artifact repository collects those internally so that the security team has a known version of the working source code. If something changes in the public repository, the artifact repository will detect it. The security team can determine whether to implement that change or stick with the downloaded source code. Developers are only allowed to use what’s stored in the artifact repository rather than anything available in the public repositories.

All DevSecOps reference designs require an artifact repository for the storage and retrieval of dependency libraries and other components. The designs also require vulnerability management tools that ensure all software and artifacts are appropriately patched. They are best practices that improve software quality and build stability by reducing reliance on public repositories.

These features are built into DeSeMa’s fully managed DevSecOps services. Our unique turnkey solution includes all the development and preproduction tools you need in a hosted environment, backed by expert services and a complete DevSecOps testing suite. Let DeSeMa help you immunize your organization against the epidemic of software supply chain attacks.

Get Started Today!

Contact Us