Skip to content

Commit de2bf63

Browse files
authored
Merge pull request #26 from shiftleftcyber/feat/SBOMSigningFAQ
feat: add SecureSBOM faq
2 parents 97abfe5 + dcf2961 commit de2bf63

3 files changed

Lines changed: 237 additions & 2 deletions

File tree

marketing/content/faq.md

Lines changed: 227 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,227 @@
1+
---
2+
title: "SecureSBOM - SBOM Signing FAQ"
3+
description: "Cryptographic signing and verification of Software Bill of Materials (SBOMs) for trusted supply chain security. Ensure authenticity, integrity, and compliance."
4+
date: 2025-12-08
5+
layout: "single"
6+
---
7+
8+
A collection of common questions about how SecureSBOM works, how it integrates into your software
9+
supply chain, and what makes it different from existing signing solutions.
10+
11+
---
12+
13+
{{< faq question="What is SBOM Signing?" >}}
14+
15+
SBOM Signing is the process of applying a cryptographically verifiable signature to a Software Bill of Materials.
16+
This signature allows anyone to confirm that the SBOM:
17+
18+
* Has not been altered or tampered with, and
19+
* Comes from a trusted source
20+
21+
before it is used in downstream processes such as vulnerability management, license compliance checks, technical
22+
due diligence, or regulatory reporting.
23+
24+
But the value of signing becomes even more important as SBOMs grow in complexity. Modern software often contains
25+
multiple components or sub-artifacts, each with its own SBOM. These individual SBOMs are frequently combined into a
26+
larger, aggregated SBOM representing the entire product.
27+
28+
Consider this example:
29+
30+
You maintain a 3-part application, each part with its own SBOM. When releasing a new version, only part 1
31+
changes—parts 2 and 3 remain identical. Without SBOM signing, you would need to regenerate, rescan, and revalidate
32+
all three SBOMs every time, even though two of them didn’t change.
33+
34+
However, if each SBOM was already signed and verified, you can:
35+
* Trust the signatures on parts 2 and 3
36+
* Confidently reuse them in the aggregated SBOM
37+
* Avoid unnecessary rebuilding, rescanning, or reprocessing
38+
* Prove at any time that these SBOMs are bit-for-bit identical to the previously signed versions
39+
40+
This approach reduces operational overhead, improves build efficiency, and strengthens supply-chain
41+
integrity—especially across large or modular products.
42+
43+
With SecureSBOM, these signatures are standards-aligned, cryptographically strong, and easy to verify,
44+
enabling organizations to safely assemble, reuse, and distribute SBOMs at scale.
45+
46+
{{< /faq >}}
47+
48+
{{< faq question="What is the Threat Model for SBOMs?" >}}
49+
50+
SBOMs sit at the center of an organization’s component inventory, vulnerability management workflows,
51+
license compliance checks, change-management processes, and more. Because so many critical decisions rely on
52+
this single document, it is essential that the SBOM is authentic, comes from a trusted source, and has not
53+
been tampered with.
54+
55+
Unsigned or unverified SBOMs introduce several threat vectors, including:
56+
57+
* **Information hiding:** intentionally altering component versions or metadata to hide known vulnerabilities or license conflicts.
58+
* **Manipulation or injection:** adding, removing, or modifying components to misrepresent the actual software supply chain.
59+
* **Source spoofing:** presenting an SBOM as coming from a trusted team or pipeline when it did not.
60+
* **Integrity erosion over time:** SBOMs passed between teams or systems becoming silently modified without detection.
61+
62+
SecureSBOM addresses these threats by ensuring every SBOM can be cryptographically validated, verified against a
63+
trusted key, and checked for unauthorized modification before it is used in any security or compliance workflow.
64+
65+
{{< /faq >}}
66+
67+
{{< faq question="What is SecureSBOM?" >}}
68+
69+
SecureSBOM is the first SBOM-specific signing and verification platform built for enterprise environments.
70+
It provides a PKI-driven approach to applying standards-compliant cryptographic signatures to both CycloneDX and
71+
SPDX SBOMs—ensuring authenticity, integrity, and trust throughout your software supply chain.
72+
73+
Designed as a scalable, secure, multi-tenant, API-driven service, SecureSBOM supports:
74+
75+
* HSM-backed key storage for strong, enterprise-grade key protection
76+
* Specification-aligned CycloneDX signing, including proper canonicalization
77+
* Online and offline verification, ideal for clean-room or air-gapped environments
78+
* CI/CD integrations, including GitHub and other DevSecOps tooling
79+
* Modular workflows that support SBOM reuse, aggregation, and enterprise compliance requirements
80+
81+
{{< /faq >}}
82+
83+
{{< faq question="Why not use Sigstore?" >}}
84+
85+
Sigstore is widely regarded as the de-facto standard for open-source signing and verification workflows.
86+
It is an outstanding technology—one we actively use at ShiftLeftCyber in our own CI/CD pipelines. However, despite
87+
its strengths, Sigstore has several limitations when it comes to enterprise-grade SBOM signing,
88+
which was ultimately one of the motivations to the creation of SecureSBOM.
89+
90+
Key differences include:
91+
92+
* **Designed primarily for open-source and OCI artifacts:** Sigstore excels at signing container images and verifying
93+
them before deployment. Its architecture and tooling are optimized around OCI registries—not SBOM-specific workflows.
94+
* **SBOMs are treated as generic files:** Sigstore does not adhere to the CycloneDX Signing & Authenticity specification.
95+
It simply signs the SBOM as a blob, without respecting canonicalization rules or embedding signatures
96+
the way enterprise SBOM ecosystems expect.
97+
* **Transparency logs may expose metadata:** Sigstore’s default model involves publishing signing metadata to the Rekor
98+
transparency log. While acceptable—and even beneficial—for many open-source projects, this can be a blocker for
99+
enterprises with strict confidentiality, regulatory, or internal governance requirements.
100+
(Note: Cosign v3 disables Rekor by default, but organizations can still enable it, and many workflows rely on it.)
101+
* **Complex and costly to operate privately:** Running a private Sigstore stack is non-trivial. It requires a multi-service
102+
Kubernetes deployment, hardware and operational overhead, long-term maintenance, and expertise—making it
103+
impractical for many organizations wanting an internal signing service.
104+
105+
SecureSBOM was built to focus specifically on SBOM authenticity, support CycloneDX-native signing, and provide a
106+
lightweight, enterprise-friendly alternative for organizations who want the benefits of signing without the
107+
infrastructure burden. For a more detailed compairson between SecureSBOM and Sigstore please see the
108+
[following](/securesbom_vs_sigstore/)
109+
110+
{{< /faq >}}
111+
112+
{{< faq question="What are the challenges with SBOM Signing & Verificaiton?" >}}
113+
114+
SBOM signing and verification may seem simple on the surface, but in practice it involves several technical and
115+
operational challenges. These challenges are amplified in enterprise environments where accuracy, repeatability,
116+
and auditability matter.
117+
118+
Here are some of the most common issues:
119+
120+
**Non-deterministic formats (JSON & XML)**
121+
122+
SBOMs are often represented as JSON or XML—both of which are non-deterministic formats.
123+
Whitespace changes, field ordering, or formatting differences can break signature verification even when the SBOM
124+
content is logically identical.
125+
126+
SecureSBOM solves this through a standards-aligned canonicalization process, ensuring every SBOM is normalized
127+
before signing so verification remains consistent and predictable.
128+
129+
**PKI & key management complexity**
130+
131+
Managing keys in a PKI system is notoriously difficult. Organizations must handle:
132+
133+
* Key generation
134+
* Secure storage
135+
* Rotations
136+
* Revocations
137+
* Access control
138+
* Audit logs
139+
* Compliance requirements
140+
141+
SecureSBOM removes this burden by providing fully managed, HSM-backed key infrastructure, so teams never have to
142+
maintain sensitive key material or operate their own PKI.
143+
144+
**Complex, error-prone verification workflows**
145+
146+
Verifying an SBOM manually often requires messy combinations of tooling such as:
147+
148+
* OpenSSL
149+
* jq
150+
* Custom scripts
151+
* Vendor-specific CLI utilities
152+
153+
This leads to inconsistency across teams and makes it difficult to standardize verification policies.
154+
155+
SecureSBOM offers simple online APIs, a fully offline verification tool, & numrious intrgrations with GitHub and other
156+
3rd party tools making verification consistent across environments—including air-gapped or clean-room builds.
157+
158+
**SBOM aggregation & reuse becomes complicated without signatures**
159+
160+
Large products often consist of many subcomponents, each with its own SBOM.
161+
Without signatures, it is impossible to safely reuse or merge previously generated SBOMs.
162+
163+
With SecureSBOM, previously signed SBOMs can be verified and reused, dramatically reducing build times,
164+
rescan overhead, and reprocessing costs.
165+
166+
**Enterprise confidentiality concerns around transparency logs**
167+
168+
Sigstore was designed for open-source ecosystems, where openness and public transparency are strengths.
169+
However, this model creates two major challenges for enterprises:
170+
171+
Transparency logs (like Rekor) may expose signing metadata that internal teams or regulated industries cannot
172+
publicly disclose. Even though Cosign v3 disables Rekor by default, many workflows still rely on it, and enabling
173+
it reintroduces the same concerns.
174+
175+
Private Sigstore deployments are complex and costly. Running Sigstore internally requires a Kubernetes cluster,
176+
multiple coordinated services, storage backends, and ongoing operational maintenance—making it difficult for
177+
many organizations to adopt privately.
178+
179+
SecureSBOM avoids these challenges by offering a fully private, API-first signing service that requires no
180+
infrastructure management and exposes no metadata publicly, providing the security guarantees enterprises
181+
need without the operational overhead.
182+
183+
SBOM signing isn't just adding a signature—it requires deterministic formatting, proper spec compliance,
184+
key management, verification tooling, and enterprise controls. SecureSBOM wraps all of this into a purpose-built,
185+
SBOM-first solution.
186+
187+
{{< /faq >}}
188+
189+
{{< faq question="How does SecureSBOM Help?" >}}
190+
191+
SecureSBOM ensures that every SBOM you produce or consume is authentic, trusted, and verifiably unmodified.
192+
It solves the core challenges of SBOM signing and verification by providing:
193+
194+
* Standards-compliant, deterministic signing for both CycloneDX and SPDX
195+
* HSM-backed key management, removing the burden of running your own PKI
196+
* Simple online and offline verification tools, eliminating fragile OpenSSL/jq workflows
197+
* Safe SBOM reuse and aggregation, enabling faster builds and reduced processing overhead
198+
* Enterprise privacy and control, with no public transparency logs or external exposure
199+
* Turnkey integrations with GitHub and common CI/CD platforms
200+
201+
By combining these capabilities, SecureSBOM gives organizations a secure, scalable, SBOM-first signing solution that
202+
improves trust, reduces operational friction, and strengthens software supply chain integrity end-to-end.
203+
204+
{{< /faq >}}
205+
206+
---
207+
208+
## Get Started Today
209+
210+
### 🎯 Request a Demo
211+
212+
See SecureSBOM in action with your actual SBOMs
213+
**[Schedule Demo](/contactus/?type=demo)**
214+
215+
### 🔑 Get API Access
216+
217+
Start integrating SBOM signing into your workflows
218+
**[Request API Key](/contactus/?type=api)**
219+
220+
### 💬 Talk to Sales
221+
222+
Discuss enterprise features and custom solutions
223+
**[Contact Sales](/contactus/?type=sales)**
224+
225+
---
226+
227+
**Questions?** Our security experts are here to help. [Contact our team](/contactus/) to learn how SecureSBOM can transform your software supply chain security.

marketing/hugo.toml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -57,8 +57,8 @@ googleAnalytics = "G-CR0HB4HF2K"
5757

5858
[[menu.main]]
5959
identifier = "securesbom"
60-
name = "SecureSBOM"
61-
url = "/securesbom/"
60+
name = "SBOM Signing FAQ"
61+
url = "/faq/"
6262
weight = 1
6363

6464
[[menu.main]]
Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
<details class="faq-item">
2+
<summary class="faq-question">
3+
{{ .Get "question" }}
4+
</summary>
5+
<div class="faq-answer">
6+
{{ .Inner | markdownify }}
7+
</div>
8+
</details>

0 commit comments

Comments
 (0)