.svg)
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.
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.
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*:
*source: https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf
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.
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.
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.
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:
When an artifact moves through CI and CD pipelines, the SSCA module checks the artifact and its associated SBOM against defined policies.
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.
To learn more about Harness SSCA and how it can enhance your DevSecOps practices, visit https://www.harness.io/products/software-supply-chain-assurance
Sign up for our free plan, start building and deploying with Harness, take your software delivery to the next level.
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
.svg){kind=small}
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.
