A UK government analysis of current best practices for OSS and supply chain risk management finds weaknesses in current standards and makes five recommendations to improve matters.
The Department for Science, Innovation & Technology (DSIT) has published a report (PDF) titled Open source software best practice and supply chain risk management. It finds weaknesses in current practices and makes recommendations on how to improve things.
The weaknesses include a lack of industry-specific practices (affecting both sector and company size), no consensus on managing OSS components, no formal process for judging OSS component trustworthiness, and the outsized influence of large tech companies on the OSS ecosphere.
The first is both horizontal and vertical. Horizontally, “Outside highly regulated industries, there is a lack of guidance on how to manage OSS components in specific industries, such as education.” Vertically, current best practices do not adequately reflect the limited resources of smaller companies.
This leads naturally to the second problem. “Although best practices are broad, we found there was a lack of consensus on the best approach to managing OSS components,” says the report.
The third issue is the lack of a formal process for judging trustworthiness. “We found that each developer uses their own trust model and that there is no documented process for evaluating the trustworthiness of OSS components within an organization.”
The fourth is a problem that affects all areas of business – the influence and actions of large companies can have a detrimental effect on smaller companies. The OSS ecosphere is no longer solely occupied by small companies and independent coders. Big tech companies are increasingly involved.
“Due to these companies’ financial backing and resources, they have been able to exert a significant influence on the open-source community.” The result is that OSS influenced by big company impositions does not always reflect the real world use of OSS. It can also sideline smaller OSS contributors and dampen innovation.
Working from its analysis, the report then makes four recommendations on how to develop in-house best practices, plus another recommendation on how to make the process actionable. These recommendations are to establish an internal OSS policy; to develop an SBOM; to implement continuous monitoring; to engage with the OSS community; and to use tooling to make it all easier.
Policy. “We recommend that all organizations establish an internal OSS policy that details the criteria for evaluating the trustworthiness and maturity of OSS components,” declares the report. It notes that this should not be overly proscriptive, which could stifle innovation and the use of OSS, and it should be sufficiently nuanced to handle the different levels of scrutiny required by different projects.
It specifically suggests the policy should include a list of acceptable licenses, an approved open source list, the criteria for evaluating the trustworthiness and maturity of OSS components, the security level of the project to guide the necessary stringency of applying the policy, and an approval process that must be met before an OSS component can be used.
SBOM. Companies should develop an SBOM for their own software products. ‘This will provide a clear understanding of the software supply chain and help in enforcing an internal OSS policy.”
Continuous monitoring. “It is important to continuously monitor the software supply chain for vulnerabilities, licensing issues, and new versions of OSS components.” The Equifax breach via a known vulnerability in Apache Struts is an example of not adequately doing so – but also highlights the necessity of monitoring where the OSS is used.
Community engagement. The report suggests it is important to engage with the OSS community. “Fostering a culture of community engagement can be achieved through various activities, including contributing to OSS projects, participating in community events, or providing financial support to OSS projects.”
The result can raise the quality of a company’s own internal developers and attract new hires and can increase the quality of the OSS components.
Use tooling. The final recommendation is in recognition of how difficult and time consuming all this can be. “Tooling can be used to automate the process of managing OSS components, can be used to enforce an internal OSS policy, perform automated and continuous monitors, and generate and maintain an SBOM. This will significantly reduce the burden on developers and ensure that the SBOM is always up-to-date, and the organization complies with the internal OSS policy.”
This DSIT report analyzes the current approach to OSS best practices, highlights the weaknesses, and then proposes how they can be overcome. “We strongly agree with DSIT,” comments Glenn Weinstein, CEO at Cloudsmith. “This write-up zeroes in on the real issues facing enterprises when they consume open-source software.
The recommended best practices are spot-on… I particularly appreciate how the authors describe OSS security as a shared responsibility between security teams, who create and curate trusted repositories with quality-oriented policies, and individual developers, who shouldn’t have to make judgment calls on whether a particular package is okay to use.”
Related: Cyber Insights 2025: Open Source and Software Supply Chain Security
Related: OpenSSF Releases Security Baseline for Open Source Projects
Related: Endor Labs and Allies Launch Opengrep, Reviving True OSS for SAST
Related: NSA Issues Guidance on Incorporating SBOMs to Improve Cybersecurity
