When a commercial airplane crashes, the manufacturer must quickly understand why it happened. Investigators looking for equipment failure must first look at whether the engine was built by General Electric, Pratt and Whitney or Rolls Royce. Once identified, they must evaluate individual engine components for points of failure, right down to the bolts and casings. In the end, these manufacturers often identify problems more quickly thanks to a thorough understanding and exhaustive documentation of all the components.
This same visibility has finally come to software. In May, the White House issued two executive orders on cybersecurity, including provisions requiring more detail by CISA and various federal agencies. Destructive largescale supply-chain attacks in 2020 and 2021 such as SolarWinds, Kaseya and Colonial Pipeline have been a strong catalyst. In each case, hundreds of victims scrambled to understand how a single software application could make so many vulnerable.
One directive of the U.S. executive order requires software sellers to provide federal procurement agents with a software bill of materials (SBOM) for each software application. Similar to the idea of a plane crash, when a disastrous breach occurs software providers and users will now have a production roadmap detailing key components to help victims recover more quickly and to reduce future damage.
Old concept, new application
While the concept of an SBOM has been well-established in manufacturing processes, and not entirely new to software, we consider the federal mandate unique. Unfortunately very few organizations have been exposed to them. Only a limited number of mature organizations have begun to explore SBOM policy and infrastructure as part of a complex security program vetting apps that run critical business processes. For the vast majority of organizations, the SBOM often servers as their first visibility into the software supply chain. Those organizations and agencies will need to quickly learn how to consume and analyze SBOM data as part of a novel process with big implications.
Even more novel are SBOM data and tools for mobile applications. Mobile software often relies on a complex patchwork of operating systems, open-source components, third-party libraries and API connections — all of them changing rapidly as new features are introduced. Many large organizations that already understand the value of the SBOM have nonetheless been unable to produce a working version for mobile applications – until recently.
SBOM and mobile apps
As a mobile AppSec software company with years of experience assessing security for many federal government agencies and large organizations, we have developed a unique mobile SBOM, the first for mobile apps and the first dynamic SBOM. The industry has long believed the way to understand SBOM lies in the source code. There's certainly some truth to that and we recognize that security teams can glean a high fidelity of information from source code, but mobile apps need something more.
Using our approach, customers can see a clearer picture when generating SBOM reports from application binaries, correlated with dynamic testing of connections and data flow. Mobile apps have security risks and a larger attack surface distinct from web apps, such as the way they transmit data, their use of third-party libraries and storage issues.
Dynamic SBOM for compiled mobile apps
We offer both static and dynamic analysis in a mobile SBOM that tests the compiled mobile app binaries. Our team can test the app binary from any public app store or pre-production build provided by development and security teams. Testing this way gives a full view of all the frameworks, first-party and third-party libraries included in the mobile app and uncover transitive dependencies that reveal at runtime but are not found by source code analysis.
Through dynamic testing, we uncover all API calls in the mobile app to see what data gets sent to them. This lets us show how data travels from the app including geolocation data. With this we can tell if an app’s data was sent where intended, or if it’s being sent to a foreign adversary or malicious actor. With a dynamic SBOM, we can inventory network data connections, gaining insight to Transport Layer Security (TLS) tunnels so we know where the app has sent data worldwide, eliminating hands-on testing or audits of every mobile app.
Security champions
We call on mobile DevSecOps teams and security professionals to lead the charge on SBOM adoption and define how security teams will use SBOMs. In reality, it may take a long time for developers to integrate SBOM into their software development lifecycle (SDLC) pipeline. Until then, security teams will have to show value and illustrate ways to consume and act upon data.
Security teams must set the tone for SBOM. SBOMs are simply tools and part of a standardized process. Making them useful will require consumption and analysis tools. For example, we’re working with OWASP-sponsored projects CycloneDX for standardization and component analysis platform Dependency Track for transitive dependencies.
Our SBOM also offers mobile security teams a high-level security assessment of vulnerabilities. This unique feature, with data taken from current testing automation, is something security teams can use to communicate supply chain vulnerabilities with developers and executives.
Mobile SBOM best practices
Here are some general tips for preparing for SBOM requirements:
- Review the executive order and government relationships to understand the impact of the mandate to the organization.
- Review the timeline for implementation and prepare accordingly to ensure compliance.
- Secure a Mobile SBOM solution that’s comprehensive, easily consumed and offers both static and dynamic data.
- Understand commercial and open-source tools for making SBOM data actionable and integrate them into the company’s SBOM process.
- Educate developers on the potential for using SBOM to check for security gaps caused by third-party libraries.
Mobile DevSecOps and security teams should lead the way in embracing SBOMs to reduce the risk of software supply-chain attacks. As part of an overall effort to understand the critical components of software and reduce their risk to an organization, adopting and understanding an SBOM offers a great starting point.
Brian C. Reed, chief mobility officer, NowSecure
