Javed Hasan is the CEO and Co-founder of Lineaje, a leader in software supply chain security management.
You wouldn’t eat a meal with expired ingredients, so why are you allowing spoiled software components to threaten your software supply chain security?
Believe it or not, food and software share many similarities. Just like your favorite recipe, each component in the software stack can have a direct impact on the final product’s (in this case, the software supply chain) quality. Contaminated food can lead to health problems, and using software with tampered, vulnerable or malicious components can also have detrimental financial and reputational effects—just look at the attack on SolarWinds, the Log4J vulnerability and, most recently, the 3CX breach. All of these incidents highlight the need for transparency and accountability within the software supply chain.
In 1990, the U.S. Department of Agriculture (USDA) mandated that all food companies were required to publish a list of nutrition facts and ingredients on all products intended to be sold. The process revolutionized nutrition and changed the way individuals bought and consumed food. The U.S. government made a similar effort in the software supply chain space in May 2021 when it issued Executive Order (EO) 14028, which requires government agencies to enhance cybersecurity and software supply chain integrity. To comply with the regulations, all software producers that work with the federal government will need to provide a software bill of materials (SBOM) for each product.
SBOMs are critical for each industry, not just those who work with the government. The recent 3CX software supply chain breach illustrates just that. 3CX is a telecommunications company that works with thousands of organizations across the globe. In the 3CX software supply chain incident, there was a clear mismatch between the source code it ingested and the packaged code it created. As a result, all of 3CX’s 12 million users’ data could be compromised—and many were.
We all know the red flags when it comes to the nutrition labels on our food, but what about our SBOM? When should an organization consider switching the software it consumes? How can an organization tell if an SBOM complies with existing government mandates such as EO 14028?
Let’s take a look.
Comparison Shopping: Not All Open-Source Software Is Created Equal
Chances are pretty high that your organization’s SBOM has some open-source software, considering open source makes up about 70% of all software. However, just like the grocery-store-brand cookies differ from Chips Ahoy or Oreos, not all open source is created equally.
Recent research from my company, Lineaje, revealed some interesting insights about open-source software risk including:
• Most (82%) open-source software components are susceptible to vulnerabilities, security issues, code quality or maintainability concerns.
• A small percentage (3%) of these components lack a known origin. We don’t know where they came from.
• Some (5.3%) fail basic integrity checks. These integrity checks might have detected the compromises that led to the 3CX and SolarWinds software supply chain attacks.
Before assembling any product using open-source software, it’s critical that organizations have formal tools in place to discover software DNA. Doing so enables IT, development, operations and security teams to continually assess the risk and integrity of software components.
Meeting Requirements: Is Your SBOM Balanced?
Just like you want to make sure you’re getting the ideal amount of protein, carbs, fats and overall calories in your diet, you also want to make sure your SBOM is compliant—and one size doesn’t fit all. In order to be considered a “balanced” SBOM, it should be published with the following in mind.
• It’s available in a standard format. such as SPDX.
• It contains the right information, which will be set by the software consumers. For example, if it’s for a federal government customer, it would likely have a lot more information.
• It discloses any and all updates. If your software changes at any point, your SBOM should reflect that. Even if you update a particular software daily, the SBOM should disclose that information.
Assess And Attest To The Quality
The Food and Drug Administration (FDA) assesses nutrition labels, and soon the EO 14028 will require procuring organizations to assess the SBOMs of all software they build or buy. The product and security teams will be the ones responsible for this. To enable accurate SBOMs and meet compliance requirements, it’s critical that these teams have the solutions in place to check code quality, security posture, supplier reputation, maintainability, vulnerabilities and provenance.
Just as food manufacturers are required to adhere to certain regulations and quality standards, the software industry should also embrace similar practices. Implementing accurate SBOMs can help establish a culture of transparency and accountability, encouraging software developers to prioritize security and quality throughout the development life cycle. It also enables organizations to comply with regulatory requirements and industry standards related to software security and mitigates the risk of a devastating software supply chain compromise.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
Read the full article here
