10th Annual State of the Software Supply Chain Report

Best Practices in Software Supply Chain Management

Every dollar spent on software development demands budget justification. This complicates risk management. The open source world is always changing, with new risks appearing daily through rapid innovation. Traditional scanning tools are unable to accurately and promptly detect new potential malware. Most organizations struggle with timely risk management due to a lack of adequate security controls and discipline to enforce better open source component choices along with the pace of necessary security updates.

Developers feel less encouraged or incentivized to adapt to a security-savvy mindset while developing software using open source packages due to a lack of proactive guidance from tools, available security data insights, or implied security processes. Further, the alarming increase in open source malware and the use of open source downloads as a vehicle for malware distribution is also highly concerning. Amid constant backdoors, ransomware, and emerging threats, security struggled with manual oversight of engineering, whose development teams, despite being the primary risk source, often ignored security concerns.

However, the expanding risk spectrum and surge in open source components don’t fully excuse the failure to choose high-quality components, update them promptly, or proactively defend against malware attacks.

Top Eight Best Practices

Our findings reinforce the need for software manufacturers to approach open source consumption with diligence. With the right tools, processes, and best practices, managing these risks and ensuring the security and reliability of software supply chains becomes possible and efficient.

Informed Selection of Open Source Components:

• Prioritize components that demonstrate active and responsive communities. These components are more likely to address vulnerabilities quickly and maintain a higher standard of code quality.
• High fix rates and low time to remediate metrics are key indicators of a component’s reliability. Also, components with transparent supply chain practices, like publishing an SBOM, typically exhibit lower persistent risk.

Adopt a Comprehensive Quality Assessment Framework:

• When selecting open source projects, go beyond surface-level metrics like the number of stars or forks. While popular projects often fix vulnerabilities more quickly, they are not inherently risk-free. Ensure your selection process incorporates more risk-related indicators, such as persistent risk across versions.
• Integrate metrics like latency (the average time to vulnerability discovery) into your risk assessment frameworks to better understand and mitigate the long-term impact of complacency.

Implement Proactive Dependency Management:

• Regularly audit your open source dependencies to identify vulnerabilities, particularly those that span multiple versions. Implement automated tools to track and remediate these issues before they impact your software.
• Develop a systematic approach for updating dependencies as soon as fixes become available. This will minimize persistent risk and prevent software from "aging like steel."

Mitigate Complacency in Maintenance:

• Implement policies that enforce regular reviews and updates of all open source dependencies, particularly those neglected for over a year. This approach will combat latent risks and reduce the chances of introducing vulnerabilities into your software.
• Utilize tooling that provides real-time alerts for outdated or vulnerable dependencies, akin to a smoke detector for your software supply chain. However, it must only alert when action is truly required. These tools should prompt timely updates and prevent complacency.

Collaboration and Continuous Improvement:

• Participate in or align with initiatives like the Open Source Consumption Manifesto and collaborate with industry groups to stay informed about emerging risks and best practices.
• Review and refine your open source consumption policies regularly based on the latest industry research and metrics, ensuring your organization stays ahead of new threats and challenges.

Stay Vigilant Against Malicious Open Source Software:

• Be particularly cautious when integrating new or lesser-known components into your software. The rise of malicious packages targeting innovative or less frequently used projects necessitates heightened awareness and rigorous validation.
• Avoid dependency management approaches that always update components to the latest version. Instead, upgrades should be considered based on an optimal version and the optimal version zone, both strategies we addressed in last year’s report.

Work in the Upstream:

• Participating in open source projects helps you stay informed about bugs and vulnerabilities, align your roadmaps with open source projects, and ensure your interests are represented. Projects often appreciate the extra set of hands as it helps with their sustainability.
• Active software supply chain management involves helping maintain the open source projects you depend on. Don’t leave it to others, and avoid making yourself dependent on often unknown entities.

Address the Human Factor in Risk Assessment:

• Educate your development teams on the cognitive biases that can lead to poor risk assessment, such as overestimating the benefits of maintaining the status quo. Encourage a mindset that values proactive risk management over short-term gains.

