Software Supply Chain Attacks: Understanding the Risks and Protecting Your Business (Vendor or User)

In simple words, Software Supply Chain is a more conclusive term for a birds-eye view on the software development lifecycle. The stages of the cycle may vary following different standards and frameworks, but the general idea is that any code that is being developed for a software, or an application goes through different stages. It usually starts with gathering requirements that mandate a design direction, then those working on the software start their design implementation process where the code is written and compiled. After that comes the testing stage to make sure that everything is running as expected. Next comes the deployment phase where most of the problems start to occur once the system starts getting distributed, and finally the maintenance stage, where any broken function or bugs are found get fixed and enhanced.

It looks straight-forward and possibly trouble-free. Yet, cybercriminals have been following a malicious act of targeting software companies, sometimes before they even publish their online-facing touchpoints or before the deployment phase. Such attacks, known as software supply chain attacks, target those working on applications that can converge a high number of data transactions, whether this application will be used internally by a large organization, or online by public users like a mobile or a web application.

Threats that target the developing end: (Software/Application developer or vendor)

Whether you’re with or against the hypothesis, Software supply-chain victims are held liable for compromises initiated on their applications. While we do empathize with the developers in such a case. We still believe that diligence and security practices must be strictly followed when coming up with a new product for the market. And when the time comes for an unfortunate event, a compromised client will not have the capacity to tolerate a vendor for overlooking a code-level vulnerability.

Here are the most common vendor-side vulnerabilities:

1. Input validation errors: These occur when software does not properly validate user input, which can allow malicious actors to inject code or manipulate data in text or input fields.

2. Authentication and authorization flaws: These occur when software does not properly authenticate and authorize users, which can allow unauthorized access to sensitive data and systems.

3. Buffer overflow errors: These occur when software does not properly manage memory allocation, which can allow malicious actors to execute arbitrary code.

4. Cross-site scripting (XSS) attacks: These occur when software does not properly sanitize user input, which can allow malicious actors to execute scripts on other users' browsers.

5. SQL injection attacks: These occur when software does not properly validate user input, which can allow malicious actors to execute SQL commands on a database.

The software I developed runs offline, am I still vulnerable?

It is true that some software still runs completely offline or has no internet-facing application. Yet, this doesn’t eliminate the attack surface. Internal users of such systems still access online resources and download e-mail attachments which could be part of a social engineering attack and still pose as a threat to the running system. Naturally, when a software in internet-facing, the attack surface becomes wider, and the security measures need to become more robust. MHE usually refers to the OWASP top 10 list that is periodically published to guide software engineers and security professionals to the highest-priority vulnerabilities. The latest version of the list and more information about the most common threats could be found here.

I am a third-party software user, but I have a firewall, does this make me secured against SSC Attacks?

Yes and no, for one thing, a firewall has limited visibility over the threats going in your system. It is true that gateway security does protect your network, but if you look at all the layers, multiple solutions are required to have a more solid cybersecurity posture. Having a firewall that allows in/outbound connection to/from a third-party software leaves you vulnerable to compromises vectoring such software. In this case, you allow the connection (that is necessary for your team to operate) and you cannot enforce a policy that denies said connection. Some malwares are too quiet to be detected by firewalls and require deeper level monitoring to be detected and neutralized.

But I only use licensed software, with constant patching and security updates.

This still doesn’t make you 100% secure in the case of the attack we’re discussing now. And this is the main issue with Software Supply Chain attacks. Building up on the previous firewall policy example, if you allow a connection to Software A, that has recently fallen victim to an SSC-Attack and the attack is cascaded to the software users through a patch or an alleged security update, a user would deploy the update unknowingly. With this deployment, the cybercriminal or attacker gains access not only to the software developer (server side) but also to the client (user-side) which is why empathy for the developers could be understood, but the liability cannot be cleared.

Case study: SolarWinds Orion "Sunburst" attack ...

In 2020, FireEye, a well-known cybersecurity company discovered a rather sophisticated attack that compromised many sensitive organizations including US-government agencies. To the date of writing this blog post, the scope of Sunburst attack vectoring Orion is still being discovered. The level of sophistication for this attack suggests that it was backed by a state-agency (The Russian SVR) but this piece of information is still not confirmed.

SolarWinds markets a Network Management and Monitoring software to many organizations including Fortune 500 companies. The attackers inserted malicious code into the updates of SolarWinds’ software that allowed them to gain backdoor access to SolarWinds’ clients’ networks. The attack was discovered by FireEye (one of the compromised organizations as well) in 2020, yet the initial attack date and the scope of the attack are still unknown. This attack was particularly impactful in the software industry and has led to higher scrutiny of the software supply chain and showed the necessity of following a secure framework during the SDLC to ensure a more secure product offering to end users and pushed the limits in reactive security solutions to some rather impressive AI-driven solutions for third-party users.

How can I develop my software or application securely?

To ensure a basic security posture, organizations should implement a few uncompromising security practices. These include: