Merge pull request #33 from shiftleftcyber/2026-03-06-blogposts

Add Recent Blog Posts

Author: j28smith

marketing/content/blog/2026-02-02-implementing-data-aware-signing.md

@@ -0,0 +1,77 @@
++++
+author = "Jason Smith"
+title = "Implementing Data-Aware Signing"
+date = "2026-02-02"
+linkedin = "https://www.linkedin.com/posts/j28smith_sbom-openssf-supplychainsecurity-activity-7424218592931405825-MBC5"
+image = "img/thirdparty/2026-02-02-data-aware-sbom-signing.png"
++++
+
+I recently argued that with SBOMs we need to stop signing the "container" (the file) and start signing the "content"
+(the data). But how do we actually implement this without making verification a nightmare?
+
+The answer lies in moving away from simple bit-for-bit hashing and toward Data-Aware Integrity. Here is the technical
+breakdown of how we build a resilient chain of trust.
+
+## 1. The Foundation: JCS
+
+To sign data-aware JSON, you must first transform it into an "invariant format".
+[RFC 8785: JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785) is the industry standard for
+this. It ensures that no matter how a tool handles the file, the cryptographic input remains identical. The first
+sentence of the RFC 8785 abstract says it all:
+
+> Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the
+> operations are reliably repeatable.
+
+The JCS process involves:
+
+- **Deterministic Property Sorting:** Keys are sorted lexicographically (alphabetical or dictionary order).
+- **Whitespace Removal:** All unnecessary spaces, tabs, and newlines are stripped.
+- **Numeric Normalization:** Numbers are formatted consistently (1.0 vs 1).
+- **Encoding:** The result MUST be encoded in UTF-8.
+
+By running JCS before you hash, a minified SBOM and a pretty-printed SBOM result in the exact same signature.
+
+## 2. Digital Signatures and the Role of JSF
+
+CycloneDX natively supports **JSON Signature Format (JSF)** for document integrity, whereas the SPDX specification does
+not explicitly define a standard for handling signatures. While SPDX typically relies on external, detached signature
+files, CycloneDX allows for an **embedded signature** directly within the JSON structure.
+
+A critical, albeit specialized, feature of JSF is **Property Exclusion**. This allows producers to cryptographically
+lock the core components of an SBOM while leaving specific fields (such as vulnerabilities and VEX information)
+unsigned. This enables security teams to enrich the SBOM with updated vulnerability context later in the lifecycle
+without invalidating the original build-time signature.
+
+How it works technically:
+
+1. The producer defines a list of fields to be excluded from the signature.
+2. During signing/verification, the tool removes these fields from the SBOM data.
+3. The remaining data to be signed/verified is then passed through the JCS process to create the canonical hash.
+4. The canonical hash is used to generate or verify the SBOM signature.
+
+This ensures that the "facts" provided by the build system are cryptographically locked, even if the "context" around
+them is enriched later in the lifecycle.
+
+## 3. The "Embedded" Challenge
+
+Because CycloneDX signatures can live inside the SBOM document itself, you have a recursive problem: you cannot sign or
+verify a file directly that contains the signature itself. At a basic level, property exclusion is a functional
+necessity and is implied for any embedded signature as the signature property itself must be excluded from the signing
+and verification process to avoid a circular dependency during hashing.
+
+This is why Data-Aware tools are a requirement as simple binary verifiers are structurally blind to the data model.
+
+---
+
+## Building the Standard
+
+I am currently leading an initiative within the [OpenSSF](https://openssf.org/) SBOM Everywhere SIG to codify these
+foundations into an SBOM Signing/Verification Best Practices Guide. We are moving past theory and into implementation.
+We are building the reference implementations with "known-good" test vectors so the industry doesn't have to guess and
+to ensure your tools are truly spec-compliant.
+
+Want to see where we are? We currently have reference implementations completed in Go, Python, and Java, with
+JavaScript and Rust coming soon (and other languages upon request).
+
+💬👇 Comment "SBOM Signing Best Practices" below if you want a link to the current Work-in-Progress and the reference
+code. Happy to get your feedback and input on this work while we are actively working on it.

marketing/content/blog/2026-02-09-sbom-signing-best-practices.md

@@ -0,0 +1,72 @@
++++
+author = "Jason Smith"
+title = "🚨 Call for Feedback: A Standardized Approach to SBOM Signing"
+date = "2026-02-09"
+linkedin = "https://www.linkedin.com/posts/j28smith_openssf-sbom-supplychainsecurity-activity-7426752007064985600-5cMX"
+image = "img/thirdparty/2026-02-09-sbom-signing-best-practices.png"
++++
+
+> The new benchmark by which all SBOM signing and verification tools will be judged.
+
+This Friday February 13th @ 11:00 EST I'll be presenting the initial draft of the SBOM Signing & Verification Best
+Practices Guide at the [OpenSSF](https://openssf.org/) SBOM Everywhere SIG meeting. This initial draft focuses on the
+methods used to compute the hash of an SBOM for signing and verification.
+
+The goal? To move the industry away from fragile "binary blob" signatures and toward data-aware integrity so we have a
+standardized system that truly scales across different platforms and vendor implementations. It is also a necessity to
+properly support the CycloneDX specification to have full interoperability.
+
+I've been heads-down on the reference implementations, and I'm excited to share that the JSON foundation is now largely
+complete. We have working code in Go, Java, JavaScript, Python, and Rust that proves we can maintain SBOM trust
+regardless of formatting.
+
+## ✅ The "Pretty-Print" vs "Minify" Tests Pass
+
+In our test suite, we took original SBOMs (both CycloneDX and SPDX), ran them through various "pretty-print" and
+"minify" cycles, and proved that the computed hash remains identical every time. No more broken signatures because of
+a 2-space indent change or an added/removed newline.
+
+### 🧐 What's in the WIP?
+
+**JCS Integration:** Full support for RFC 8785 *"permits data to be exchanged in its original form on the 'wire' while
+cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints
+generate consistent results"*.
+
+**Format Agnostic:** Support for CycloneDX and SPDX JSON structures, including embedded signatures and property exclusion
+in JSF for CycloneDX.
+
+**Language Diversity:** Reference implementations across 5 major ecosystems (Go, Java, JavaScript, Python, Rust).
+
+**The XML Frontier:** I'll be sharing my early findings on why W3C Exclusive C14N canonicalization isn't enough for
+XML-based SBOMs and some thoughts on how to approach XML normalization. However, the core focus for Friday will be on
+the JSON method.
+
+## 🫵 Join the Discussion
+
+I want your eyes on this. Whether you are a tool-builder, a security engineer, or a compliance officer, your feedback
+is critical to ensuring this standard is adopted and works in the real world.
+
+I want to hear from the supporters and the critics alike. If you love the approach, help us refine it. If you hate it,
+come tell me why. The only way we build a truly resilient standard is by stress-testing it against every perspective
+before it's finalized.
+
+### 📅 OpenSSF Calendar
+
+[https://calendar.google.com/calendar/u/0/embed?src=s63voefhp5i9pfltb5q67ngpes@group.calendar.google.com](https://calendar.google.com/calendar/u/0/embed?src=s63voefhp5i9pfltb5q67ngpes@group.calendar.google.com)
+
+### 🕚 Meeting Time
+
+Friday February 13th @ 11:00 EST
+
+### 🔗 Zoom Link
+
+[https://calendar.google.com/calendar/u/0/embed?src=s63voefhp5i9pfltb5q67ngpes@group.calendar.google.com](https://calendar.google.com/calendar/u/0/embed?src=s63voefhp5i9pfltb5q67ngpes@group.calendar.google.com)
+
+### 🔗 GitHub WIP
+
+[https://github.com/shiftleftcyber/sbom-signing-best-practices/tree/initial-setup](https://github.com/shiftleftcyber/sbom-signing-best-practices/tree/initial-setup)
+
+If you are unable to make it and want to discuss directly just let me know. Take a look through the GitHub repo,
+gather your thoughts and feedback, and then connect with me to book a time to discuss further.
+
+Let's stop signing the formatting and start signing the facts. Hope to see you Friday!

marketing/content/blog/2026-02-23-sbom-signature-storage-tax.md

@@ -0,0 +1,47 @@
++++
+author = "Jason Smith"
+title = "The SBOM Signature 'Storage Tax': Money Talks 💰📉"
+date = "2026-02-23"
+linkedin = "https://www.linkedin.com/posts/j28smith_finops-eu-cra-activity-7431724688411754496-7VnP"
+image = "img/thirdparty/2026-02-23-sbom-signature-storage-tax.png"
++++
+
+Over the last few weeks, I've been deep in the weeds of technical best practices for signing SBOMs. I've discussed
+JSF, JCS, property exclusion, and how we move toward data-aware integrity for better interoperability. 🔍
+
+But beyond the technical elegance of a resilient signature, there is a much simpler driver for this work: The Bottom
+Line. 💳
+
+Currently, most organizations sign SBOMs as binary blobs. This means you are signing the file (the container), not the
+data (the content). If you change a single space or minify the file for storage, the signature breaks. ❌
+
+This comes with a massive economic cost. 💸
+
+With regulations like the EU Cyber Resilience Act (CRA) mandating that manufacturers store SBOMs for 10+ years,
+storage is no longer a round-off error in your cloud budget. ☁️💵
+
+The realities of the SBOM binary blob signature storage tax... 👀
+
+## 💾 Storage Inefficiency
+
+Binary blob signatures prevent you from minifying your data. You are forced to store every space and newline to keep
+the signature valid.
+
+## 📈 The 40% Premium
+
+My initial estimates show that signing "pretty-printed" SBOMs results in ~ 40% higher storage costs (or more) compared
+to data-aware signing.
+
+## ⏳ 10-Year Compounding
+
+Across thousands of builds and a decade of mandatory retention, that "formatting debt" turns into a significant
+long-term financial liability.
+
+Technical specifications help with interoperability, but money talks. Data-aware signing isn't just about better
+security, it's about avoiding a decade-long storage tax. 🏦
+
+I brought up this point during my last presentation at the [OpenSSF](https://openssf.org/) SBOM Everywhere SIG meeting
+and the shift in the room was noticeable. It's a powerful reminder that while technical specs drive interoperability,
+economic impact drives adoption. 🚀
+
+\#FinOps \#EU \#CRA \#SBOM \#SupplyChainSecurity \#CloudCosts \#OpenSSF \#DevSecOps \#CyberResilienceAct

marketing/content/blog/2026-03-02-sbom-storage-tax.md

@@ -0,0 +1,84 @@
++++
+author = "Jason Smith"
+title = "The SBOM Storage Tax: Optimization at Scale"
+date = "2026-03-02"
+linkedin = "https://www.linkedin.com/posts/j28smith_sbom-supplychainsecurity-finops-activity-7434359722511601665-DPTT"
+image = "img/thirdparty/2026-03-02-sbom-storage-tax.png"
++++
+
+Following my last post on the "Storage Tax" of binary blob signing, I received some insightful feedback from the
+community. The common critique was:
+
+> JSON minification doesn't really matter if you compress the JSON.
+
+It's a valid point. Technically, compression will save far more than minification. But does the choice to sign the
+"data" (allowing minification) still matter if we are just going to run it through Zstandard (zstd) anyway?
+
+To find out, I ran a series of tests on the sample set of CycloneDX and SPDX SBOMs from my
+[sbom-signing-best-practices](https://github.com/shiftleftcyber/sbom-signing-best-practices) GitHub repo. I compared
+the storage footprints of pretty-printed files, minified files, and their compressed counterparts.
+
+The data confirms the initial intuition, but only if you look at the surface-level percentages. Under the hood, there
+is a "hidden" efficiency gain that still justifies a data-aware signing strategy.
+
+## The Technical Reality Check
+
+Based on my analysis of the test data, here is the breakdown of average storage savings:
+
+- **Minification:** Reduced file size by ~32%.
+- **Zstd Compression:** Reduced file size by ~79%.
+- **The "Combo" (Minify + Zstd):** Reduced file size by ~81%.
+
+At first glance, the "compression-only" camp seems to have won. Adding minification to the compression pipeline only
+appears to save an additional 2% relative to the original file size.
+
+**The 2% Trap:** While 2% of the total original file seems negligible, we don't pay for storage based on the original
+file size. We pay based on the final compressed artifact. When we look at the results through a "FinOps" lens, that
+small delta becomes more significant.
+
+## The 11% Efficiency Gain
+
+When we look at the final artifact size (the compressed file we actually pay to store), the story changes.
+
+In my tests, applying minification before Zstandard compression resulted in a final file that was 11% smaller on
+average than compressing the pretty-printed version. By stripping away the "entropy" of unnecessary whitespace and
+newlines first, the compression algorithm can focus purely on data patterns, leading to a tighter result.
+
+Let's scale that 11% efficiency gain to the requirements of the **EU Cyber Resilience Act (CRA)**:
+
+1. **10-Year Retention:** You aren't storing one SBOM. You are storing a decade of build history. 11% savings today
+compounded over time is a massive reduction in "whitespace debt" by year ten.
+2. **Enterprise Scale:** For thousands of software products and services, each with daily or even per-commit builds,
+this is the difference between manageable cold storage and a budget-breaking line item.
+3. **Global Traffic:** 11% less data means lower egress costs for every audit and transfer.
+
+In this context, an 11% reduction in your long-term storage footprint isn't just "technical elegance". It's a
+significant reduction in operational overhead and "whitespace debt".
+
+## The Recommended Storage Strategy
+
+If you are locked into "Binary Blob Signing", you are effectively forbidden from fully optimizing your data. To keep
+that signature valid for a decade, you must store the compressed "Pretty-Printed" version. As a result, you are paying
+an 11% storage tax indefinitely.
+
+To avoid the storage tax, our recommended strategy for long-term SBOM retention is:
+
+1. **Implement Data-Aware Signing:** Stop signing the container (the file) and start signing the "Facts" (the
+canonicalized data).
+2. **Minify + Compress for Storage:** Use JSON minification to strip out the structural overhead and a modern algorithm
+like Zstandard on the minified version of the SBOM to reach peak efficiency.
+
+This approach ensures that your signatures are resilient to formatting changes while your storage is optimized for the
+next 10 years of compliance.
+
+## Final Remarks
+
+I initially brought up the storage topic during my last presentation at the [OpenSSF](https://openssf.org/) SBOM
+Everywhere SIG meeting when presenting my findings on SBOM signing best practices and it sparked an immediate shift
+in the conversation. A special thank you to [Kate Stewart](https://www.linkedin.com/in/katestewartaustin/) for
+inviting me to the SPDX tech call to give the same presentation there. And thanks to the OpenSSF SBOM Everywhere SIG
+members and the SPDX Tech call members for all the feedback that prompted this deeper dive.
+
+We are moving toward a world where signing the "Facts" isn't just more secure, it's cheaper.
+
+**The benchmark is being set.** Are you signing the container, or are you signing the data?