Cybersecurity is a Universal Issue

In 2024, the policies shaping this movement have come into sharper focus and, in some cases, are already being implemented and enforced. While each country is dealing with its own set of regulations, cybersecurity is a unifying issue. As such, regulations are integral to improving the cybersecurity posture of organizations across the globe. As a global leader in protecting the software supply chain, we feel that regulations will be foundational to how the industry mounts effective countermeasures against the always-evolving cybersecurity threat landscape. Liability has shifted from just the developers to the consumers of technology, with potentially harsh financial penalties for noncompliance.

Security isn’t just a development issue; it's a boardroom issue.

Securing the software supply chain has become one of the guiding principles for this raft of legislation. As we’ve covered in this report, modern software development relies heavily on open source components, and protecting components is critical to compliance with these new standards.

Before the industry can apply rules, regulations, and best practices effectively; organizations need to be able to understand what is being demanded:

• Understanding how new policies interact with existing measures
• Knowing what organizations are impacted
• Who's responsible for what

United States

NIST SP 800-218 and Secure Software Development Attestation

When the White House issued Executive Order 14028 on Improving the Nation’s Cybersecurity, it was the first federal regulation targeting the security of software components. It was also the impetus for a wave of activity - both legislatively and industry-driven - designed to drive immediate improvements in the nation’s IT security posture. The order included a directive for the National Institute for Standards and Technology (NIST) to issue guidance on enhancing the security of the software supply chain, which it did with an update to The Secure Software Development Framework (SSDF) Version 1.1, or NIST SP 800-218.

EO 14028 also requires that system integrators and software vendors comply with the Secure Software Development Attestation Form provided by the Cybersecurity and Infrastructure Agency (CISA), which requires vendors supplying software to federal entities to certify through a CEO or an authorized designee’s signature that their software is developed securely and adheres to the Secure Software Development Framework (SSDF) guidelines established by NIST.

The Secure Software Development Attestation Form Addresses Four High-Level Practice Areas:

1. Prepare the Organization
   • Ensure that the organization’s people, processes, and technology are prepared to perform secure software development at the organization level and, in some cases, for individual development groups or projects.
2. Respond to Vulnerabilities
   • Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar vulnerabilities from occurring in the future.
3. Produce Well-Secured Software
   • Produce well-secured software with minimal security vulnerabilities in its releases.
4. Protect the Software
   • Protect all components of the software from tampering and unauthorized access.

European Union

Network and Information Security Directive 2 (NIS2)

NIS2 is the European Union’s most comprehensive cybersecurity legislation and focuses on critical infrastructure and essential services. Taking effect on October 17th, 2024, NIS2 replaces the NIS Directive from 2016 and modernizes the legal framework to keep pace with increased digitization and evolving cybersecurity threats.

Bolstering security for software supply chains is central to NIS2, and like most EU-wide legislation, NIS2 provides a minimum framework that member states must adhere to but allows for flexibility in how it’s implemented at the national level.

Australia

The Essential Eight strategies are guidelines introduced by the Australian Signals Directorate’s Strategies to Mitigate Cyber Security Incidents.

The Essential Eight Mitigation Strategies Include:

1. Application Control
2. Patch Application
3. Configure Microsoft Office Macro Settings
4. User Application Hardening
5. Restrict Administrative Privileges
6. Patch Operating Systems
7. Multi-factor Authentication
8. Regular Backups

These strategies provide a framework for organizations to evaluate current practices and increase their resiliency against cyber threats. The Essential Eight is organized around four maturity levels by which organizations can evaluate and boost their cybersecurity measures.

India

This summer, the Securities and Exchange Board of India (SEBI) introduced the Cybersecurity and Cyber Resilience Framework (CSCRF) to help enhance cybersecurity for regulated entities (REs). Critical to the CSCRF is mandating strict guidelines for software bill of materials (SBOMs) in order to improve transparency, track vulnerabilities, and mitigate supply chain risks.