How Firmware Risks Are Exposed Through SBOM Mapping, Exploitability Checks, and Smarter AI-Powered Defenses

We interacted with Michael Scott, Co-Founder & CTO of NetRise, who walked us through how defenders can unpack firmware images, build accurate SBOMs, and map real exploitability. Scott has served on the front lines of cybersecurity, from leading incident response and endpoint detection at Cylance to counter-infiltration and cyber warfare operations with the U.S. Marine Corps.

He explains the role of automation and AI in triage, the value of build-time checks, and why reverse engineering is essential for verifying vendor claims.

Firmware has become one of the most critical yet overlooked layers in enterprise security. Software supply chain attacks are dominating the headlines, and attackers are targeting the code that runs below operating systems. 

This is where persistence can outlast reboots and evade traditional tools. 

Vishwa: Can you walk us through, step by step, how firmware analysis works on your platform? What are hardcoded credentials in firmware, and what does detecting those credentials actually mean in practice?

Michael: The workflow starts the same way every time: take whatever the team has—full image, delta/patch, or a single compiled binary—and carve it open with iterative, recursive extraction. Match on known structures, peel apart volumes, file systems, and inner archives, and keep drilling until there’s nothing left to unpack. 

Signature depth matters because the long tail of “weird” formats is real; thin signatures fail on the exact assets people need analyzed.

Not all firmware looks alike. RTOS payloads often sit close to bare metal and give you fewer traditional clues; embedded Linux tends to look like a tiny distro where os/service configs and package hints help a lot. If what you ingest is a patch, layer it over a known base so downstream analysis sees the actual runtime state. Track that layering in the data model so provenance and diffs stay intact.

Once extracted, index and fingerprint everything, identify components down to version (build a real SBOM, not a guess), and analyze binaries across architectures for memory‑safety issues, injection paths, missing mitigations, and insecure configurations. 

Map findings to CVEs/CWEs so systemic weaknesses can be tracked across products. Use function‑level similarity/diffing to confirm difficult-to-identify components or when symbols are stripped.

Hardcoded credentials are exactly what they sound like—passwords, API tokens, or private keys baked into code or configuration. Detecting them isn’t just “found a string.” It’s where it lives, what consumes it (web admin, SSH, update agent), and whether that path is reachable in a real deployment. That context is what turns a red flag into a prioritized fix.

Finish by overlaying exploitability (is the vulnerable code executed? reachable? privileged?) and current pressure (what’s actively exploited; what’s likely to be next). The output is something an analyst can act on: SBOM, known and newly discovered issues with reachability, secrets, misconfigurations, and clean hand‑offs into tickets and monitoring.

Vishwa: What dashboard-level insights can defenders gain by mapping firmware Software Bill of Materials (SBOMs)? What does prioritization by exploitability look like in raw data form? And what does a high-risk vendor alert look like to a Security Operations Center (SOC) analyst staring at the screen?

Michael: You can’t fix or respond to what you can’t see. Firmware analysis is similar to network security in that you start by knowing your footprint and what’s running where. The same applies to firmware analysis. 

If you don’t understand the devices and the software inside them, everything else is guesswork. A useful view gives you the basics first—what’s there, where it came from, how old it is, and who touches it—then layers on risk, runtime filtering, and what to do next.

A mature platform provides the following to defenders:

• Composition and provenance: The components, their versions, suppliers, and licenses; when they were last updated; who maintains them.
• Authorship context: Signals about contributor health or prior compromises so you can spot projects that deserve extra scrutiny.
• Known and unknown risk: CVEs paired with findings from binary review (tagged to CWEs) so you’re not blind to issues that never made it into a database.
• Runtime information: Whether the vulnerable code actually runs, which services start at boot, what OS configurations there are, and what privileges the exploit would need—and whether those conditions exist in your environment.
• Exposure and blast radius: How many assets, sites, or segments are affected; which ones are configured to be touching the network.
• Threat overlays: Whether the issue is being weaponized now, likely to be soon, and whether it aligns with TTPs you care about.
• VEX and vendor statements: “Present but not affected” gets de‑prioritized—with the rationale captured.
• Fixability: Patch availability, safe config changes, or compensating controls you can deploy today.

Exploitability isn’t one thing; it’s multiple layers that work together:

• Device‑context exploitability: Start with how the device really runs. Which code starts at boot, on login, or on a specific event? What’s the execution context? Can you trace a plausible path—from an entry point like a network service, through the components and config, to a vulnerable line of code—with the required conditions in place (network access, service context, privileges, user interaction, etc.)? When that chain holds on your devices, it moves to the top of the list. If the code is present but never executed, or blocked by privileges you don’t grant, it drops in priority.
• Exploit maturity and threat‑intel exploitability: Then ask: how “real” is the threat outside the lab? Are there reliable, repeatable exploits? Is it being used in the wild? Do high‑likelihood signals and actor TTPs line up with your fleet and exposure? This layer turns a theoretical bug into an operational problem and determines urgency.

When both layers both say “yes”—it runs the way your devices run and the exploit picture is mature—you can cut a list of tens of thousands of issues down to just tens. Everything else gets de‑prioritized with receipts: present but dormant, reachable only with unavailable privileges, or only exploitable with brittle, unproven exploits. That’s how you keep teams focused and mitigations effective.

What a “high‑risk vendor” alert looks like to a SOC analyst:

• High‑risk vendor, to me, blends two buckets: hygiene and supply chain. On hygiene, look at how often code lands without review, how long releases sit or show up as panic hotfixes, how big and tangled the third‑party dependency graph has become, and whether maintainer churn leaves you with operational issues. 
• On the supply‑chain side, flag any sign that a contributor or org is malicious or compromised, and watch for distribution artifacts that don’t cleanly trace back to source—the xz‑utils episode is the poster child, with non‑obvious downstream impact amplified by a packaging layer decoupled from upstream. 

When those signals light up you should understand why this vendor is being flagged, and what to do now: freeze new pulls, pin to known‑good versions, quarantine update channels, map downstream/transitive use via SBOM, diff vendor binaries against upstream and demand signed, traceable provenance, and segment or close ports until patches land. 

The point isn’t to scream “critical”; it’s to give the SOC a clear, actionable reason for the rating and fast pivots, integrations for pulling data into workflows, and a detailed dependency map for understanding impact.

Vishwa: What checks should be automated at build time for firmware security? What do dashboard notifications for SBOM enforcement actually look like? And what does blocking compilation of unverified third-party components mean? What’s the “oh-no” moment when that pops up?

Michael: Build pipelines should enforce:

• Cryptographic integrity everywhere. Verify checksums and signatures for every input and output; publish digests with releases; fail on mismatch (in cases where hashes are deterministic).
• Hardcoded credentials scanning. Check source, configs, and binaries for passwords, tokens, and keys; treat violations as a hard stop.
• Declared vs. resolved drift. Compare what manifests declare to what the resolver actually builds. Fail on unexpected versions, new transitive deps, or substituted sources.
• Config drift tests. Confirm shipped images reflect secure defaults (no insecure services, enforced signed updates, misconfiguration checks, etc).
• SBOM on every build. Emit SPDX/CycloneDX with supplier, version, hashes, license, and dependency paths; fail on missing fields.
• Exploitability gates. If something is actively exploited and reachable—or crosses your likelihood threshold—patch, isolate, or provide a credible “not affected” justification before merging.  Remember – if your tool does not tie code to the OS configuration layer and only looks at code-path based reachability, you have a huge blind spot.

Why provenance and lineage matter:  a trusted maintainer persona pushed a compromised release that spread through transitive dependency resolution. 

The lesson: teams need to ask “who authored this, where did it come from, and what else did it drag in?” 

The same visibility helps legal enforce license policy before a problematic component sneaks into a build.

Regarding the “oh‑no” moment: It doesn’t need to be that dramatic – the build halts because a third‑party package or vulnerability shouldn’t be there, matches a compromised version pulled in transitively, violates license policy, is misaligned from known remediations/fixes, or lands on a restricted‑origin list.  

In the case of enterprise device consumers, you respond appropriately, given the context available by merging your firmware analysis platform data and network/endpoint data, and ultimately push back on the vendor, armed with the facts.

Vishwa: Firmware attacks are notoriously difficult to detect once live. What techniques are adversaries using now? From your reverse engineering perspective, what stands out about modern Internet of Things (IoT) and Operational Technology (OT) exploitation? And what does binary analysis actually reveal about unpatched vulnerabilities?

Michael: Firmware attacks are hard to spot once they’re live because the best ones sit below the OS and outlast normal cleanup; LoJax proved real UEFI‑level persistence in the wild, and BlackLotus showed how a Secure Boot bypass plus slow revocation can let an attacker own the startup path on “fully patched” machines.

