10th Annual State of the Software Supply Chain®
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.
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
Click on a region of the map for an update on governance and regulations in 2024
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:
The Secure Software Development Attestation Form Addresses Four High-Level Practice Areas:
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.
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.
Produce Well-Secured Software
Produce well-secured software with minimal security vulnerabilities in its releases.
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. In particular, it sets for minimum cybersecurity risk management measures and reporting obligations in Article 21, Section 2 of NIS2.
NIS2 goes into effect on October 17th, 2024 and replaces the NIS Directive from 2016.
These include:
(a) policies on risk analysis and information system security;
(b) incident handling;
(c) business continuity, such as backup management and disaster recovery, and crisis management;
(d) supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;
(e) security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;
(f) policies and procedures to assess the effectiveness of cybersecurity risk-management measures;
(g) basic cyber hygiene practices and cybersecurity training;
(h) policies and procedures regarding the use of cryptography and, where appropriate, encryption;
(i) human resources security, access control policies and asset management;
(j) the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate
NIS2 also places an emphasis on reporting and requires organizations to submit an early warning of significant cybersecurity incidents within 24 hours. These need to be submitted to the relevant CSIRT and indicate if the significant incident is suspected of being caused by unlawful or malicious acts. Within 72 hours, the first report must be updated to include an initial assessment of the incident, including severity and impact. Within a month, a final report is required that includes a detailed description of the incident, including its severity and impact, the type of threat or root cause that is likely to have triggered the incident, and ongoing mitigation measures being taken.
The Digital Operational Resilience Act (DORA)
DORA is expected to go into effect in January 2025 and applies to every bank, investment service, and insurance company doing business within the European Union – more than 20,000 companies and third-party service providers. Like other regulations, it’s also chiefly concerned with the integrity of open source components and considers software composition analysis (SCA) as a basic security requirement that all institutions under its guidance must apply. To this end, DORA includes language outlining how to achieve a high level of digital operational resilience and emphasizes open source analysis as a fundamental security requirement:
To reflect differences that exist across, and within, the various financial subsectors as regards financial entities' level of cybersecurity preparedness, testing should include a wide variety of tools and actions, ranging from the assessment of basic requirements (e.g. vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing or end-to-end testing) to more advanced testing by means of TLPT.
The Cyber Resilience Act (CRA)
The European Parliament approved the CRA in March of 2024, and most of its provisions become enforceable starting in 2027. This sweeping legislation, which establishes essential requirements for manufacturers to ensure their products reach the market with fewer vulnerabilities, applies to any software or hardware product and its remote data processing solutions, as well as products with digital elements whose intended use includes a logical or physical data connection to a device or network.
Specifically, the CRA sets a standard for digital resiliency in the EU through a focus on the security of the software supply chain by placing key requirements for the security of software components, vulnerability handling, and reporting requirements on suppliers.
Again, the CRA has been developed with an eye toward protecting open source software. Incorporating robust security measures into the development process is necessary to strengthen your approach to OSS components and SDLC processes that take into account established best practices that will minimize risks. As a result of the CRA, all software components will be required to obtain the CE certification mark.
Organizations will be held accountable if any software or hardware product that contains digital elements is found to be non-compliant. If products are discovered to be non-compliant, sanctions will apply, including fines of up to €15 million or 2.5% of a company's global annual turnover, whichever is higher.
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:
The Essential Eight Mitigation Strategies Include:
Application Control
Patch Application
Configure Microsoft Office Macro Settings
User Application Hardening
Restrict Administrative Privileges
Patch Operating Systems
Multi-factor Authentication
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 four maturity levels by which organizations can evaluate and boost their cybersecurity measures.
Maturity Level Zero
This maturity level signifies that there are weaknesses in an organization’s overall cyber security posture. When exploited, these weaknesses could facilitate the compromise of the confidentiality of their data or the integrity or availability of their systems and data, as described by the tradecraft and targeting in Maturity Level One below.
Maturity Level One
The focus of this maturity level is malicious actors who are content to simply leverage commodity tradecraft that is widely available in order to gain access to, and likely control of, a system.
Maturity Level Two
The focus of this maturity level is malicious actors operating with a modest step-up in capability from the previous maturity level. These malicious actors are willing to invest more time in a target and, perhaps more importantly, in the effectiveness of their tools.
Maturity Level Three
The focus of this maturity level is malicious actors who are more adaptive and much less reliant on public tools and techniques. These malicious actors are able to exploit the opportunities provided by weaknesses in their target’s cyber security posture, such as the existence of older software or inadequate logging and monitoring. Malicious actors do this not only to extend their access once initial access has been gained to a target but also to evade detection and solidify their presence. Malicious actors make swift use of exploits when they become publicly available, as well as other tradecraft that can improve their chance of success.
Australian ISM Software Development Guidelines
Another Australian measure to boost cybersecurity is the March 2024 update to the Australian Signals Directorate’s Information Security Manual (ISM). The ISM provides a framework based on risk management principles and best practices to help CISOs, CIOs, cyber security professionals, and IT managers protect their systems and data from cyber threats.
The ISM includes cyber security guidelines designed to ‘provide practical guidance on how an organisation can protect its systems and data from cyber threats.’ These include Guidelines for Software Development, which provide a useful set of guidelines for creating traditional and mobile applications to increase security. The ISM is a framework, so organisations are not yet required by law to comply. However, it’s a useful tool for companies to ensure they do not violate existing legislation, and under its guidance, organisations can put up a pretty effective defence against data breaches.
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.
SEBI characterizes the importance of SBOM management and its benefits in the CSCRF with the following:
Recent security breaches at third-party vendors like Apache (Log4j), Solarwinds, etc. have led to the introduction of Software Bill of Materials (SBOM) that enables an organization to identify possible vulnerabilities in the applications/ software solutions.
Key SBOM mandates of the CSCRF include:
- New software: REs must obtain SBOMs for any new software products or Software-as-a-Service (SaaS) applications related to core and critical activities during procurement.
- Existing software: SBOMs must be obtained for existing critical systems within six months of CSCRF issuance.
- Ongoing updates: SBOMs must be updated with each software upgrade or modification.
- Legacy systems: Where SBOMs are unavailable for proprietary or legacy systems, RE boards must provide approval, detailing the rationale and risk management approach.
Benefits For REGULATED ENTITIES IN INDIA WITH THE INTRODUCTION OF SBOMS:
Transparency
REs will become more aware of components, versions, licenses, cryptographic hashes, etc., that they are using in their software applications. This will make the REs well-informed to make better security decisions.
Tracking Vulnerabilities
Es will be able to track the vulnerability status for each of the components as and when an update is made or a component is added/ deleted.
Mitigate Risk
REs will be able to prevent and mitigate supply chain risks arising due to open-source or third-party dependencies (e.g., libraries, repositories, etc.) in software components.
Audit
REs will have the confidence that only authorized third-party dependencies have been used in their software applications and that they can be audited as and when required.
The Evolving Landscape of Software Regulations
As the software industry matures, we can anticipate that regulations around the world will increase as well.
Reliable Dependency Management
Since inception, Sonatype has led with the precision and accuracy of our open source intelligence. From the start, our core principle has been to avoid wasting engineers’ time with false positives and negatives. As open source usage and security research exploded, the number of true risk findings has increased dramatically. This has created a significant burden on development productivity, forcing organizations to choose between ignoring material risks and impairing productivity.
The only possible path forward as we see it is to use a reliable dependency management automation platform that scales as needed and only updates component versions when necessary. This automation cuts down the noise, reduces persistent risks, improves open source component quality and creates a better malware defense while saving valuable engineering time with full transparency.
Implementing reliable automation for open source dependency management can have a transformative shift in your organization:
- Reduced conflict and seamless collaboration between security and engineering teams
- Improved productivity by freeing up 5% of engineering capacity
- Enhanced security due to a significant drop in open source risk levels
- Quality and reliability improvements by integrating high-quality open source components
- Better competitive advantage through improved security and increased productivity
Sonatype leverages three unique data sources to understand global open source software usage:
1.
Millions of Enterprise Applications: Regularly analyzed to track trends and behaviors
2.
Sonatype’s Nexus Repositories: Insight into hundreds of thousands of usage patterns
3.
Maven Central:
Observing Java open source consumption patterns
As many organizations continue to make suboptimal open source version choices, Sonatype’s intelligent software composition analysis (SCA) enhances developer efficiency and risk management without altering workflows. By prioritizing risks and automating dependency management throughout the software development life cycle (SDLC), we achieve significant improvements. This win-win scenario boosts competitiveness and innovation across the board.
Intelligent dependency management automation is set to revolutionize software supply chain optimization, making secure and efficient development as the industry standard. By combining dependable automation with prioritizations like advanced reachability analysis, developers are empowered to produce high-quality software more quickly within their existing workflows. Security teams gain from enhanced risk prioritization, focusing on actionable vulnerabilities. Our tools integrate seamlessly with collaboration platforms, enhancing the governance of the dependencies.
Download the Full Report