The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →The UK government’s advice is to manage open-source software (OSS) as part of the organisation’s software supply chain: set an internal policy, inventory components and dependencies in a Software Bill of Materials (SBOM), continuously check them with software composition analysis (SCA), and support the communities behind important projects. These are recommendations, not a new legal requirement. The Department for Science, Innovation and Technology (DSIT) published its report, Open source software best practice and supply chain risk management, on 3 March 2025.
What did the UK report recommend?
DSIT’s report maps and evaluates guidance for organisations that use, produce, secure and license OSS. It was commissioned to inform UK software-security and resilience policy. Its central concern is that an open-source component can be widely reused even when its maintenance is limited. A vulnerability or dependency problem in one component can therefore affect downstream software and users.
The report sets out four practical measures. Together, they address governance, visibility, detection and the long-term health of the software an organisation depends on.
1. Establish an internal OSS policy
Define how teams may select, approve, use and maintain open-source components. The policy should make clear who owns decisions and what teams need to consider, such as whether a component is actively maintained, how security issues are handled, and whether its licence fits the intended use. The report recommends a policy; it does not prescribe a particular approval workflow or policy template.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match#1 Best Overall
2. Create an SBOM
A Software Bill of Materials records software components and their dependencies. DSIT recommends using one to track OSS in an organisation’s software supply chain. Useful inventory coverage depends on capturing both direct dependencies—the packages a team deliberately adds—and transitive dependencies brought in by those packages. An SBOM supports visibility; on its own, it does not assess whether a component is vulnerable, maintained or suitable.
3. Monitor with SCA
Software composition analysis identifies components and checks them for issues such as known vulnerabilities and licensing concerns. DSIT calls for continuous supply-chain monitoring using an SCA tool. This is the detection layer: it can help teams identify findings that need investigation, but a tool does not replace an owner, a response process or a decision about whether and how to remediate.
Rank #2
4. Engage with open-source communities
The report recommends active community engagement to improve component quality, attract talent, support innovation and contribute to a sustainable ecosystem. Depending on the organisation and project, engagement can include contributing expertise or other resources; it should be considered alongside the risks of relying on components maintained by communities with limited capacity.
How can an organisation put the recommendations into practice?
A workable approach connects the four measures instead of treating an SBOM, a scanner and a policy as separate compliance artefacts. The following sequence translates the report’s recommendations into an operational starting point; DSIT does not mandate these specific steps or prescribe a particular tool.
- Assign ownership. Name the roles responsible for OSS policy, component inventory, security findings, licensing questions and decisions to update or replace a dependency. Establish how development, security, procurement and legal teams hand off issues.
- Build and maintain the inventory. Generate an SBOM for the software products or services in scope and include direct and transitive dependencies where the build process allows. Record which product or release it describes, and keep the inventory current as software changes.
- Set review criteria. Use the policy to guide component selection and review. Consider maintenance and support arrangements, the availability of updates and security notifications, and licence suitability. The report calls for an internal policy but does not provide a universal scoring method for component trustworthiness.
- Connect SCA findings to action. Decide who reviews vulnerability and licensing alerts, how issues are prioritised, and how teams track decisions through resolution or documented acceptance. Recheck components as the software and available information change; continuous monitoring is the report’s recommendation, not a one-time scan.
- Plan for maintenance. Establish how teams will learn about and apply patches, and what they will do if a dependency is no longer maintained or cannot meet the organisation’s needs. The NCSC Cyber Assessment Framework says organisations using open source should take appropriate and proportionate steps to maintain confidence in its security and have support and maintenance arrangements.
- Support critical dependencies. Identify projects on which important products rely and consider appropriate ways to contribute resources or expertise. The report recommends community engagement, but does not specify a required contribution level.
- Keep evidence with decisions. Retain the inventory, monitoring results, ownership records, review decisions and follow-up actions needed to explain how the controls operate. Use that evidence to identify gaps and improve the process.
What do SBOM and SCA each do?
They solve related but different problems. An SBOM is an inventory; SCA analyses component information for issues. Using both can connect visibility to detection, while policy and maintenance practices determine what the organisation does next.
| Control | Main purpose | What it does not establish by itself |
|---|---|---|
| SBOM | Records software components and dependencies to improve visibility. | Whether a component is vulnerable, actively maintained, appropriately licensed or acceptable for a particular use. |
| SCA | Checks software composition for vulnerabilities and licensing issues; DSIT recommends continuous monitoring. | That every finding is exploitable, that a chosen response is adequate, or that the organisation has arranged ongoing maintenance. |
| OSS policy | Sets governance: ownership, decision criteria and how components are managed. | That teams are following the policy or that inventory and monitoring are complete. |
| Maintenance and community engagement | Address how components receive support and how organisations can contribute to a sustainable ecosystem. | A guarantee that a project will remain maintained or that a particular vulnerability will be fixed on a given schedule. |
For that reason, an SBOM should not be treated as a security certificate, and an SCA alert should not be treated as a complete risk decision. The useful outcome is a traceable process: identify what is present, detect relevant issues, assign responsibility, decide what to do and maintain the components the organisation continues to use.
Rank #4
How does the UK Software Security Code of Practice relate to open source?
The report is part of DSIT’s wider software-security programme, but the voluntary Software Security Code of Practice has a different scope. It is aimed at organisations that develop or sell software to organisational customers. It covers secure design and development, build-environment security, secure deployment and maintenance, and communication with customers. It is technology-agnostic and intended as a baseline that can be adapted to organisations of different sizes and sectors.
The Code is not an OSS-specific replacement for component governance. Its relevance is that secure software development and maintenance need to account for the components in a product, including open-source dependencies. NCSC implementation guidance frames conformance in terms of outcome-related claims and supporting evidence. Separately, the NCSC Cyber Assessment Framework advises organisations using open source to take appropriate and proportionate steps to maintain confidence in security and to have support and maintenance arrangements.
Best Value
The Code’s voluntary status matters: this report recommends stronger practices, but the material described here does not establish a universal statutory requirement for every UK organisation to use a particular SBOM format, SCA product or process. Organisations should distinguish the report’s recommendations from any obligations that may apply to them under other rules or contracts.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What does the evidence say about the need for better practice?
DSIT’s 2025 government response, citing the Cyber Breaches Survey 2024, reported that 11% of organisations took the necessary steps to review cyber risks from their direct suppliers, while 6% reviewed wider supply-chain risks. These figures concern supplier-risk review generally; they are not measurements of OSS policy, SBOM adoption or SCA usage.
In DSIT’s 2024 consultation, 92% of 86 respondents considered funding industry-led initiatives very or somewhat effective for addressing risks specific to open-source software development. In the 2025 government response, 81% of 72 respondents agreed that government should produce guidance showing software vendors what good cyber security looks like. Also in that response, 46% of 67 respondents said they were very likely to use a voluntary Software Security Code of Practice to inform procurement, and a further 27% said they were likely to use it. These are respondent views, not evidence that the practices have already been adopted across the market.
What further work did DSIT identify?
The report points to areas where more guidance or evidence could help organisations apply the recommendations:
Recommended Free Tools
- Guidance scaled to organisations’ size and capability, with possible sector-specific guidance.
- Further consideration of how organisations can contribute back to open source.
- Research into effective community engagement.
- Standardised metrics for assessing component maturity and trustworthiness.
Until such measures are established, organisations should avoid presenting a single score or scan result as a universal measure of trust. Component assessment needs to be proportionate to the software’s role and informed by its maintenance, support and security context.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