Which is why you baseline and verify firmware integrity instead of hoping EDR sees it—exactly the protect/detect/recover mindset NIST lays out for platform firmware.

On the appliance side, attackers work the always‑on services and the update path; the Barracuda ESG incident, with command injection exploited for months, and the vendor ultimately recommending replacement of compromised units,is  a reminder that firmware and its delivery channel are part of the attack surface. 

In OT, purpose‑built toolkits like INCONTROLLER/PIPEDREAM target PLCs and engineering workstations directly, while shared embedded stacks keep creating blast‑radius events—Ripple20 and AMNESIA:33 are classic examples where a buried TCP/IP library bug turns into RCE/DoS across product lines and vendors, with patching slowed by supplier chains and downtime windows. 

From a reverse‑engineering viewpoint, binary analysis gives you proof and context when marketing blurbs don’t. You can confirm: 

• whether the exact vulnerable function still exists (even in stripped builds), 
• whether a patch actually replaced the code path you care about, 
• whether the image is missing hardening or allows unsigned/rollback updates, and
• whether any hardcoded secrets or debug backdoors are tied to reachable services.

It also exposes the very real “undocumented patch” problem—patch diffing routinely surfaces fixes and regressions that never made it into notes, and ecosystem studies have shown vendors sometimes miss or misreport patches—so there’s plenty of low‑hanging fruit without writing the next 0‑day if you simply understand what systems are made of. 

Add in the supply‑chain reality that vendoring and updates can be a wild west—with decoupled distribution and murky lineage, as the xz‑utils backdoor made painfully clear—and the only durable path is reliable, automated reverse engineering backed by a well‑curated ground‑truth dataset; if you want to build the mental model for how attackers bend boot chains and how to reason about them, *Rootkits and Bootkits* remains a great practitioner’s guide.

Vishwa: With CISA directives and the U.S. Executive Order on supply chain security, how do you see regulation shaping firmware analysis adoption? Are boards beginning to demand measurable firmware security metrics, or is this still mostly a CISO-level conversation?

Michael: Zero trust is a compass, not a GPS, at least not in the near term—most supply chains are too heterogeneous to “flip” quickly. In the near term, visibility and provenance are the levers that move risk: SBOM as baseline for every build; VEX so operators know what’s actually exploitable in product; enough automation and depth of analysis to take findings from triage to remediation.

CISOs are already asking for metrics that map to this reality and things are quickly evolving to the board level: SBOM coverage across products; count and MTTR for actively exploited exposure; percent of builds with valid or “acceptable” provenance; percent of fleet with verified firmware integrity. The teams that can do binary‑level identification have an edge—manifests aren’t always present, honest, or complete.

Vishwa: What role do you see AI and automation playing in firmware security? What might identifying vulnerable code patterns without human review look like? And why are humans still needed for advanced contextual decisions?

Michael: On AI and automation: I see AI earning its keep first as ruthless triage—cutting down false positives and bubbling up the handful of issues you actually need to act on. 

The trick isn’t “let the model read everything,” it’s doing deterministic pre‑work so the model only sees the signal: identify components cleanly, check reachability and execution context, validate signatures and provenance, fold in threat intel, then hand AI a reduced set to rank and explain. 

Done right, you upload a container, firmware image, or binary and get back 10–20 items that are not just high risk but immediately actionable—patch here, lock this config, or drop a compensating control at the edge and store the rest away until you need it. 

Humans still matter because edge cases and coupled systems are everywhere in IoT/OT; attackers are creative; and there are business and safety judgments a model shouldn’t make. 

But the arc is obvious: the more reliably you can narrow and enrich the problem set up front—with solid analysis, provenance joins, and live threat context—the more useful and trustworthy the AI becomes, and the less work defenders have to do to land real fixes.

Vishwa: What security tools would you recommend for newcomers securing their devices? And what tools would you recommend for seasoned professionals, beyond the usual, like red-team frameworks, fuzzing toolkits, or firmware analysis platforms?

Michael: Tools worth recommending (beyond fuzzers and red‑team kits)

For Tinkering and learning:

• Binwalk to unpack firmware and see structure/layout.
• Ghidra or IDA Pro to dig into binaries and spot basic mistakes.
• Wireshark to learn the device’s update and cloud protocols; a lot of risk hides in the OTA path.

Enterprise Grade:

• NetRise for depth and breadth, Syft for the easy stuff where accuracy and depth aren’t vital