Enterprise Linux security programs have become considerably more mature over the past decade. Package vulnerability scanning, CVE management, configuration hardening, FIPS-validated cryptographic components, and supply chain documentation through SBOMs have all become standard capabilities in organizations running hardened Linux infrastructure. Security teams monitoring their Rocky Linux, RHEL, or equivalent deployments can identify kernel vulnerabilities, package-level CVEs, and configuration drift with tooling that has reached genuine operational maturity.
What that tooling does not reach is the layer beneath the operating system. Firmware, boot components, baseboard management controllers, and vendor-supplied binaries that operate below the OS stack are invisible to package scanning tools that work from software manifests and source code. Vulnerabilities in those components, including vulnerabilities that have been present and exploitable for years without appearing in any CVE feed because no source code analysis discovered them, sit outside the security perimeter that most enterprise Linux security programs can actually observe.
The most dangerous threats often live in the blind spots security teams cannot see. While sub-OS vulnerabilities create hidden infrastructure risk, attackers are also exploiting invisible identity gaps through credential abuse, deepfake impersonation, and AI-powered social engineering. Consltek’s Deepfake to Breach: SMB Playbook for Identity Attacks helps organizations uncover and defend against the trust-layer threats traditional controls often miss.
The CIQ and Binarly partnership directly addresses that sub-OS visibility gap by pairing CIQ’s commercially supported, hardened Enterprise Linux platform with Binarly’s binary-level analysis and firmware vulnerability detection capability. The combination creates what neither vendor can provide independently: a continuous security assurance path from firmware and boot components through the operating system that covers the full infrastructure stack rather than the portion that source-code-dependent scanning tools can reach.
Why Binary Analysis Without Source Code Changes the Vulnerability Discovery Equation
Binarly’s Transparency Platform performs deep binary analysis without requiring source code, and that architectural detail is more significant than it might initially appear to security teams accustomed to source-code-dependent scanning approaches.
Source-code-based vulnerability analysis works well for software where the source code is available, accurately reflects what was compiled into the binary running in production, and has been analyzed by researchers who submitted their findings to CVE databases. For open-source Linux packages, that coverage is reasonable. For firmware, BMC software, UEFI implementations, and vendor-supplied binary components, source code is frequently unavailable, proprietary, or simply not part of the vulnerability research pipeline that feeds CVE databases.
The consequence is that firmware and binary component vulnerabilities can persist in production infrastructure for years, sometimes decades, without appearing in any vulnerability management tool that an enterprise security team is monitoring. The Binarly research that produced the LogoFAIL disclosure in 2023, finding vulnerabilities in UEFI firmware image parsers across a significant proportion of enterprise hardware that had existed undetected for over a decade, illustrates precisely this phenomenon. The vulnerabilities were real, exploitable, and present across enterprise infrastructure globally. They were simply invisible to every security tool that depended on source code analysis or CVE coverage.
Binary analysis that can identify vulnerabilities directly from compiled code and firmware images, without source code access or prior CVE coverage, closes that discovery gap. It reaches the vulnerability population that exists in the infrastructure beneath the OS and that no other tooling class can surface.
Firmware and BMC Security as an Enterprise Risk Priority
Baseboard management controllers and firmware components occupy a specific position in enterprise infrastructure security that gives vulnerabilities in those components disproportionate severity relative to their typical visibility in security programs.
BMCs provide out-of-band management access to servers, enabling remote power control, console access, hardware monitoring, and firmware update capabilities independent of the operating system state. A compromised BMC can maintain persistent access to a server even after the operating system is reimaged, because the BMC operates on a separate processor with its own firmware and network interface that OS-level remediation does not touch. Vulnerabilities in BMC firmware that allow unauthorized access or firmware manipulation represent a persistence mechanism that can survive any remediation action taken at the OS layer.
UEFI and BIOS firmware components that execute during the boot process before the operating system loads represent a similarly privileged attack surface. Malware that can persist in boot firmware survives OS reinstallation and is invisible to security tools that begin monitoring after the OS has loaded. The Secure Boot mechanism that protects against boot-level compromise depends on the integrity of the firmware implementation that enforces it, which means vulnerabilities in UEFI firmware can undermine Secure Boot’s protection guarantees even when Secure Boot is correctly configured.
For enterprise security programs that have invested in OS hardening, FIPS compliance, and runtime security monitoring, the unaddressed firmware and BMC attack surface represents a foundational assumption gap. The hardened OS sits on top of a firmware layer whose security has not been assessed, whose vulnerability state is unknown, and whose compromise would potentially survive any remediation action taken at the OS layer.
The Supply Chain Documentation Gap That the Partnership Closes
The partnership’s contribution to SBOM generation and supply chain documentation deserves specific attention from enterprise security and compliance teams navigating the expanding regulatory requirements around software supply chain transparency.
CIQ’s contribution of OS-level compliance evidence and FIPS 140-3 validated components through RLC Pro provides the operating system layer of supply chain documentation. That layer covers the packages, libraries, and OS components that source-code-based SBOM generation can reach and that compliance frameworks referencing FIPS standards require evidence for.
Binarly’s contribution of binary and firmware analysis, SBOM generation, and full dependency mapping including transitive dependencies extends that supply chain documentation below the OS layer to the components that existing SBOM tooling cannot reach. Firmware components and vendor-supplied binaries that are present in enterprise infrastructure but absent from OS-layer SBOMs represent a supply chain documentation gap that regulators examining software bill of materials completeness will increasingly identify as inadequate.
Executive Order 14028 on Improving the Nation’s Cybersecurity established SBOM requirements that have been interpreted to cover software components in their entirety, not just the application code layer. CISA’s guidance on SBOM practices addresses the completeness requirement directly. An organization that produces an SBOM covering its application software and OS packages while omitting firmware and binary components from its supply chain documentation is producing a materially incomplete compliance artifact that may not satisfy regulatory examination requirements as SBOM scrutiny increases.
The combination of CIQ’s OS-level SBOM and Binarly’s firmware and binary analysis produces a supply chain documentation package that spans the full infrastructure stack, giving auditors and regulators the complete evidence they need to assess supply chain diligence rather than requiring them to accept an OS-layer-only representation as comprehensive.
Remediation Structure as the Operational Differentiator
Both CEO Gwen Castro’s observation that the partnership turns visibility into action and CIQ President Bjorn Hovland’s emphasis on moving from finding to fix in production reflect the operational reality that visibility without remediation structure has limited security value.
Firmware vulnerability discovery creates a specific remediation challenge that distinguishes it from OS-level vulnerability remediation. OS package vulnerabilities can typically be remediated through the package management system that the security team already operates: identify the affected package, apply the vendor patch through the standard update mechanism, and verify the remediation through a subsequent scan. The remediation pathway is defined, familiar, and integrated into existing security operations.
Firmware and binary vulnerability remediation has no equivalent standardized pathway in most enterprise security programs. Firmware updates require coordination with hardware vendors, validation against specific hardware models and configurations, testing in non-production environments that mirror production hardware, and execution through firmware update mechanisms that differ from OS update processes. Binary component vulnerabilities in vendor-supplied software may require vendor engagement timelines that extend significantly beyond what OS patch management expects.
The structured remediation guidance that Binarly’s platform provides, prioritized by actionable context rather than raw severity scores, gives security teams the information needed to assess remediation complexity and plan remediation execution within the enterprise support model that CIQ provides. That combination converts a vulnerability finding from an unstructured research output requiring security engineers to independently develop remediation approaches into a structured remediation workflow aligned with how production infrastructure teams actually execute changes in enterprise environments.
Rocky Linux and the Enterprise Linux Ecosystem Context
CIQ’s founding commercial sponsor role for Rocky Linux provides specific context for why the Binarly partnership matters to the enterprise Linux ecosystem beyond the general firmware security argument.
Rocky Linux was established as a downstream rebuild of Red Hat Enterprise Linux following CentOS’s transition to CentOS Stream, providing the stable, enterprise-grade Linux distribution that organizations running production workloads on CentOS had depended on. CIQ’s commercial sponsorship and enterprise support model for Rocky Linux serves the organizations that need the stability and long-term support characteristics of RHEL-compatible Linux without the direct RHEL commercial relationship.
The Binarly partnership extends the security assurance available to Rocky Linux enterprise deployments below the OS layer for the first time, providing firmware and binary security capability that was previously unavailable within the Rocky Linux commercial support ecosystem. Organizations running Rocky Linux in regulated environments, critical infrastructure, or other contexts where supply chain documentation completeness is a regulatory requirement now have access to firmware and binary security assurance through their existing Rocky Linux commercial support relationship rather than requiring a separate vendor engagement for sub-OS security.
The FIPS 140-3 validated components in RLC Pro combined with Binarly’s binary analysis create a compliance-grade infrastructure assurance package that is specifically relevant for government contractors, defense industrial base organizations, and regulated industry deployments that need both OS-level FIPS validation and supply chain completeness documentation below the OS layer.
What This Partnership Signals for Enterprise Infrastructure Security Program Maturity
The CIQ and Binarly partnership is a market signal that enterprise infrastructure security programs are beginning to address the firmware and binary vulnerability layer that has been acknowledged as a risk for years without producing adequate enterprise-scale solutions for systematic detection and remediation.
The Binarly research team’s prior work, including the LogoFAIL UEFI vulnerability research, the PixieFail network boot vulnerability disclosure, and extensive BMC security research, has established the firm’s technical credibility in the sub-OS security domain at a level that enterprise security teams can evaluate against documented research output rather than vendor claims alone. The partnership with CIQ translates that research capability into a commercially supported, enterprise-deployable offering rather than a research service requiring security engineering expertise to operationalize.
For enterprise security leaders building infrastructure security programs that address the full stack from application code through OS to firmware and hardware, the CIQ and Binarly partnership provides one of the first commercially structured pathways to sub-OS security assurance for enterprise Linux environments. The integration milestones planned across the CIQ product portfolio will determine how completely the partnership delivers on the full-stack assurance promise, but the architectural foundation and the research capability it draws on provide a credible basis for enterprise evaluation.
Organizations managing Enterprise Linux infrastructure in regulated industries, defense and intelligence supply chains, critical infrastructure operations, and any environment where supply chain documentation completeness is subject to regulatory examination should be evaluating the CIQ and Binarly partnership as a material advancement in the infrastructure security assurance capability available for their platform of choice.
Research and Intelligence Sources: CIQ
To participate in our interviews, please write to our CyberTech Media Room at info@intentamplify.com
