Last week, we hosted a highly anticipated webinar with guest speaker Katie Norton, Research Manager at IDC. The task: to discuss the latest IDC software supply chain research and recommended tools and best practices to proactively reduce open source risk. Below are our highlights, including why securing the software supply chain is important, Katie’s insights on recommended approaches, and more. To hear about all of IDC’s findings and more detail on Katie’s recommendations, you can watch the entire webinar on-demand by following this link. 

Why are we focusing on the open source software supply chain?

Growing number of supply chain attacks and government reactions

Government action has added fuel to the growing momentum to address software supply chain attacks. Executive order (EO) 14028, OMB memo M-22-18, U.S. Omnibus Appropriations Bill, and the National Cybersecurity Framework are just a few examples of government movements to improve cybersecurity—and this is only in the U.S.

Katie highlighted, “Particularly, the U.S. government is looking to leverage both procurement processes and legislation to enforce security standards. This will significantly impact organizations selling software to the U.S. government, but I also believe these recommendations will have a downstream impact. As more software providers adopt these standards, non-governmental organizations are going to expect that same due diligence.” 

In addition to these ecosystem regulations, IDC reported that, when compared to 2022, 2023 saw a 241% increase in software supply chain attacks, and that 64% of organizations surveyed were impacted by a vulnerability or compromise associated with open source software. So it’s no wonder that IDC found that the top two application security gaps were the growing use of open source software (31%) and a vulnerable software supply chain (29%).

What is the software supply chain?

“At IDC we define the software supply chain as comprising everything and everyone that touches an organization’s code in the software development life cycle (SDLC), including the people, processes, open source dependencies, and tools,” Katie explained. “What I want to emphasize here is the everything and everyone point. A supply chain, when you look at it even in non-software terms, it’s that entire system of producing. So, even as we narrow in on open source, it’s not just about open source—it’s a huge, entire process we need to ensure the security of.” 

Katie gave an example of how complex a supply chain can be with the example of the production of Honey Nut Cheerios. 

Katie drove the message home, “When we’re talking about software supply chain security, we’re talking about that end-to-end process—where code is deployed and the security of all of the steps, tools, and people that are involved in creating it.” 

Recommended approaches to securing the software supply chain

Standards, frameworks, and best practices

Over the last few years, we’ve seen more industry and government standards developed to help improve the state of national, organizational, and personal cybersecurity. Incidents such as the SolarWinds hack on proprietary software and the log4j open source vulnerability highlighted the need for a more robust standard around software security. 

Katie made a point to emphasize the importance of looking for new ways to proactively ensure the open source packages you use are secure and well maintained and follow many of these industry best practices.

“Proactive open source security necessitates that you must look for threats and identify gaps in your security posture before an incident or breach takes place. What’s really important here is that you don’t have to start from scratch before undergoing an assessment. There are a whole host of standards, frameworks, and best practices that can help with this. In many cases, these frameworks consist of research and tested best practices, even if they may be tailored to meet certifications or certain compliance requirements.” 

“Organizations that can understand and adopt these standards will be far better equipped to fortify their software supply chains and eliminate unnecessary risks. When choosing a standard, it’s important to prioritize which standards you may be beholden to. Once you’ve selected a standard, or several standards to follow, you need to go through that assessment process—looking at what your current state is, and then map the steps you need to take to progress forward in meeting those standards better.” (For a full list of suggested practices, you can watch the webinar on-demand.) 

Software bill of materials (SBOM) management

It’s likely that many of our readers have heard about SBOMs—they’re often seen as the first steps towards understanding what’s homed in your organization’s applications. However, what’s often less discussed is what comes after generating an SBOM. How do we make SBOMs more effective? How can we use them to proactively manage the open source we use? 

Katie offered her insights on the often overlooked next steps in SBOM-generation, “An SBOM has a lot of value, it can help you proactively identify vulnerabilities throughout the software supply chain. However, to be a truly effective mechanism for aiding in the security of your supply chain at scale, they have to be integrated into your daily operations, or operationalized into your existing tools and security ecosystems at your organization.”

“A static SBOM provides little benefit other than checking a box. When SBOMs are generated for every deployment or delivered release for an application, that’s going to create SBOM sprawl over time and become unmanageable. Organizations need to look to SBOM management solutions to provide a centralized repository or database. These solutions should be able to ingest both internally and externally-created SBOMs, and should be able to reconcile SBOMs and normalize that data to be able to provide that unified, organization-wide view. Developing a more comprehensive and collaborative SBOM practice is going to help you establish more proactive software information and risk management programs.”

