Defending the Software Supply Chain

Current software development could not exist with the open-source ecosystem. Almost all software (98%) tested by security firms makes use of open-source components, with an average of three-quarters of every codebase consisting of open-source code. This widely available ecosystem has also attracted software developers from all parts of the world and from non-technical careers.

The result is an ecosystem that is a necessary foundation for competitive software development, but at the same time, is prone to defects, errors and vulnerabilities. For that reason, companies need to not only worry about their own software development pipeline but external sources of code as well.

Almost all software

tested by security firms makes use of open-source components.

Hardening the Fault Points in the Supply Chain A critical step for organizations to avoid incorporating flawed or compromised code into their own products is the ability to spot anomalies in open-source components and projects. In many cases, open-source maintainers do not have the time nor funding to enforce a secure development lifecycle on their project. Spotting warning signs, such as a long time to remediate issues, can help companies to decide whether using code from such a project is worth the risk.

Watch Out for the Easiest Attacks At present, the most common attempted attack is dependency confusion. The ease with which attackers can create malicious projects to take advantage of typing errors has lead to thousands—if not tens of thousands—of software projects specifically created to fool developers. While the attack has a very low success rate, like phishing and spam, it only takes one user at a company to give attackers a beachhead from which to compromise other systems. In addition, online tutorials can be used as a way to propagate the names of malicious dependencies, taking advantage of novice developers.

Focus On—Detecting Anomalies in the Software Ecosystem CyberRes Debricked tracks information about open-source projects to score the projects on their security as well as give developers a measure of the project’s popularity. Other metrics that can be used as a guide to the stability of a particular project include a score for the contributors.

Spotting warning signs, such as a long time to remediate issues, can help companies decide whether using code from such a project is worth the risk.