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
- Don’t stop at source code. Scan your compiled binaries.
- Analyze what’s actually on the device. Not what you think is there.
- Ask more from your tools. If they can't handle stripped binaries or static links, they're not IoT-ready.
- 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.