Open Source Software (OSS) has changed the game for building and deploying complex modern applications in two ways. First, developers are incorporating a myriad of OSS artifacts into their software and by using these prefabricated building blocks, they are able to pump out new applications with unprecedented speed. Second, the proliferation of OSS artifacts throughout the software development lifecycle makes building secure applications more complicated, given the scant visibility most organizations have into the vulnerabilities that each OSS component introduces into the incorporating software.
OSS Risks are a Major Software Security Blind Spot
The risk of vulnerable components within the software supply chain can be devastating for software organizations. Look no further than the Solarwinds, Log4j, and Codecov breaches to see that a single, compromised artifact can wreak havoc for tens or hundreds of thousands of the software’s consumers.
These high profile breaches culminated in the White House’s issuance of Executive Order 14028, which mandates that software producers account for and ensure the integrity of their applications and all of the artifacts incorporated therein. Complying with EO 14028 necessitates the adoption of a Software Bill of Materials (SBOM)– essentially a detailed inventory of an application’s components within a given codebase or software build. It includes information on the OSS components and license type, as well as information on known vulnerabilities related to those components. That said, the SBOM is the new currency for ensuring software integrity.
The Software Bill of Materials, In Detail
According to Gartner, the Software bill of materials (SBOM) “improves the visibility, transparency, security and integrity of proprietary and open-source code in software supply chains.” Managing the SBOM throughout the software development lifecycle is a vital capability of any successful DevSecOps program.
What information is actually included in a SBOM? At a minimum (according to the National Telecommunications and Information Administration), a software bill of materials should document the following parameters*:
Supplier Name: The name of an entity that creates, defines, and identifies components
Component Name: Designation assigned to a unit of software defined by the original supplier
Version of the Component: Identifier used by the supplier to specify a change in software from a previously identified version
Other Unique Identifiers: Other identifiers that are used to identify a component, or serve as a look-up key for relevant databases
Dependency Relationship: Characterizing the relationship that an upstream component X is included in software Y
Author of SBOM Data: The name of the entity that creates the SBOM data for this component
Timestamp: Record of the date and time of the SBOM data assembly
Currently, there are three standard SBOM formats: SPDX, CycloneDX, and SWID. However, SPDX and CycloneDX are the most widely used.
In addition to being an indispensable tool for tracking a software artifact’s security vulnerabilities, SBOMs are also useful for verifying license compliance, establishing visibility across a software portfolio in the case of mergers or acquisitions, and identifying alternatives for artifacts that are at the end of their useful life.
Making SBOM Management Part of Your DevSecOps Practice
SBOMs have a lifecycle of their own, throughout which they need to be generated, updated, verified, and signed. Typically, an SBOM is first generated within the build phase, where much of the critical data for a reliable, detailed SBOM exists. Updates can happen frequently; for example, scanning software dependencies recursively after a build may require changes to the SBOM. Ultimately, lifecycle management needs to be automated and easily orchestrated across software development pipelines without slowing down developers as they build their applications.
SBOM Orchestration and Lifecycle Management With Harness
The Harness Platform’s SSCA module offers users intuitive, automated workflows for generating and orchestrating SBOMs throughout their pipelines. Users have the option of using their preferred tools for generating SBOMs in both CycloneDX and SPDX formats. Moreover, Harness SSCA empowers users to sign and validate SBOMs using their private keys, ensuring secure storage and sharing with software consumers.
The Harness SSCA module generates, manages, and analyzes SBOMs for software artifacts. Below is the SSCA workflow for generating a SBOM:
SSCA supports SPDX and CycloneDX formats for SBOM generation and tools such as Syft and Cosign. When an SBOM is generated, the SSCA module generates and signs the attestation, ensuring that the information is accurate and trustworthy. The attestations are then securely stored in your artifact repository, where you can access and analyze them as needed.
Policy-driven OSS Governance
With Harness, DevSecOps teams have full control over the use of OSS components throughout CI and CD stages via the SSCA module’s policy management and enforcement capabilities. To make sure only compliant artifacts are deployed, two types of policies can be enforced:
Deny list policies: Define components, or combinations of component attributes, that are not allowed. If an artifact includes a component that is part of the deny list, the artifact's policy evaluation fails.
Allow list policies: Define components or combinations of component attributes that are allowed. If an artifact includes a component that is not part of the allow list, the artifact's policy evaluation fails.
When an artifact moves through CI and CD pipelines, the SSCA module checks the artifact and its associated SBOM against defined policies.
Ensuring Software Integrity, The Harness Way
More and more enterprise organizations are taking a platform approach to building out their DevSecOps practices, and a big reason why customers come to Harness is the seamless integration of key security capabilities such as SBOM generation and orchestration.