Keeping an Eye on Binaries – 360° Security with a Next-Generation SBOM Tool

News about attacks on the software supply chain keeps appearing—and these incidents have long evolved into a serious security risk for organizations. One day, reports surface about malicious code discovered in JavaScript packages on npm The next time, an invisible worm infiltrates Visual Studio extensions. The scenarios vary widely, but these undetected vulnerabilities have one thing in common: they can disrupt business operations, create compliance and liability risks, and ultimately lead not only to financial losses but also to a loss of customer trust.

Even organizations that believe they are well protected because they already use a solution to generate a Software Bill of Materials (SBOM) should keep reading. Not all SBOM tools are created equal.

Why SBOM Matters

Let’s start from the beginning. Whether it’s source code, third-party code, dependencies, toolchains, or open-source libraries—a software supply chain consists of countless components, each with its own lifecycle. This complexity often turns the supply chain into an opaque structure. If organizations lack transparency, attackers may gain access unnoticed.

That is why a Software Bill of Materials (SBOM), which lists all components, libraries, and dependencies, is highly recommended. In some cases, it is even one of the most effective ways to meet requirements introduced by regulations such as NIS2, DORA, or the Cyber Resilience Act (CRA). After all, an SBOM provides transparency into the software components in use, enables secure supply chains, and helps organizations systematically identify risks within their software supply chain.

However, traditional SBOM tools typically generate the bill of materials only during the build process—often based on configuration data rather than the final binaries. This approach can create significant risks.

Four Weaknesses of Traditional SBOM Tools

Organizations that already rely on an SBOM tool—or are currently evaluating solutions—should take a closer look. Four critical aspects must be addressed to achieve effective security:

Incomplete: Traditional SBOM tools that analyze only source code overlook many dependencies that are introduced during the build or compilation process. Embedded or transitive dependencies—such as third-party binaries (for example .jar, .so, or .dll files)—are often not detected. As a result, the generated SBOM does not represent the actual delivered artifact and remains incomplete. And what you cannot see, you cannot control.
Outdated: Software components inevitably age from a security perspective as new vulnerabilities are discovered over time. However, SBOM data represents only a snapshot of a software bill of materials. If additional components are loaded during build or deployment, the SBOM that accompanies the released software may already be outdated.
Overlooked: Not all security risks become visible through source code analysis alone. Many assets remain undetected because no source code exists. For example, static API keys or backend URLs added during the build or deployment process often go unnoticed. Similarly, assets that exist only as binary data during development—such as microcode, firmware, or AI model blobs—are frequently not captured.
Unprioritized: An SBOM simply describes the components contained within a piece of software—much like a bill of materials in manufacturing. Insights into actual security risks emerge only when these components are correlated with vulnerability databases such as CVE. Especially in large projects, this correlation can produce extensive lists of potential findings. Without structured evaluation, critical and exploitable vulnerabilities may get lost among less relevant entries. Risk-based prioritization—taking into account severity, exploitability, real-world exposure, and remediation effort—is therefore essential for implementing effective security measures.

Rethinking the SBOM Tool

Does that sound unsatisfying? It was. For a long time, organizations were unable to guarantee 100 percent security for their software supply chains. This is a challenge we were eager to address. Together with our partnerReversingLabs,, long known for its focus on comprehensive software supply chain security, we developed a new SBOM tool: Application Supply Guard.

Application Supply Guard analyzes software in the state in which it is actually used—in other words, at the level of the final binary. Based on this analysis, it generates a complete Software Bill of Materials that reflects all included components. Each identified component is automatically compared with up-to-date CVE databases to detect known vulnerabilities and risky dependencies.

Designed for Usability

Because SBOM analyses are often difficult to interpret, Application Supply Guard focuses on clear and meaningful reporting. The results are structured in a comprehensive security report—including a detailed vulnerability assessment—providing a solid basis for targeted security measures.

The best part: getting started requires only three simple steps.

Register for Application Supply Guard by providing basic contact information and payment details.
Upload your data—whether a binary file, Docker image, or ZIP archive. Processing is fully encrypted, and all data is permanently deleted after analysis.
Receive both the generated SBOM and the security report.

This enables organizations to identify potential vulnerabilities quickly and address them in a targeted manner.

SBOM Analysis—Done Securely

In complex software ecosystems, reliable and automated SBOM reports are no longer a nice-to-have—they are a necessity for both security and compliance. Application Supply Guard closes the gap left by traditional tools and provides complete transparency into all software components and their associated risks.

Want to analyze your software supply chain? You’re just three steps away.