Shellfish, SBOMs, and Firmware: A Security Tale You Won’t Forget

If your vulnerability scanner only sees source code and package manifests, you're shipping IoT products with blinders on.

The Problem Nobody Wants to Admit

Most traditional vulnerability scanners weren’t built for the complex, chaotic world of IoT. They’re optimized for conventional enterprise environments — think clean, well-structured applications, container stacks, web services. But IoT? That’s a whole different animal.

We’re talking about stripped-down firmware, hand-rolled binaries, kernel-level modifications, and a patchwork of third-party code with questionable provenance. In short: it’s messy.

Yet many scanners cling to source code and package manifests as their primary source of truth. Helpful? To a degree. But complete? Not even close. The uncomfortable truth is this: if a component isn’t declared in the manifest, it effectively doesn’t exist, at least from your scanner’s point of view.

The Clam Juice Analogy (Yes, Really)

Imagine you’re allergic to shellfish. You order a pasta dish, ask the server if it’s safe, and they check the recipe card — no shellfish listed. You dig in and boom. Surprise! The chef added a splash of clam juice for flavor. It wasn’t in the official ingredients but in the food.

Now swap pasta for firmware. That clam juice? It’s the statically linked binary blob from a third-party supplier. It is not in your SBOM or manifest, but absolutely part of your device. That’s the gap. That’s the risk.

{{cta('190840854344')}}

What Your Scanner Isn’t Telling You

• Compiled Binaries: Your scanner probably doesn’t analyze them at all. If it does, it might bail if symbols are stripped.
• Statically Linked Code: If it’s baked into a binary, it’s invisible to manifest-based tools.
• Third-Party Blobs: You’re using someone else’s binary driver? Cool. But what did they bake in?
• Runtime Differences: What you wrote in source is not always what runs on the device. Optimization, compile flags, and linker scripts all alter the final output.

The Real-World Impact

• Undetected CVEs: Vulnerabilities hidden in compiled code never make it to the report.
• Compliance Failures: Regulations like the CRA demand deeper visibility. Incomplete scans mean incomplete SBOMs.
• Supply Chain Risk: You can’t secure what you can’t see, and what you can’t see might be where your attackers strike first.

What You Can Do

1. Don’t stop at source code. Scan your compiled binaries.
2. Analyze what’s actually on the device. Not what you think is there.
3. Ask more from your tools. If they can't handle stripped binaries or static links, they're not IoT-ready.
4. Push for accurate SBOMs. Especially for third-party code and binaries. Bonus points if they show exploited vulnerability reachability.

Final Word

If your scanner only looks at source code and manifests, it’s missing critical parts of the picture.

But this isn’t just a visibility issue; it’s a security and compliance problem. Modern standards and regulations expect deeper insight (read as accuracy) into what’s actually running on the device, not just what was planned during development.

To secure IoT, you need tooling that analyzes the final product: the binaries, the firmware, the real build, not just the ingredients list.

Next up: We’ll look at how binary analysis works in practice, and how to extract real insights from the parts your scanner probably isn’t even looking at.