Skip to content

Firmware analysis

Uploading the shipped binary lets alloy-it derive an inventory from what actually went out the door, rather than from a document describing what was meant to. Where a vendor SBOM also exists, the two are compared.

Firmware is never analysed automatically

Completing an upload does not open the file. A derived SBOM is created only when you explicitly click Generate SBOM from firmware. Scheduled rescans re-query vulnerability data against inventories that already exist; they never re-extract a binary.

This is deliberate. Customer firmware is sensitive, and opening it should be a decision someone made, not a side effect of an upload finishing.

Multi-binary releases

A release can hold several binaries: a bootloader, a kernel, a root filesystem, an application, a full image, a bundle. Each is tagged with its role and analysed independently, producing its own derived SBOM. Release-level views show the union.

This matters for scoping: "the vulnerability is in the bootloader, not the application" is a triage answer, and it needs the binaries to have been kept apart.

What to expect by format

Detection runs on upload: classification only, the file is not opened. Extraction quality is what decides whether a derived SBOM is meaningful, and the interface tells you what to expect before you analyse rather than after.

Format Extraction Expected derived SBOM
SquashFS (hsqs/sqsh) sasquatch Good: package metadata usually intact
ext2/3/4 e2fsprogs (debugfs) Good
UBI / UBIFS ubireader_extract_files Good
JFFS2 jefferson Good
cramfs, EROFS, ISO9660 7z / fsck.erofs Good
Android sparse / boot images simg2img Good once the filesystem is reached
U-Boot uImage, FIT unblob Depends on the payload inside
Archives (tar, gzip, xz, zstd, lz4, zip, 7z, cpio) native tools Good: covers what the archive holds
.deb / .ipk / .rpm ar / 7z Package contents only, not a full firmware inventory
ELF, PE, Mach-O scanned directly Sparse: a single binary rarely carries package metadata
Intel HEX, Motorola S-record n/a Empty: bare-metal images have no package database
Raw / high-entropy not possible Empty: flagged likely_encrypted; decrypt first

Bare-metal and MCU images

If you ship Intel HEX, S-record, or raw Cortex-M images, a derived SBOM will be empty or nearly so. There is no package manager in the image to read, and no amount of extraction will invent one.

The working path is a vendor SBOM from your build system (Zephyr west spdx, Yocto SPDX) attached to the same release. Where the optional deep-analysis profile is deployed, these images still gain value through hardening and version-string findings.

→ Uploading SBOMs

Encrypted images

Detected by entropy and flagged likely_encrypted before analysis. Nothing can be derived until the image is decrypted.

Compare: trust but verify

When a release carries both a vendor SBOM and a derived inventory, the Compare tab shows a read-only diff. Neither side overwrites the other, and both stay under monitoring.

Treat differences as triage input rather than as errors:

  • A component in the binary but absent from the vendor document is the finding you most want before an authority finds it for you.
  • A component in the document but not the binary may be a build-time dependency that never shipped, worth recording as a triage justification.

The Unified inventory view merges the two for reading, with source badges and findings deduplicated. That merge is presentation and counting only; the stored inventories stay separate.

Match-rate caveats

Vulnerability matching depends on component identity, and embedded root filesystems are the hard case:

  • Components carrying a PURL match well.
  • Components the scanner can only name, common in embedded rootfs, match by name and an ecosystem guess. Both false negatives and mismatches are possible.

The vendor ↔ derived compare exists partly to make that gap visible. Triage is where the gap gets closed, with a human decision and a written justification.

Extraction is best-effort

When extraction fails or finds no clear root filesystem, the analyzer falls back to scanning the raw file and records a warning on the binary, visible in the analysis notes, not buried in an audit log.

Every analysis produces a downloadable report artifact: what was extracted, which tools ran, and any warnings. It lives on the Artifacts tab of the release, and it belongs in an evidence pack.

Deep analysis

Where your deployment enables the optional deep-analysis profile, a Deep analysis action runs an EMBA-class scan: binary hardening counts, kernel configuration findings, and detected version strings, alongside an SBOM that feeds the normal CVE path.

It takes tens of minutes to hours. It is not part of the default stack, and it is most valuable precisely where ordinary extraction is weakest: bare-metal and MCU images.

Next