SBOM environment
The main goal of EMBA was always to get an accurate real life overview of the threats inside a firmware image that is analyzed. While a few years ago the target audience was only pentesters, in today’s EMBA world also software developers, product owners and product security teams are using her to achieve different goals.
Over the time EMBA is grown and today she is not only a firmware analyzer anymore. Nowadays, EMBA is used to test every little piece of unknown binary. While our main interest stays on analyzing Linux based firmware, we have seen that EMBA is also used for UEFI, Windows binaries, Linux binaries, Scripts, Android APKs and a lot of other stuff. Beside the high fragmentation of the targets under test, we have seen a growing demand for SBOM generation. EMBA includes some kind of basic SBOM support for ages, but as most of our analyzed firmware images do not rely on package managers, we have not seen the demand for supporting them on a broad base - until today.
Now, we have adjusted our approach to support a broad range of package managers, packet types and further sources for getting an accurate SBOM out of every testing candidate.
Beside our binary analysis mechanism as SBOM source EMBA is now able to extract details from the following sources:
- Binaries and libraries (as before via module s09 - excluded from sbom-minimal profile)
- Linux Kernel (via module S24 - could take quite long)
- Linux Kernel (extracted from kernel modules - module s25)
- Kernel modules (via module s25)
- Linux distribution identification (via module s06)
- RPM package management system (via module S08)
- Debian package management system (via module S08)
- OpenWRT Package management system (via module S08)
- Python PIP package management system (via module S08)
- Python requirements files (via module S08)
- RPM packages (via module S08)
- DEB packages (via module S08)
- FreeBSD pkg packages (via module S08)
- Java archives (jar, war - via module S08)
- Alpine APK
- Python poetry
- Python wheel
- Rust (cargo.lock)
- Ruby (gem)
- JavaScript - npm
- Windows binary exif data
- Windows binary extraction and analysis
To start a quick SBOM generation test of a Windows executable the following EMBA command can be used:
# sudo ./emba -f ~/windows_exe_file.exe -l ~/emba_logs_sbom-exe -p ./scan-profiles/quick-sbom.emba
For testing a Linux based firmware image with the new SBOM capabilities and the binary analysis mechanism the following scan-profile can be used:
# sudo ./emba -f ~/firmware.bin -l ~/emba_logs_sbom-firmware -p ./scan-profiles/default-sbom.emba
In general the following scan-profiles should be used:
- To use only the minimal/non-binary SBOM generation mechanisms the quick-sbom.emba scan-profile should be used
- To use the full SBOM capabilities (including binary testing) the default-sbom.emba scan-profile should be used
- To perform a firmware analysis with full SBOM capabilities the default-scan.emba scan-profile should be used
- Sometimes (e.g. you are testing some zip/tgz/.. packed filesystem/sources) it makes sense to disable the deep extraction mechanism. This can be done via
DISABLE_DEEP=0in your scanning profile or with the EMBA parameter-q
In the following section some impressions of the SBOM testing capabilities are shown.
Profile used: sbom-minimal.emba
Profile used: sbom-minimal.emba
Profile used: default-scan.emba
