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.
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.
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].
What is Technical Debt? Technical debt is a popular term within the software industry. First coined by well-known programmer Ward Cunningham, technical debt is a metaphor that explains the long-term burden developers and software teams incur when taking shortcuts.
ThoughtWorks’ Martin Fowler sums up the point well:
“Doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.
One of my talks at RSA 2014 tried to convince attendees that they shouldn’t fear root on mobile. The talk, while lightly attended, seemed well received. Max Eddy of PCMag did a nice write up on it entitled Phones Can’t Be Trusted, Security Needs Root in Mobile.
Abbreviated “history” of root access It’s funny if you think about the history of privilege on computer systems (this is a broad generalization of computer history).