Why open source software supply chain management is worse than you think
A Sonatype survey also found a 650% year-over-year increase in supply chain attacks aimed at upstream public repositories.
The seventh annual State of the Software Supply Chain Report from Sonatype found that developers think software management practices are in much better shape than what conditions on the ground indicate.
The analysis found that the majority of respondents use an ad hoc approach to software supply chain management for most parts of the process, except for remediation and inventory. Respondents seem to be remediating risky components and to understand where the risks are in the supply chain, even though they have an informal approach to the build and release and risk management processes.
The report showed a clear disconnect between what is actually happening and what people think is happening: “Respondents have talked themselves into believing that they’re doing a good job, leading at the least to a false sense of security and at worst to huge inefficiencies in the engineering process.”
The report also found a 650% year over year increase in supply chain attacks aimed at upstream public repositories. There were 216 software supply chain attacks from February 2015 to June 2019. From July 2019 to May 2020, that number went up to 929 attacks, according to the report.
SEE: Open-source developers say securing their code is a soul-withering waste of time
Matt Howard, EVP of Sonatype, said in a press release that the report reinforced the fact that open source is both critical fuel for digital innovation and a ripe target for software supply chain attacks.
“While developer demand for open source continues to grow exponentially, our research shows for the first time just how little of the overall supply is actually being utilized,” he said. “Further, we now know that popular projects contain disproportionately more vulnerabilities.”
Also, the analysis revealed that 29% of popular open source projects contain at least one known security vulnerability compared to only 6.5% of less popular OSS projects. And, despite the millions of open source projects that are available, only 6% are used on a regular basis.
The most common types of attacks on the software supply chain over the last year were:
- Dependency/namespace confusion: A bad actor publishes a malicious package using the exact same name as a legitimate, proprietary package to a public repository that doesn’t regulate namespace identity.
- Typosquatting: This indirect attack takes advantage of misspellings and typos to get developers to install a malicious component that is mistaken for the real one.
- Malicious source code injections: This type of attack dropped in frequency over the last year and involved injecting malicious source code directly into an open source project’s repository.
How to reduce OSS software supply chain risks
To minimize risk associated with vulnerabilities in third-party open source libraries, Sonatype analysts recommend that software development teams adopt defined criteria for selecting open source projects and look for projects that have low Mean Time To Update.
This metric provides visibility into an open source projects’ dependency management practices and a lower time is better. According to the report, “Projects that consistently react quickly to dependency upgrades in their downstream dependency chain will have low MTTU. Projects that either consistently react slowly or have high variance in their reaction time will have higher MTTU.” Previous Sonatype research also suggested that MTTU is correlated with mean time to remediate.
Sonatype’s 2021 State of the Software Supply Chain Report combined public and proprietary data to identify trends in modern software development. This year’s report analyzed operational supply, demand and security trends associated with the Java (Maven Central), JavaScript (npmjs), Python (PyPI) and .NET (nuget) ecosystems. Researchers also studied software engineering practices gleaned from 100,000 production applications and 4 million component migrations made by developers over the past 12 months.
Measuring supply chain practices and engineering outcomes
In addition to assessing the state of OSS security, the Sonatype report also looked at how the reality of supply chain management compares to best practices. Researchers also surveyed 702 software engineers to measure the state of software supply chain management with open source software. The survey aimed to develop a set of benchmarks.
Sonatype analysts measured survey responses against these eight elements of software supply chain management practices:
- Application inventory: What applications are you running and what open source components do they include?
- Supplier hygiene: Do the OSS components come from a trusted supplier?
- Build and release: Do you understand how software components come together to build and release applications into production?
- Project consumption: Do you govern OSS component selection?
- Giving back: Do you contribute to the open source community?
- Policy control: What is your tolerance for risk?
- : What is your execution plan for implementing new processes and tools?
- Remediation: How do you fix identified risks in OSS components?
Responses were scored and then mapped onto one of the the five stages of software supply chain management maturity:
- Unmanaged: An “anything goes” mindset with minimal oversight.
- Exploration: A process of identifying perceived problems and starting to find solutions.
- Ad hoc: The start of defining and selecting new tooling and processes.
- Control: A more formalized governance process starts to take hold.
- Monitor and measure: A phase of proactively addressing OSS component risk.
The majority of responses were rated in the ad hoc or earlier phase. Combining these results with the objective analysis from other chapters in the report revealed the disconnect between how software development teams think they are doing and what is actually happening. According to the report, “development teams are not following structured guidance, and do not have intelligent tooling to ensure quality outcomes. Reconciling this perception with reality will help organizations in achieving the promised efficiency gains in dependency management.”