2021 was an annus horribilis for software supply chain security. Attacks skyrocketed with an increase of 300% compared to the previous year. As a consequence, the U.S. administration issued a Presidential executive order on improving the nation’s cybersecurity, and national agencies started providing recommendations to avoid software supply chain security breaches.
What is a Software Supply Chain Breach?
A software supply chain breach is a cyberattack that aims to hit an organization by targeting a third party instead of the organization itself. Consider the SolarWinds hack as an example. It is arguably the biggest security incident in the 21st century and has impacted most Fortune 500 companies and government agencies worldwide. With access to the main system, bad actors attacked a third-party company to get into the Orion network management system and eventually hit their users.
Similarly, bad actors exploited a series of vulnerabilities in Log4J, a popular Java-based logging utility, instead of directly targeting the company apps on the web. CVE-2021-45046 has been classified as critical since it allows remote code execution; that means attackers could run nasty applications on servers to do illegal activities, like stealing confidential data, IP or even deploying ransomware.
This kind of attack is more cunning than others because third-party organizations and components are not under the control of the main company targeted by cybercriminals. In some instances, this can make them more difficult to protect.
Can a Software Supply Chain Breach Happen in Mobile Apps?
The short answer is yes it can. Quite frankly, developers don’t want to reinvent the wheel every time they work on a new project because the process is tedious and market dynamics push them to release applications at a fast rate. Expediting mobile app time-to-market has led to widely-accepted practices that result in supply chain risks.
A key threat vector for supply chain breaches is the use of third-party libraries. Using these libraries is a widespread best practice in software development across industries as well as mobile.
Additionally, the popularity of open-source code hosting platforms makes it extremely easy for developers to find third-party libraries to integrate with their apps. There are also repositories for mobile apps, like Maven for Android or pub.dev and React native directory for hybrid frameworks like Flutter and React Native.
The use of time-saving third-party libraries can facilitate software supply chain attacks. A poorly maintained open-source library can introduce unwanted and unpredictable vulnerabilities in mobile application code. Additionally, bad actors could voluntarily create malicious pull requests to introduce vulnerabilities in popular libraries. Doing so enables them to exploit those vulnerabilities to complete attacks on a large scale.
Making Mobile Apps More Resilient to Supply Chain Attacks by Shifting Left
The benefits of using third-party libraries in mobile app development are apparent, so it is worth adopting strategies to mitigate the potential security issues they could introduce.
Shifting left is a way to improve the security posture of mobile apps. That means addressing security earlier in the software development life cycle (SDLC). Though mobile application security testing helps achieve that goal, there is a potential barrier to the adoption of such tools: developers don’t usually like dealing with security!
Security is often perceived as a distraction from developers’ programming activity and is often criticized for slowing down the overall development process. Therefore, there is a tendency to overlook security design, which, ironically, could exacerbate the risks of software supply chain breaches.
To overcome such a barrier, it is paramount that mobile application security testing tools used in the earlier stages of the SDLC are developer-friendly. They should be intuitive to use, offering a user experience that is familiar to developers. They should also focus on finding true positives and on providing actionable recommendations to fix them quickly. Doing so would allow developers to save time in security investigations of false issues.
Additionally, mobile app developers should leverage code hardening, like obfuscation and encryption, to protect the integrity of the app from threat actors. This also extends to third-party libraries. For example, a threat actor who reverse engineers your app can do a lot of damage, from stealing proprietary information to inserting malicious code into your app by leveraging third-party libraries. It’s important for developers to not only scan the code from a third-party library before implementing it into the app development process but should also continue to scan that code for any potential new vulnerabilities.
Ultimately, mobile application security testing tools should offer the possibility of automation by integrating them seamlessly into the CI/CD workflow of app publishers.
Mobile application security testing tools that put developers’ interests upfront are very likely to be adopted by engineering teams analyzing application code. At the same time, dependencies earlier in the SDLC can help teams mitigate the risk of software supply chain breaches before releasing the apps in the market.
