PulseMeter Report: Software supply chains

The not-so-distant memories of security events like Log4Shell and the SolarWinds attack keep software supply chain attacks front of mind for developers. 

There are things organizations can do to detect and deter malicious supply chain attacks, including the recently mandated (as per the U.S. federal government) software bill of materials (SBOM). SBOMs itemize the components embedded in code so that users of these applications and software packages can track potential exposures to any existing but not-yet-discovered vulnerabilities within them. 

Towards the end of 2022, Techstrong Research polled our community of DevOps, cloud native, cybersecurity, and digital transformation readers to take their pulse on SBOMs. Here’s what they found:

• Software supply chain attacks are on everyone’s mind.

• Many orgs are already using SBOMs.

• SBOMs alone are not enough.

Software supply chain attacks are on everyone’s mind

The research found that over 78% of those asked are at least somewhat worried about software supply chain attacks, and 40% of respondents were very worried. This makes perfect sense because these malicious acts are usually high profile and can be incredibly damaging. However, 25% of those asked remain passive in the face of supply chain vulnerabilities and do not comprehensively analyze the code and third-party open source libraries they leverage.

When asked about SBOMs in general, over 55% of respondents indicated that they already produce SBOMs, with 70-90% of that group also publishing their SBOMs.

Many orgs are already using SBOMs

As of December 2022, SBOMs are, by executive order, required for any software the US government purchases. While SBOMs cannot and will not solve software attacks directly, the information they provide is beneficial for identifying vulnerable software and mitigating potential attack vectors.

A software bill of materials provides detailed information around the software and libraries that make up applications, presenting critical information about what is potentially lurking within code for future assessment. This improves vulnerability response by allowing developers to identify vulnerable versions of components and, in conjunction with proper developer security tooling, mitigate at-risk features quickly.

The benefits of using a software bill of materials are:

• Improved vulnerability response and security. With an SBOM, you can verify the components/versions of components against vulnerability databases and ensure no potential vulnerabilities exist.

• Improved compliance. With SBOMs, you can easily identify components not allowed within a specific compliance framework.

• Improved reporting. With SBOMs, you have an understanding of the historical drivers for security solutions.

SBOMs alone aren’t enough

The research shows us that after years of siloed work, application security and development teams will soon need to join forces and work together to ship secure code and meet organizational mandates.

With 78% of our research respondents being somewhat afraid of software supply chain attacks, the time to act is now. We need to educate developers on security principles so they can choose less risky packages as they code, and create continuous processes that track and fix new vulnerabilities as they arise. 

Furthermore, the research shows that publishing an SBOM is necessary but insufficient on its own in helping organizations secure their code. 

Think of an SBOM as a list of ingredients. The list is generated, and while everything seems  healthy at first, you soon discover an ingredient that’s bad for you — or that a batch was compromised. 

The discovery will lead you to mitigation, but discovery alone will not mitigate the issue.

Open source needs security and automation

Of those surveyed, 25% responded that they rely on open source code for its functionality. 

Securing your open source code is still largely manual. Therefore, an excellent first step toward enhancing open source supply chain security is obtaining automated SBOM-generating technology. Automating your SBOM will enable you to identify security and compliance issues quickly. It will also provide improved vulnerability tracking for your open source libraries. 

Securing your software supply chain requires a dynamic approach, a joint effort between security and development teams, and should happen at all stages. 

Whether the components integrated into your code make up a large or small portion of the software you deploy, are imported into the code as a third-party dependency, or from a base container, security is vital

Discover more about what the Techstrong PulseMeter Report found.