With the advent of the European Union's
Cyber Resilience Act (CRA), makers of embedded and
Internet of Things devices will need to inspect their firmware before it goes to market, certify that it's safe to use, compile lists of all third-party code sources, and keep consumer products updated through the devices' working lives.
Unfortunately, neither of the two main methods of firmware and software review —
static application security testing (SAST) and software composition analysis (SCA) — is by itself enough to guarantee secure code and CRA
compliance.
Only by combining SAST and SCA scans as part of a largely automated
DevSecOps process can device makers achieve comprehensive results, making certain that the firmware and software in IoT products and other digital hardware is ready for today's tougher regulatory environment.
"We oftentimes come into organizations who haven't historically invested in security, and we can very rapidly bring them up to par," says Matt Wyckhouse, CEO of connected-device firmware security provider Finite State.
Even greater gains come from SAST and SCA scanning tools that can not only read code but decompile binary blobs to offer total insight into firmware composition and potential flaws. The resulting transparency lets organizations avoid
supply-chain vulnerabilities and create the thorough
software bills of material (SBOMs) required by the CRA.
"We can support initial scanning of their code bases with our binary SCA tools and binary SAST tools," Wyckhouse adds. "We can help them get a baseline understanding of their security, and then very rapidly provide remediations for any of the security issues that they might encounter."
The limitations of SCA and SAST
Static application security testing and software composition analysis each have their pros and cons.
SAST looks at the code early in the development process and tries to find problems within. SCA tries to break out all the different components of the code, trace their origins and map out their dependencies, often near the end of the software-development life cycle.
SAST is a form of source-code analysis, which once was a couple of developers manually poring over each line of code but now involves rapid, automated code scans. Any kind of source-code analysis is worthwhile, but it works best on first-party code that's developed by the same organization releasing the product.
If there's any possibility of the software containing third-party or open-source code, as is often the case with IoT and embedded-device firmware, then you'll need to do SCA too. In that way, sources and dependencies that SAST may miss can be identified and accounted for, essential for discovering potential
vulnerabilities as well as licensing issues.
Furthermore, SAST and source-code-analysis tools are often geared toward different programming languages. Compatibility may be an issue, especially when it comes to obscure languages.
"You have to look at software at multiple points in the life cycle, and you have to have really strong compatibility," explains Wyckhouse. "For anything where we have the source code, we're looking at all of the dependencies that are being pulled into those projects. That's pretty straightforward. We then also supplement that with our binary-based SCA."
SCA, in turn, often doesn't grasp the context of analyzed or decompiled code and may make mistaken assumptions about potential vulnerabilities. For that reason, SCA tools are famous for generating a lot of
false positives, making it hard to separate the truly problematic bits of code from the alert noise.
There are many free (and freemium) open-source SCA tools, but they can also be limited in how many vulnerability databases they access and how they integrate with other security tools. That's especially troublesome because SCA tools are key to creating SBOMs.
"For embedded devices, the risk is that you have blind spots because [free SCA tools are] not designed to cover the third-party binaries that are coming in," says Wyckhouse. "They might not be designed to support all the programming languages that you're using. They probably have very limited support for C or C++, a lot of that native code that you find in embedded devices."
"We're big fans of open-source," he adds. "But a lot of companies need something that's more reliable today, and in particular, for anyone that's building a connected device, I think it would be really tough to just rely on open-source."
The best of both worlds
The ideal situation is to use both SAST and SCA during the DevSecOps process, shedding light on your codebase and its sources from two different perspectives. Using either SCA or SAST by themselves will leave gaps, as even the best SCA tool might miss context and even the best SAST tool may overlook open-source or third-party code.
"We have source-code-scanning capabilities that integrate early into the development process," says Wyckhouse, "Whatever the
CI/CD pipeline is that you're using, it gives very instant feedback to engineers so that they can just write secure code by default, make good decisions about the dependencies that they're pulling in."
SAST and SCA tools that can decompile binaries have an added advantage, giving them access to a whole universe of open-source code to analyze and review for vulnerabilities and other issues.
"We've automated that whole decomposition process, where we extract it, we look at all the files, and then for every single file that has executable code in it, we actually disassemble, decompile and extract all of these features," Wyckhouse says. "It does require a lot of work to do binary analysis, a lot of computation, but we've been refining that over many, many years to make that work very well."
Finite State's repository of open-source and third-party components lets it quickly match what it finds in your code to its origin — essential when creating an SBOM for review by EU authorities or outside
auditors.
"We do very accurate, very comprehensive, scanning of code bases and binaries together that lets us get a really good picture," says Wyckhouse. "We know that the software we are analyzing is the software that you're shipping, and nothing else has come in between the time that you generated that SBOM and the time you take it to market."
