Merge pull request #16 from shiftleftcyber/jason

Adding Blog Posts

Author: j28smith

marketing/content/blog/2025-06-03-evolution-of-sboms-at-ownersbox.md

@@ -0,0 +1,37 @@
++++
+author = "Jason Smith"
+title = "The Evolution of SBOMs at OwnersBox"
+date = "2025-06-03"
+linkedin = "https://www.linkedin.com/posts/j28smith_the-evolution-of-sboms-at-ownersbox-practical-activity-7335755375452823552-tvyL"
+image = "img/thirdparty/2025-06-03-evolution-of-sboms-at-ownersbox.png"
++++
+
+I gave a presentation at the CISA SBOM Community Weekly Meeting yesterday where I shared how we approached SBOMs in my latest role at OwnersBox. SBOM adoption here was driven by a real need rather than just to check a box on some regulatory/compliance framework requirement (these checkboxes later became an added benefit).
+
+In my presentation I covered:
+
+😱 The real-world incident that triggered our SBOM journey
+
+🛠️ How we built and automated SBOMs into our pipelines
+
+📝 Custom tooling to turn raw SBOMs into actionable insights
+
+✨ The impact on risk, compliance and development culture
+
+🧐 Where I see SBOMs going next - towards secure and trustable software transparency
+
+During the presentation, I also shared a fun (and slightly chaotic) story from the technical due diligence process during the acquisition of the first startup I worked at.
+
+Back then, SBOMs didn't exist. So I had to manually compile a list of all third-party software we were using. And since the team wasn't yet aware of the potential acquisition, I had to do it somewhat quietly.
+
+What followed was a week or two of digging through git repos and build files, piecing everything together by hand. 🤯
+
+It really drove home how far we've come and how valuable structured, automated SBOMs are today.
+
+I hope it helps others working to operationalize software transparency in their organizations and highlights that the real value goes far beyond simply checking a box for regulatory or compliance framework requirements.
+
+Thanks again Allan Friedman, PhD for the invite and continuing to bring the SBOM community together and promoting software transparency.
+
+👉💬 Curious to see the full deck? Comment "SBOM" and I'll DM you the Google Slides link.
+
+#SBOM #SoftwareSupplyChain #DevSecOps #AppSec #CyberSecurity #CISA #Startup #SoftwareSecurity #OpenSourceSecurity #SecurityEngineering #SoftwareTransparency #SecureByDesign #SupplyChainSecurity

marketing/content/blog/2025-06-08-sbom-signing-not-security.md

@@ -0,0 +1,49 @@
++++
+author = "Jason Smith"
+title = "🔏 SBOM Signing ≠ Security"
+date = "2025-06-08"
+linkedin = "https://www.linkedin.com/posts/j28smith_sbom-softwaresecurity-supplychainsecurity-activity-7341132648515346437-FqBE/"
+image = "img/thirdparty/2025-06-08-sbom-signing-checklist.jpeg"
++++
+
+Just because an SBOM is signed doesn't mean it's safe.
+
+Signing is still important though. It gives you integrity. You know the SBOM wasn't tampered with after it was produced.
+
+But integrity ≠ trustworthiness.
+
+Here's why:
+
+🧱 Garbage In, Garbage Out
+
+If the SBOM was generated incorrectly, with missing or outdated components, signing it just seals in the errors.
+
+🎭 Signed ≠ Honest
+
+A signature only tells you who signed the SBOM. It says nothing about whether they were truthful, competent, or even authorized to sign it.
+
+📅 Is It Still Current?
+
+Software changes fast. An SBOM signed last week may already be outdated. If you can't link the SBOM to a specific build artifact or verify it's up to date, the signature alone doesn’t help.
+
+⚖️ Trust is Contextual
+
+Do you trust the signer? Are they using your keys, their own, or a third-party authority? Just because something can be verified doesn’t mean you'll trust what it says.
+
+✅ Signing is a Baseline, Not a Guarantee
+
+Think of signing as the "tamper-evident seal". Useful, but only meaningful if the package was accurate, complete, and fresh when sealed.
+
+🤔 The takeaway?
+
+Signed SBOMs are better than unsigned ones. But we need complete, current, and verifiable SBOMs, ideally linked to build systems and verified by trusted parties.
+
+💬👇 Would love to hear: 
+
+❓ How are you validating SBOM accuracy and provenance today?
+
+❓ Does signing increase your trust?
+
+❓ What else would increase your trust?
+
+#SBOM #SoftwareSecurity #SupplyChainSecurity #DigitalSignatures #SecureDevelopment #DevSecOps #ApplicationSecurity #SoftwareIntegrity #CyberSecurity

marketing/content/blog/2025-06-15-sbom-signing-myths.md

@@ -0,0 +1,65 @@
++++
+author = "Jason Smith"
+title = "🚨 SBOM Signing: The Myths That Are Putting You at Risk 🔥"
+date = "2025-06-15"
+linkedin = "https://www.linkedin.com/posts/j28smith_sbom-softwaresecurity-supplychainsecurity-activity-7344065612274376704-7laa/"
+image = "img/thirdparty/2025-06-15-sbom-signing-myths.jpeg"
++++
+
+"If the SBOM exists, that's enough"
+
+"We'll deal with signing later"
+
+"Too complex to be worth it"
+
+"We only need it for external releases"
+
+"Open source doesn't need this"
+
+👀 I've heard these all before. And they're not just wrong, but they're dangerous to believe.
+
+Let's break them down:
+
+❌ Myth #1: "If the SBOM exists, that's enough"
+
+Just generating an SBOM isn't the endgame, it's the beginning.
+
+An unsigned SBOM is an unauthenticated claim. Without signing, you're just hoping no one tampers with it.
+
+❌ Myth #2: "We'll deal with signing later"
+
+Delaying SBOM signing is like building a house and skipping the locks.
+
+You might be safe for a while... until you're not.
+
+❌ Myth #3: "Too complex to be worth it"
+
+Key management, CI integration, and identity binding can be tricky but these are solvable problems.
+
+If you're already sharing SBOMs for software transparency without integrity protections, complexity isn't your problem. You're prioritizing convenience over trust.
+
+❌ Myth #4: "We only need it for external releases"
+
+Insider threats. Supply chain drift. Misconfigured pipelines.
+
+If you're not protecting internal artifacts, you're assuming your own house is clean. The riskiest threats aren't always outside, sometimes they come from within.
+
+❌ Myth #5: "Open source doesn't need this"
+
+Open source doesn't mean risk-free. Unsigned SBOMs leave the door wide open for supply chain attacks.
+
+Signing puts a lock on that door.
+
+💥 The truth?
+
+If you're not signing your SBOMs, you're shipping unsigned claims about your software supply chain.
+
+That's like selling a product with no warranty and claiming it's guaranteed.
+
+🧠 It's time to treat SBOMs like first-class security artifacts.
+
+And that means securing them by default.
+
+💬👇 How do you handle SBOM signing today? What friction points have you hit - or solved?
+
+#SBOM #SoftwareSecurity #SupplyChainSecurity #SBOMSigning #DigitalSignatures #PKI #OpenSourceSecurity #DevSecOps #CyberSecurity #SoftwareTransparency