On open source and SBOMs, Katie added, “When you’re including open source components in your application code, you're acquiring all the subsequent components used by them and you’re inheriting all of the transitive dependencies. Without SBOMs and SBOM management, organizations are not going to be able to truly identify vulnerabilities and risks and take proactive steps to mitigate that risk.”

Managed open source

Beyond tackling SBOM development and interpretation, there’s managing open source usage across an organization. Open source management involves creating a pre-vetted catalog of open source packages, helping prevent bad packages from entering an organization’s application from the start (rather than reactively removing bad packages after a vulnerability incident).

Katie defined managed open source as, “...the process of outsourcing the management of your internal repository to a third party. Most of these services are provided as a SaaS and provide you an offering where the provider is going to keep the open source your organization is using up-to-date while reducing the administrative overhead of management of your repository.” 

“Some key benefits of working with a managed open source provider include: 

• a catalog of pre-vetted open source components that removes the burden of research that your development teams have to do,
• insight and control of the open source your developers are embedding into your application,
• and making sure that the open source you’re using meets your organization's security, risk, and compliance standards.

One of the biggest values of using a managed open source provider is allowing your organization to focus more on developing compelling applications and delivering business value; rather than spending their time having the burden of managing all of this as part of their day-to-day development work.” 

Open source software project intelligence

The fourth recommended means to proactively reduce open source risk is by using an open source software intelligence tool. With an SBOM generated and an understanding of the open source in use at your organization, the next step is proactively identifying safe-to-use packages and mitigating issues before they become a vulnerability. 

Katie started off by defining these tools and what makes them different from everyday scanners, “These solutions take a more proactive slant, especially when you compare it to something like Software Composition Analysis (SCA) tools. Rather than focusing on known vulnerabilities, it involves examining that open source project ecosystem for potential threats. Some examples include: monitoring for anomalous behavior from project contributors, how timely security flaws are fixed in a project, project maintenance, popularity—all of the metadata that reflects the health of a project.” 

Katie added emphasis on the proactive aspect of these tools, “Most organizations have tons of vulnerability data telling them what their vulnerabilities are, which packages might be impacted, and often how to reconcile or remediate that. However, organizations now are starting to look for insights into a package that might help them identify potential vulnerable projects down the line. As a result, they’re potentially minimizing the need to do remediation work in the future.” 

On package monitoring, Katie noted, “Additionally, projects are constantly being updated and changed. Not only that, there are often new leading indicators of what might suggest an insecure package and that changes over time as new risks are revealed and security research is done. Where open source project intelligence is really key here is that it can help organizations identify and replace those potentially bad open source packages that might have previously been pulled into their SDLC and considered safe, but may now not be—allowing them to mitigate the issue before they are impacted by a vulnerability.” 

How can Tidelift help organizations proactively manage their open source usage?

Tidelift takes a unique, data driven approach to help organizations get more proactive. There are four distinct actions that we see our customers implementing:

• Evaluating packages before pulling them in for application development: When researching and evaluating open source packages to use, Tidelift’s package recommendations provide an excellent starting point. The recommendation is a holistic evaluation of the package, and whether it is developed and maintained in a way that would make it a good fit for application development.
  
  
• Actively monitoring the open source packages in use: Open source packages are constantly changing. With Tidelift organizations can identify leading indicators of warning such as changing license types, impacted by a new vulnerability, change in maintenance status of a project –– whether it is end-of-lifed, getting abandoned, or a version being marked as end-of-support.
  
  
• Identifying and eliminating potentially bad packages already adopted: While it is ideal to identify and avoid bad packages in the first place, most organizations will have already adopted a significant number of packages without having done the upfront research. Tidelift helps organizations evaluate their existing open source dependencies and prioritize the work to migrate away from bad packages
  
  
• Reinforcing at-risk packages to keep them from becoming bad: Tidelift customers play a direct role in ensuring the packages our customers rely on keep getting better because package maintainers are paid based on factors that include customer usage. Maintainers use this income to improve the secure development practices they have in place, to document these practices, and to commit to maintaining them over time.

— — — — — — — —

In 2024 it’s vital to start thinking beyond SBOM generation by applying proactive measures such as open source management and open source software project intelligence tools. These, along with staying up-to-date with current standards and policies will reduce risk and liabilities and help improve the overall health of your applications. Our summary only covers a portion of the insights Katie brought to discuss and we recommend watching the whole webinar to learn more about IDC’s research, Katie’s recommendations, and experience an engaging Q&A with answers to questions you might have.