Firmware CVE intake: the finding is almost never a zero-day, it is a five-year-old BusyBox

The reason the version-banner pass is worth institutionalising has little to do with cleverness. It needs no cooperation from the vendor. Banners in binaries like busybox, openssl, dropbear, lighttpd and zlib usually survive stripping, because the program prints or logs them at runtime and they are compiled-in constants rather than debug metadata ^[6]. The party with the least leverage in an embedded supply chain, the buyer holding a .bin file and no source tree, can therefore still produce a component inventory. That is a procurement capability wearing a security label.

Where it gets uncomfortable is the direction of the errors. The source names two ways a version match misleads: a vendor can backport a security fix without bumping the version string ^[9], and embedded builds routinely compile out whole code paths, such as a protocol handler that is never enabled, to save flash ^[12]. Both produce a match with nothing behind it. So the characteristic failure of this workflow is over-counting, not under-counting ^[1]. A scanner run on its own yields a hit list, and turning that into a findings list means confirming in the disassembly that the vulnerable path is compiled in and reachable ^[2]. Anyone treating CVE-bin-tool output as a report has skipped the step that makes it defensible ^[8][12].

The cost is not evenly spread across the image. Userspace is close to automated: unpack with binwalk, which scans for magic bytes including SquashFS, CramFS, JFFS2, gzip streams and kernel headers, and whose extraction mode gives you a filesystem tree rather than a blob ^[3]. Then grep the strings, then match against a local mirror of NVD-sourced data ^[8]. Kernel modules and object files break that chain, because they generally carry no human-readable banner ^[10]. What you get instead is vermagic, via modinfo or by reading the .modinfo section with readelf, which pins the kernel version and config the module was built against and narrows which kernel-side CVEs are even in play ^[10]. Past that the fallback is pulling the module into Ghidra or radare2 and comparing exported symbols against a known-vulnerable version of the same driver ^[11]. That is analyst hours per module, and it is where the budget for firmware review actually goes.

Hash-matching binaries against vulnerable-binary databases would be cheaper and mostly does not work, because vendors relink, strip and sometimes patch ^[5]. Which leaves the unglamorous grep as the highest-signal move in the whole sequence, by the author's own account ^[7].

The honest framing here is the author's: none of this is fast, and auditing source you can read is an easier problem ^[13]. But the thing being checked is not whether the device has a novel bug. It is whether the vendor ever patched an old one, and the usual answer is an OpenSSL or BusyBox build from five years ago that nobody was tracking ^[2][1]. That is a question with a bounded cost and a repeatable answer, which is the definition of an intake step rather than a research project.