A Wake-Up Call for Operators When OWASP first introduced “Using Known Vulnerable Components” back in 2013, it was a developer problem. Fast forward to 2025, and A03:2025 – Software Supply Chain Failures has become an operator’s nightmare. This category, now ranked #3 in the OWASP Top 10 (and #1 in the community survey), reflects how deeply our production environments rely on a sprawling, fragile, and opaque software supply chain. As an operator, I don’t just deploy code — I deploy trust. Every library, base image, CI/CD action, and IDE extension is part of that trust chain. When any one of them fails, it’s not just a bug — it’s a breach. ...

This guide helps software engineers, DevSecOps teams, and open-source maintainers choose and implement the right SBOM (Software Bill of Materials) generator for their projects — based on technology stack, ecosystem, and workflow maturity. General Guidelines When selecting and using SBOM generators, follow these best practices: Choose actively maintained tools: Select SBOM generators that are actively maintained, whether they are ecosystem-built generators or external tools. Prefer Open Source Software (OSS): OSS SBOM generators are improving rapidly and benefit from community contributions and transparency. ...

This blog post describes how OwnersBox quickly mitigated the threat of the “Shai-Hulud” npm supply chain attack in September 2025. The attack involved malicious packages that stole credentials and aggressively self-propagated.

Docket Number: CISA-2025-0007 Comment Deadline: October 3, 2025 Submission Portal: regulations.gov Executive Summary Interlynk appreciates the opportunity to provide feedback on CISA’s proposed “2025 Minimum Elements for a Software Bill of Materials (SBOM).” As developers of open-source SBOM quality and management tools, we bring a unique perspective grounded in practical implementation experience across diverse enterprise environments. Through our work on sbomqs (SBOM Quality Score) and sbomasm (SBOM Assembler), we have analyzed millions of SBOMs from various industries and toolchains, giving us deep insights into the real-world challenges of SBOM creation, validation, and consumption. Our tools help organizations assess SBOM completeness, manage multi-format SBOMs, and ensure compliance with evolving standards—experience that directly informs our response to these proposed minimum elements. ...

Hey SBOM enthusiasts 👋 An SBOM isn’t just a list of components anymore — it has detailed information of your software, which contains hundreds of components. And that’s what gives you the transparency of each and every component: such as, who authored it, who supplies it, under what license it’s released, and even what known vulnerabilities it carries. In other words, it’s not just an inventory — it’s visibility into the very DNA of your software. ...

Hey SBOM enthusiasts 👋, These are common challenges faced by all SBOM authors. How can fields such as “NOASSERTION”, “NONE” be filled at a scale ? This issue is widespread because SBOM generation tools often have gaps and limitation. I do not blame any tool for this; it is beyond their capability, as these tools are primarily design to capture the dependencies of a software. SBOM generation depends on various factors, such as the programming language, the package manager used, the type of SBOM build( source build, build time or post build) and the information provided by the software author on their site. ...

Hey SBOM enthusiasts 👋, we all know by now — SBOMs aren’t optional anymore. They’ve become a standard part of the software supply chain, and there’s a lot you can do with them: augmenting, enriching, editing, validating… the list keeps growing. But here’s the thing — while adding and improving data in SBOMs gets most of the attention, sometimes the real power comes from removing what you don’t need. Maybe it’s for privacy, maybe for cleanup, maybe to keep your SBOM lean before sharing it. ...

Hey SBOM community, Love to see you back here learning something new. If you’re working with SBOMs, you probably know that generating SBOM is just a first step. What you get after generating SBOM is just a raw SBOM ? And the raw SBOM is incomplete, inaccurate sometime and most importantly not even comply with NTIA minimum element according to this research whitepaper. And that’s exactly where your involvement comes to enrich the SBOM, augument the SBOM, etc to make a better quality SBOM with completeness, accuracy and enriched data. At the end the real power of SBOM lies within itself i.e data. Because at the end these SBOM will be feeded to SBOM platform which perform complete analysis of the SBOM. The more complete and correct the data is, the more it helps you understand and reduce risk in your software supply chain. ...

GitHub Release Monitoring: SBOM Automation for External Repos 🚀 If you’ve been following our sbommv blog series, welcome to the fourth one—each post tackling a new challenge around SBOM automation. Here’s a quick recap of what we’ve covered so far: GitHub Release Transfers: How to fetch SBOMs from GitHub release pages and move them to systems like folders, Dependency-Track, Interlynk, or AWS S3. Folder Monitoring: Running sbommv in daemon mode to continuously watch a local folder and upload new SBOMs as they appear. AWS S3 Integration: Adding S3 as both an input and output adapter, enabling SBOM flows to and from S3 buckets. In short, sbommv is a tool built for automation—designed to seamlessly move SBOMs across systems, with support for format conversion, metadata enrichment, and monitoring workflows like folders. ...