You Trust the Software. But Can You Trust Its Components? | Co.Next
Uncovering Hidden Risks in the Software Supply Chain
Co.Next × Black Duck | NT 2026, Portorož
Figure 1. Campaign visual.
| Modern organizations rely on far more software than they develop themselves. Commercial applications, open-source libraries, containers, firmware, embedded systems and supplier-provided binaries are now part of almost every technology environment. The challenge is no longer simply whether we trust a software vendor. It is whether we can independently understand and verify the components inside the software we actually receive and deploy. |
Application security programs have traditionally focused on source code: static analysis, developer testing, secure coding and CI/CD controls. Those practices remain essential, but they cover only one part of the real software estate. Organizations also consume compiled applications, appliances, firmware, container images and other artifacts for which the source code may never be available.
That creates a practical blind spot. A vulnerability in a third-party component does not become less relevant simply because the component arrived inside a commercial binary. The same is true for outdated libraries, unsupported versions and license obligations. If the component is part of the software you run, its risk becomes part of your risk.
The software bill of materials (SBOM) has become one of the most useful mechanisms for improving software supply-chain transparency. It can provide a structured list of components, versions and relationships and gives security, procurement and compliance teams a common basis for discussion.
But an SBOM also raises an important operational question: how do you verify that the list accurately represents the artifact that was delivered? Software can change during packaging, components can be embedded in compiled files, and a supplier-provided SBOM may have been produced at a different stage of the build process. The objective is not to distrust the SBOM; it is to strengthen assurance by comparing declarations with the software itself.
Binary analysis provides that additional layer of visibility. Instead of relying only on source repositories or build manifests, the analysis starts with the compiled artifact: an executable, library, firmware image, container or packaged application. It examines what is actually present and identifies software components that can then be assessed for known vulnerabilities, versions and licensing risk.
Black Duck Binary Analysis (BDBA) is designed for precisely this scenario. It extends software composition analysis to artifacts where source code is unavailable, making it relevant to commercial software, supplier deliverables, embedded systems, IoT and OT environments, firmware and container images.
For organizations using Black Duck Polaris for cloud-based application security, BDBA adds an important perspective: Polaris helps address the software you build and test, while binary analysis helps provide visibility into software you receive, package or deploy. Together they support a broader software supply-chain security strategy.
Consider a simple supplier scenario. A vendor delivers a business-critical application together with an SBOM. The organization can accept the declaration and use it for vulnerability monitoring. A more mature process can also analyze the delivered binary and compare the discovered composition with the supplied information.
The value is not limited to finding an unexpected critical vulnerability. Verification can reveal additional components, obsolete versions, licensing obligations or differences introduced later in the build and packaging process. It gives procurement and security teams evidence about the artifact that will actually enter production.
This distinction is especially important for organizations that operate industrial systems, network appliances, embedded devices or regulated products. In those environments, third-party software can remain deployed for years, source code may be unavailable, and the ability to understand the contents of a firmware image or executable can materially improve vulnerability response.
The market is evolving in the same direction. Gartner’s 2026 Magic Quadrant for Software Supply Chain Security positions software supply-chain security as a distinct category. In the attached Magic Quadrant graphic, dated “As of May 2026,” Black Duck is positioned in the Leaders quadrant.
That is significant because the conversation is moving beyond individual SAST or SCA features. Organizations increasingly need a coordinated approach to third-party dependencies, software provenance, SBOM management, artifact verification, vulnerability intelligence and the controls that connect development, procurement and operations.
Trust remains essential to every supplier relationship, but trust and verification are not opposites. Verification creates evidence. It helps answer a very practical question: does the software we received contain what we believe it contains, and do we understand the risks of those components?
At NTK 2026 in Portorož, Co.Next will explore this challenge through practical examples of binary analysis and software supply-chain visibility. We will look beyond source-code scanning and discuss how organizations can examine binaries, firmware and containers, validate component information and move from assumed trust toward measurable assurance.
You trust the software. But can you trust its components? The first step is knowing what is actually inside.
Figure 2. Gartner® Magic Quadrant™ for Software Supply Chain Security, as of May 2026. Black Duck is shown in the Leaders quadrant. Graphic supplied by the sponsor.
| Join Co.Next at NT 2026 in Portorož and see how binary analysis can help uncover what is really inside the software you receive. |
