The Cybersecurity Research Center at Synopsys analyzed the Software Bill of Material (SBOM) for 10 populars Android sports and betting apps and released their findings earlier this month. Not surprisingly, many of the apps contained outdated and vulnerable open source components.
You should take a look at the report as it’s interesting and well written. But I’d like to focus in on two important points that they made.
Exploitable Whenever a developer is presented with evidence of a vulnerable dependency, I suspect on of the first questions that comes to mind is: ok, but is that code used and exploitable?
On Monday, Reuters released an article disclosing “Russian software disguised as American finds its way into U.S. Army, CDC apps”. In it, they share:
Thousands of smartphone applications in Apple and Google’s online stores contain computer code developed by a technology company, Pushwoosh, that presents itself as based in the United States, but is actually Russian, Reuters has found.
The article is a fascinating read, almost from a spy novel, including fake business addresses and even fake LinkedIn profiles of “two Washington, D.
If you’d like to generate an Android SBOM every time you build your app, you can combine previous techniques discussed on this blog to achieve this with GitHub Actions + NowSecure. If you’re not a NowSecure customer, first sign up for 10 free SBOMs so you can follow along in the tutorial.
To brush up on the previous techniques, check out my blog+video on how to generate an Android SBOM in CycloneDX format.
On 25 Oct 2022, OpenSSL began pre-notifying organizations of two critical vulnerabilities in OpenSSL 3.0.x. On the positive side, OpenSSL 3.0 had not been widely deployed and on 1 Nov 2022, the two vulnerabilities were downgraded to a high. However, on the heels of recent highly impactful vulnerabilities like Log4j and the devastating impacts of the OpenSSL “Heartbleed” vulnerability from 2014, defenders went on high alert.
Popular mobile apps with OpenSSL With the recent tutorials I’ve been sharing on Software Bill of Materials, I decided to take a look at 3,845 very popular mobile apps to see if I could determine if an app contained a direct or transient OpenSSL dependency and if so, was that version vulnerable.
Let’s walk through the steps on how to generate a mobile SBOM for an Android app and compare the results from a source code vs. binary analysis.
So that everyone can follow along, I decided to use the excellent open source note-taking app Joplin. The source code is available of GitHub and there are multiple flavors of the app including Android and iOS apps. The project also has a great article on building the Joplin applications which you can follow instead of the below directions if you prefer.
Generating a SBOM can sometimes be very simple and other times a royal pain. For this first SBOM tutorial, I’m going down the very simple path! :-)
Using the open source ios-triage app, the following steps will build a CycloneDX SBOM in json format. As I’m hoping this blog is useful for folks new to security and/or programming, I’m going to provide a step-by-step approach.
Note: these commands were run on macOS but can be easily adapted for Linux or Windows
SBOM generation techniques There are two primary techniques for generating a Software Bill of Materials (SBOM):
Source code analysis Binary analysis Each technique has their owns strengths/weaknesses and an ideal solution would be the combination of the two. This article will provide a brief overview of each techniques, pros and cons and wrap up with a quick tutorial.
Source code analysis As the name implies, source code analysis refers to analyzing the source code of the application.
What is an SBOM Software Bill of Materials (or SBOMs) have been around for over a decade and in their simplest form are a structured list of 3rd party software, components and libraries included directly, or indirectly, in your code.
Why are SBOMs useful SBOMs are useful from a number of use cases/personas:
List all dependencies (developer) Remove unused software (developer) Update stale software (developer) Identify non-compliant software license (developer/product) Remediate dependencies with know vulnerabilities (developer/security/product) SBOM Standards In 2011, the Linux Foundation released the SPDX standard to ease software licensing compliance issues [^1].