When using digital technology, ensuring the security of the software supply chain has become essential due to the rising frequency and complexity of cyberattacks. Recent incidents like the SolarWinds supply chain attack and the Log4Shell vulnerability have highlighted the critical need for transparency and security in software components. A Software Bill of Materials (SBOM) plays a pivotal role in this security framework by providing detailed information about all components in a software application.
When integrated with code signing, SBOMs ensure that software remains authentic and untampered. It not only verifies the integrity and authenticity of the code but also accurately catalogues its composition, providing a comprehensive overview of all included components. Encryption Consulting LLC’s CodeSign Secure portal provides SBOM as a key feature that allows users to scan their code for vulnerabilities before deployment. By generating an SBOM scan, the portal provides a clear view of the software’s makeup, helping developers push secure code to platforms like GitHub.
SBOM in code signing, defined: scanning an artifact’s components for known vulnerabilities before it’s signed, so a signature never gets applied to code that fails your vulnerability threshold, and optionally attesting the resulting SBOM with a signature bound to the specific artifact digest, so downstream consumers can verify the component list matches what was actually shipped, not just read a document that could have been edited after the fact.
Key Takeaways
- CodeSign Secure’s SBOM scan runs before signing, as a gate: code exceeding your vulnerability threshold blocks the signature rather than shipping with a warning attached after the fact.
- An unsigned SBOM is just a document anyone could edit after the fact. For the SBOM to carry real evidentiary weight, it needs to be bound to the specific artifact digest via a signed attestation, the same mechanism used for SLSA build provenance.
- For the broader software supply chain attack surface this fits into, see Code Signing 101: Locking Down Your Software Supply Chain; for the attestation mechanism itself, see SLSA Build Provenance and Signing in CI/CD Pipelines.
What is SBOM?
An SBOM, or Software Bill of Materials, is a complete list of all the components, libraries, dependencies, and key details like licenses and versions used to build a software application. It allows organizations to comprehend their software’s composition, identify potential security risks, and ensure compliance with industry regulations.
- Vulnerability Identification: SBOMs allow organizations to pinpoint outdated or vulnerable components, enabling timely updates.
- Regulatory Compliance: Mandated by the U.S. government’s 2021 executive order for software vendors (Executive Order 14028), SBOMs ensure adherence to standards like NIST, ISO 27001, and GDPR.
- Risk Management: By providing visibility into the software supply chain, SBOMs help mitigate risks from supply chain attacks. Tools like Syft, Trivy, and various SPDX tools (e.g., SPDX SBOM Generator) are commonly used to generate these detailed lists, enabling your organization to identify and address vulnerabilities within its software components proactively.
Where SBOM Standards Stand Today
Two formats dominate: SPDX, now an ISO standard (ISO/IEC 5962:2021) originating from the Linux Foundation’s open-source license tracking work, and CycloneDX, OWASP’s security-focused format built specifically to surface vulnerabilities and outdated components. CodeSign Secure’s scan is compatible with both, so the format choice comes down to whether your downstream consumers or compliance framework specify one. Executive Order 14028 (May 2021) mandated SBOMs for federal software acquisitions and is the regulatory anchor most enterprise SBOM requirements trace back to.
Benefits of SBOM
SBOMs provide significant advantages across the software lifecycle, benefiting developers, buyers, operators, and the broader ecosystem. Below are the key benefits as per the user roles, such as Developer, Buyer, or Operator, drawn from industry insights and strategies:
| User Roles | Benefits | Example |
|---|---|---|
| Developers |
|
For instance, a critical vulnerability (CVE) is announced for an open-source library that a financial software company uses. The development team can immediately query their internal SBOMs for all their applications. Within minutes, they identify which specific applications are affected, down to the version of the vulnerable library. They can then prioritize patching or upgrading those applications, minimizing their exposure to the new threat without manually reviewing countless lines of code. |
| Buyers |
|
For example, a large enterprise is evaluating two different HR management systems from competing vendors. ‘Vendor A’ provides a detailed SBOM, which shows all the third-party libraries, their licenses, and known vulnerabilities (with remediation plans), whereas ‘Vendor B’ provides no SBOM. The enterprise’s security team can use Vendor A’s SBOM to assess the security level of their product confidently, identify potential licensing conflicts, and demonstrate due diligence to auditors, making ‘Vendor A’ a much more attractive and trustworthy choice. |
| Operators |
|
For instance, a new, critical vulnerability in a widely used web server component (e.g., OpenSSL) is publicly disclosed. The operations team can cross-reference this vulnerability with the SBOMs of all their deployed applications and infrastructure components. This allows them to instantly pinpoint every server or application that utilizes the affected OpenSSL version. Instead of a manual, time-consuming audit, they can rapidly initiate targeted patching across only the impacted systems, significantly reducing the Mean Time to Respond (MTTR) to the incident and maintaining system availability. |
Consequences of Not Using SBOM
Failing to adopt SBOM can lead to considerable risks and vulnerabilities, especially given our current cyberspace and threats.
| Consequence | Description | Example |
|---|---|---|
Insecure Products | Without an SBOM, vulnerabilities in third-party components may go undetected, increasing the risk of cyberattacks. | SolarWinds Supply Chain Attack (2020): Attackers inserted malicious code into a legitimate software update from SolarWinds, a widely used IT management company. An SBOM for the SolarWinds software, if properly utilized, could have helped detect the presence of the unauthorized, malicious component during the build or deployment process, potentially preventing or significantly limiting the impact of this widespread supply chain attack. |
| Missed Security Updates | Lack of visibility into components makes it hard to know when updates or patches are needed, leaving software exposed. | Log4Shell Vulnerability (2021): The critical Log4Shell vulnerability in the Apache Log4j library impacted countless applications globally. Organizations without SBOMs struggled immensely to identify all instances of Log4j within their systems. They had to undertake massive, manual efforts to scan codebases and deployed applications, leading to delayed patching and prolonged exposure to a severe remote code execution vulnerability. |
| Legal Challenges | Untracked licenses can lead to violations, resulting in legal battles, financial penalties, and reputational damage. | GPL Violations (Numerous Cases): Many companies have faced legal action (or public scrutiny) for violating open-source software licenses, particularly the GNU General Public License (GPL). Without an SBOM clearly documenting the licenses of all included components, a company might inadvertently distribute software containing GPL-licensed code without providing the required source code, leading to infringement claims, product recalls, and significant reputational harm, as seen in cases involving various embedded device manufacturers or software distributors. |
| Unmet Compliance Requirements | Industries like healthcare require SBOMs for compliance (e.g., FDA’s “refuse-to-accept” policy). Non-compliance can delay product launches and incur costs. | Medical Device Regulations (FDA): The U.S. FDA, through guidance and policies, increasingly requires medical device manufacturers to provide SBOMs for their software. A medical device company failing to provide a detailed and accurate SBOM for a new device could have its submission rejected by the FDA, leading to significant delays in product approval, loss of market opportunity, and substantial financial costs associated with rework and resubmission. |
| Inefficient Development | Without SBOM, developers face delays in incident response, resource wastage, and challenges in managing dependencies, leading to bloated code. | “Dependency Hell”: A development team building a complex application without an SBOM might find themselves in “dependency hell,” where conflicting versions of libraries cause build failures or runtime errors. When a security vulnerability is discovered, the absence of an SBOM forces developers to manually trace dependencies, potentially spending days or weeks identifying affected modules and their transitive dependencies, leading to inefficiency, delays, and an increase in development costs. |
SBOM in Encryption Consulting’s Code Signing Solution
Encryption Consulting LLC’s CodeSign Secure portal integrates SBOM to provide a robust solution for code signing and security. Here’s how to use the SBOM feature from our CodeSign Secure:
Access the SBOM Feature
Initiate a Scan
-
Click the Scan Code button.
-
Enter required details, including a GitHub Personal Access Token (PAT) for
repository access.
- To generate a PAT:
-
Go to GitHub settings > Developer Settings > Personal Access Tokens.
- Select “Tokens (classic)”.
- Click “Generate new token (classic).”
- Add a token note and grant permissions for “repo” and “workflow.”
Upload Code
Review Results
-
If vulnerabilities are below the specified threshold, a success message confirms the code is safe.
-
If vulnerabilities exceed the threshold, a warning message will prompt you to address the issues.
Is the SBOM Itself Signed?
Generating an SBOM answers “what’s in this artifact.” It doesn’t by itself answer “can I trust that this SBOM actually describes this artifact,” since an unsigned SBOM is a document anyone could edit after the scan ran. Closing that gap requires an attestation: a signed statement binding the SBOM’s exact content to the specific artifact digest it describes, so a downstream consumer verifying the attestation’s signature can trust the listed components genuinely match what they’re running, not just that someone produced a plausible-looking file.
This is the same in-toto attestation framework SLSA build provenance uses, so a pipeline that already produces signed provenance can extend the same signing infrastructure to attest its SBOMs rather than treating them as a separate workflow. CodeSign Secure’s vulnerability gate runs the scan before signing; pairing that with a signed SBOM attestation closes the loop from “this passed the scan” to “this specific artifact, verifiably, is what passed the scan.”
VEX: Filtering the Noise
An SBOM lists every component; it doesn’t say whether a given CVE in one of those components is actually exploitable in your specific build. The Vulnerability Exploitability eXchange (VEX) format complements SBOM by letting a vendor state that explicitly, cutting down the alert fatigue of chasing CVEs that don’t apply to how a component is actually used in your artifact.
Frequently Asked Questions
Does CodeSign Secure block signing if the SBOM scan finds vulnerabilities?
Yes, based on a configurable threshold. Code exceeding the threshold returns a warning and doesn’t proceed to signing; code within the threshold gets a success confirmation and can be signed.
Which SBOM formats does CodeSign Secure support?
The scan is compatible with both dominant formats, SPDX (ISO/IEC 5962:2021) and CycloneDX. Which one to generate typically depends on what your downstream consumers or compliance framework requires.
Is an SBOM the same as a signed attestation?
No. An SBOM is the component list itself; an attestation is a signed statement binding that list to a specific artifact digest. Without the attestation, an SBOM is just a document someone could edit after the fact.
Conclusion
The Software Bill of Materials is an important tool for organisations to navigate the complexities of modern software development. SBOMs enable organizations to manage risks, ensure compliance, and build secure applications by providing transparency into software components.
Encryption Consulting LLC’s CodeSign Secure leverages SBOM to help users scan code, identify vulnerabilities, and confidently deploy. Along with this, it is truly a future-proof solution for software integrity. It provides robust support for reproducible builds, ensuring software artifacts’ consistent and verifiable reconstruction before signing using pre/post hash validation. Furthermore, CodeSign Secure is designed to facilitate the transition to post-quantum cryptography (PQC), helping organizations proactively adapt their signing processes to resist the threats posed by future quantum computing advancements.
By automating workflows, ensuring compliance, and leveraging advanced security features such as vulnerability scanning, reproducible builds, and post-quantum cryptography (PQC), CodeSign Secure empowers organizations to protect their software assets while maintaining trust in their products.
