What do teams get wrong about SBOMs and signature-based malware tools?

Why This Matters for Security Teams

SBOMs and signature-based malware tools solve important but limited problems. An SBOM improves component visibility, and signatures help block known malicious files, but neither proves that software is safe to run, safe to update, or safe once an attacker changes the context. That gap matters because procurement, build pipelines, and endpoint defenses are often treated as if they are interchangeable forms of assurance. They are not.

Security teams commonly overread an SBOM as evidence of trust and overread detections as evidence of prevention. A build can be fully inventoried and still contain risky transitive dependencies, embedded scripts, or post-install behaviours that never appear in the component list. Likewise, a file can evade signatures simply because it is novel, packed, modified, or delivered as living-off-the-land activity rather than a classic malware sample. NIST guidance on control layering in NIST SP 800-53 Rev 5 Security and Privacy Controls supports the broader principle: inventory and detection are necessary, but they are not sufficient on their own.

In practice, many security teams discover the limits of SBOMs and signatures only after a dependency update, build compromise, or fileless intrusion has already bypassed the assumptions behind both controls.

How It Works in Practice

SBOMs are most useful as a structured input to risk decisions. They help answer what is in the software, where it came from, and which known components may require patching or exclusion. They do not answer whether the software behaves maliciously, whether a dependency was tampered with after cataloguing, or whether an agentic system will misuse credentials at runtime. Signature-based tools, by contrast, match known malicious patterns, hashes, or reputation indicators. They work best against repeatable threats and fail gracefully only when you assume they are one layer in a broader control stack.

Practically, teams should connect SBOMs to verification and response workflows rather than treat them as a checkbox. That means checking source provenance, verifying build integrity, correlating SBOM entries with vulnerability intelligence, and using runtime controls for execution, network, and secrets access. In the endpoint and SOC context, the goal is to combine detection with prevention and containment, not replace one with the other. The CIS Controls v8 align well with this layered approach because they emphasise asset inventory, vulnerability management, and malware defences as distinct capabilities.

• Use SBOMs to identify exposed components, then confirm whether those components are actually reachable in your deployment.
• Require artifact signing, provenance checks, and controlled build paths so inventory cannot be separated from integrity.
• Pair signature tools with behaviour-based detections for suspicious process trees, script execution, and credential access.
• Monitor for post-install actions, outbound connections, and attempts to retrieve secondary payloads.

Where this guidance breaks down is in heavily ephemeral environments such as short-lived containers, serverless functions, and fast-moving CI pipelines, because the runtime changes faster than inventory and signature baselines can be refreshed.

Common Variations and Edge Cases

Tighter inventory and detection controls often increase operational overhead, requiring organisations to balance speed against assurance. That tradeoff is especially visible when teams want SBOM coverage for every release while also expecting malware tooling to catch novel threats automatically.

Best practice is evolving, but there is no universal standard for treating SBOM completeness as proof of safety. A complete SBOM may still miss injected build logic, malicious package maintainers, or dependency confusion that occurs after compilation. Similarly, signature-based malware tools are less effective against bespoke implants, credential theft via scripts, and malware that blends into normal admin activity.

The main edge cases appear where software supply chain risk intersects with identity and automation. For example, an agentic AI workflow may call external tools, load packages dynamically, or request secrets from a vault at runtime. In that environment, the meaningful question is not only whether the component exists, but whether the identity executing it is authorised, observable, and constrained. Teams should therefore validate runtime permissions, secrets access, and network egress alongside build artefacts, not after the fact. Additional guidance on control baselines in NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant here because it separates inventory, monitoring, and response into different control objectives.

The clearest signal of maturity is when teams use SBOMs and signatures as inputs to a broader assurance model rather than as substitutes for runtime detection, provenance, and least-privilege execution.

Related resources from NHI Mgmt Group

• What do teams get wrong about PowerShell-based malware campaigns?
• What do security teams get wrong about archive-based malware delivery?
• What do security teams get wrong about Jupyter-based malware?
• What do security teams get wrong about spreadsheet-based control evidence?