A Software Bill of Materials (SBOM) catalogs all libraries, dependencies and transitive dependencies present in an application. This critical piece of the development and security puzzle allows development and security teams to identify outdated, unlicensed or untrusted first-party and third-party libraries that require updates or removal.
Mobile app development and security teams can use SBOMs to deliver secure mobile apps faster. Developers commonly rely on third-party and open-source libraries to build mobile apps and teams need an easy, scalable way to recognize the dependencies their applications have. SBOMs do exactly this, and when formatted in industry-standard formats like CycloneDX or SPDX, they are machine readable, writable and can be translated into other formats quickly and easily to use within your systems and workflows.
Teams can use mobile SBOMs in four key ways:
- Comply with the White House Cybersecurity Executive Order (EO) to produce an SBOM for all software purchased and used by the federal government.
- Gain visibility into the components used by a mobile application, including hard-to-find transitive dependencies.
- Aid identification of third-party libraries for completion of Google Play Data safety declarations.
- Integrate directly into dev tools such as GitHub Dependabot as part of shift left strategy.
Interest in SBOMs surged following the mandates of the White House Cybersecurity Executive Order 14028, “Improving the Nation’s Cybersecurity.” The EO stipulated that U.S. government agencies that create applications, and any business that sells applications to the government, must produce a SBOM to be considered for future purchases and use, and failure to do so would result in the removal of the noncompliant software. Mobile applications were included in these requirements. The EO kickstarted the conversation around SBOMs and spurred government action. NIST published new Security Measures, OMB issued four Memos (M-21-30, M-21-31, M-22-01, and M-22-09), and Congress updated the Federal Information Security Modernization Act (FISMA). These initiatives demonstrate the U.S. government’s desire to improve the security of all applications, including mobile applications, produced by and used by its agencies.
The application security testing industry has reacted quickly to strengthen security and generate SBOM information to guard against supply-chain attacks like SolarWinds and Log4j. The Open Web Application Security Project (OWASP) introduced a lightweight standard design for SBOM data meant to simplify consuming dependency data called OWASP CycloneDX.
Other mobile application security standards such as the new Google Play Data safety section and the App Defense Alliance (ADA) Mobile Application Security Assessment (MASA) require identification of third-party dependency risk. The Google Play Data safety section requires the identification of third-party libraries or SDKs in the app that collect or share data. The new ADA MASA requirements are based on the OWASP Mobile Application Security Verification Standard (MASVS) and require “All third-party components used by the mobile app, such as libraries and frameworks, are identified, and checked for known vulnerabilities.”
Benefits of Using Mobile Software Bill of Materials (SBOM)
In addition to complying with the cybersecurity EO, SBOMs provide helpful visibility. By analyzing the version of each first-party and third-party library found and comparing it to the most current published version, developers can identify out-of-date libraries that need to be updated. This same information gives development and security teams insight into libraries that were meant to be retired or removed from the application but remain in the code as a dependency or transitive dependency. Transitive dependencies are particularly difficult to identify and remove manually or with statically generated SBOMs because of their nested nature. Dynamically generated SBOMs provide enhanced visibility into the dependencies of dependencies to make it easier to identify those that must be removed. Libraries that are unlicensed or restrictive can also be identified in this way because most SBOMs include the relevant license information by component.
SBOM data also enables developers to accurately complete the new required Google Play Data safety section. Before uploading a new app or updating one in Play Console, developers must complete the new Google Play Data safety section outlining how their mobile apps collect, handle and secure user data.
They can also obtain an optional Independent Security Review from an ADA Authorized Lab to certify the mobile apps meet industry wide standards for security and privacy. This information will be shown in the Play Store listing to inform users about the mobile app’s privacy and security practices. The Data safety requirements also apply to the data collected and handled through any third-party libraries or SDKs included in the mobile app. A developer can combine the list of libraries provided in a SBOM with information from the SDK providers’ published data safety section or the Google Play SDK Index to check for a link for guidance.
To complete the Data safety form in the Play Console, developers must comply with the requirements and the User Data policy. The requirement includes disclosing the libraries and SDKs that collect any data from the user’s device and any libraries or SDKs that share data collected with a third party. This also applies to APIs that an app uses.
New app submissions and app updates that are non-compliant have received warnings beginning July 20, 2022, and as of August 22, 2022 all new apps and app updates will require a completed Data safety form. The app will no longer be published if the Data safety section is incomplete. If there are any outstanding discrepancies in the information provided, users will see an error message in the listing that says “No information available” and developers will have to work to resolve those issues.
The data provided from SBOMs can be a critical piece to quickly, easily, and accurately completing the Data safety form in the Play Console.
Integrating SBOM Data Into Dev Tools
Integrating security into the software development lifecycle is a cornerstone of DevSecOps. Integrating dependency information into the tools dev teams are using greatly eases finding libraries devs are using that may not be approved. Populating a GitHub Dependency graph with the information from an SBOM enables developers to quickly recognize dependencies using out-of-date versions and update them all in the same tool. Some dependency tracking tools provide Software Composition Analysis that checks the dependencies in an application for known vulnerabilities.
Developers can integrate many SBOM generation tools into the pipeline they use every day with similar methods to integrating security analysis tools. Tools like Jenkins and CI/CD tools like GitHub enable SBOM generation at build time, and results can be fed directly to development or security teams in ticketing systems like Jira. The teams can then analyze the results for outdated or unapproved libraries, and quickly take steps to mitigate or remediate risks.
DevSecOps speeds the deployment of secure code as does integrating the data from an SBOM. Shifting dependency identification and tracking left empowers developers to identify anything that needs to be updated or removed earlier in the development process, saving time, headaches and money later.
Using a NowSecure Dynamic SBOM
NowSecure launched the world’s first Dynamic SBOM for Mobile Apps to help development and security teams gain visibility into the critical components of any Android or iOS mobile app to better understand supply-chain risks. This SBOM goes beyond the traditional SBOM produced through manual efforts and source-code analysis by running both static and dynamic analysis of the compiled mobile app binary on real iOS and Android devices. The SBOM includes rich detail about native and third-party libraries and frameworks identified as direct or transitive dependencies, API endpoints, data transmission location, and a summary of vulnerability information, all available in PDF or CycloneDX format.
A NowSecure SBOM provides immediate visibility into the libraries and frameworks included in the mobile app, enables the discovery of libraries and frameworks that are using older and outdated versions, helps identify components that remain but were previously required to be removed, uncovers component licenses that may violate internal and external policies, and provides information on where data is going, including unapproved APIs and geolocations.
By combining a NowSecure SBOM with the Google Play SDK Index, developers can more accurately provide the information required by the new Google Play Data safety section. NowSecure is also an ADA Authorized Lab that can perform an independent security review for MASA validation. NowSecure also released the NowSecure GitHub Action for Mobile SBOM GitHub Action to dynamically generate an SBOM and populate the GitHub Dependency Graph in Dependabot. This empowers mobile app developers to view their dependency information directly in their GitHub repositories to extend visibility and protect their supply chain.
