OWASP Firmware Security Testing Methodology (FSTM), explained

FSTM's own note on sequencing: "Consider visiting the OWASP Internet of Things Project page and GitHub repository for the latest methodology updates and forthcoming project releases," signalling the document is actively maintained rather than frozen at its 2019 release — the current text adds static-analysis tooling (Cppcheck, Flawfinder, Clang-Tidy, CodeQL, Semgrep) and a Software Bill of Materials section referencing CISA's minimum SBOM elements, both absent from the original release.

Stage 2 lists acquisition methods in roughly increasing order of difficulty: directly from the manufacturer or vendor support site; via man-in-the-middle capture of an update; through exposed cloud storage (with an explicit caveat to "follow local laws and regulations when downloading data from exposed cloud provider storage services"); from hardware debug interfaces such as UART or JTAG; or, as a last resort, by desoldering the flash chip. FSTM recommends requesting both debug and release builds "to maximize testing coverage... in the event debug code or functionality is compiled within a release." Stage 4 then carves the extracted image's filesystem with binwalk -ev, falling back to manual offset carving with dd when binwalk's signature database does not recognize the filesystem's magic bytes — the methodology walks through squashfs, cpio, jffs2 and ubifs extraction commands as worked examples.

Stage 5 directs testers to search extracted filesystem contents for "legacy insecure network daemons such as telnetd... hardcoded credentials (usernames, passwords, API keys, SSH keys, and backdoor variants)... hardcoded API endpoints... [and] startup scripts for remote code execution," using tools such as firmwalker for pattern-based scanning and FACT or EMBA for automated component identification, CVE correlation and binary-mitigation detection (NX, DEP, ASLR, stack canaries, RELRO). From Stage 6 onward the testing shifts from static inspection to a running target: Stage 7's dynamic analysis covers embedded web-application testing (default credentials, directory traversal, injection in diagnostic pages), bootloader tampering (interrupting boot to reach a U-Boot shell, modifying bootargs to add init=/bin/sh), and firmware-integrity testing (uploading a custom image to check signature verification); Stage 8's runtime analysis attaches a debugger to the emulated or live binary to set breakpoints on functions like memcpy and strcmp and fuzz for overflows.

Stage 9 is explicit that exploit development is a distinct skill from vulnerability discovery: "Developing exploit code requires programming experience in lower level languages (e.g. ASM, C/C++, shellcode, etc.) as well as background within the particular target architecture," and names return-oriented programming as the technique needed when NX/DEP/ASLR protections — uncommon in embedded systems, per FSTM's own observation, but not absent — block a straightforward shellcode injection.

FSTM is deliberately scoped to the firmware image alone. The methodology states its complementary documents cover the rest of a device's attack surface: the OWASP IoT Security Testing Guide (ISTG) "provides additional test cases for hardware interfaces, wireless protocols, network services, and user interfaces," while the OWASP IoT Security Verification Standard (ISVS) "defines WHAT security controls must be implemented, while FSTM defines HOW to test firmware components." OWASP's own recommendation is to use the three together — ISVS as the requirements checklist, ISTG for the device's broader surface, FSTM for the firmware binary — rather than treating any one as sufficient on its own. OWASP also maintains IoTGoat, a deliberately vulnerable firmware image used in FSTM's own worked examples, as practice material for applying the methodology end to end.

FSTM is a testing methodology, not a regulatory control — no regulation known to us names FSTM itself as a required step, so any claim that completing an FSTM-style assessment alone satisfies the EU Cyber Resilience Act, RED/EN 18031 or similar regimes should be treated as to be confirmed rather than assumed. Where it is directly useful is as a structured way to generate the kind of technical evidence — hardcoded-credential findings, confirmed memory-corruption or command-injection vulnerabilities, exploitability proof — that a vulnerability-handling process or secure-development lifecycle narrative does need to produce. A firmware SBOM answers what components are inside an image; an FSTM-style assessment answers whether those components, and the glue code around them, are actually exploitable.

This guide summarises the public OWASP FSTM documentation (CC BY-SA 4.0); it does not constitute legal or compliance advice.