Supply chain attacks – Threats and protection mechanisms (part 2)

In the first part of Supply chain attacks – Threats and protection mechanisms, we described dependencies on frameworks and libraries. We then presented attack vectors – pathways that attackers can use to gain access to systems – and looked at protective measures. In part 2, we will examine two other aspects of supply chain security:

1. Managed services: Services that are managed and maintained by third-party providers. These include cloud services – both low-level services, such as queuing technologies, and high-level services, such as user authentication and authorization. But managed services can also include services provided by specialist providers, such as payment services.
2. Coding assistants: Services based on large language models (LLMs), which developers use to generate code. This category of tools emerged very recently. It includes tools such as Cursor, Bolt, and GitHub Copilot.
 

Managed services are used everywhere in development and application operations. The idea of using managed services is tempting. You pay for a certain level of functionality, and in exchange, the provider takes care of maintenance, further development, performance, and security.

However, we need to be aware that using managed services means giving up control and influence. Particularly when it comes to security, we place considerable trust in managed service providers. Two recent examples show why decision-makers need to consider security when deciding to buy a managed service. We do not want to criticize the companies mentioned. The incidents merely serve as examples for this article. There have been dozens of successful supply chain attacks on large, small, and specialist companies [1].

In July 2023, Microsoft announced that a group of attackers had obtained a private key that is used to sign data within the Microsoft ecosystem. This key allowed the attackers to generate valid access keys for Outlook Web Access (OWA) and outlook.com. This meant they could access any user account and data on these services [2].

Researchers from the cloud security platform Wiz found that the attackers were able to gain even more access: The attackers used the private key and other vulnerabilities to generate keys for any application that uses a personal Microsoft account for authentication. At least in theory, this meant that the attack also affected SharePoint, Teams, Azure DevOps, and customer applications that allow a Microsoft login [3]. Azure DevOps is particularly critical for supply chains!

Overall, this incident represents a worst-case compromise of the Azure cloud.

Another supply chain attack in July 2023 affected the company JumpCloud. JumpCloud provides a platform for managing access to services and applications. The attackers wanted to gain access to customer systems. To do so, they used a type of targeted phishing attack known as “spear phishing.” This allowed them to gain access to JumpCloud’s internal network. They were then able to inject malicious code into JumpCloud’s commands framework [4]. JumpCloud reported that “fewer than 5 JumpCloud customers were impacted” [5].

One point is worth noting in particular: JumpCloud’s zero-trust approach was unable to stop this attack at any point.

We want to use these two examples to present some learnings and draw some conclusions with regard to security:

1. Choosing a larger managed service provider does not mean greater security. You cannot assume that either large or specialized cloud providers are naturally secure.
2. Using a managed service makes you more vulnerable to attacks: This is because it gives cybercriminals more potential routes to access your systems. If your managed service provider is compromised, you may also have been compromised – at least in theory. These two incidents show how easily attackers can extend their attacks to customers of managed services.
3. Without any doubt, there are good reasons for using managed services, and they certainly have their advantages. As responsible software engineers, it is our job to explain potential security risks to stakeholders and decision-makers. Threat modeling is a particularly useful tool for assessing security risks [6]. Due to space limitations, however, we will not describe this approach in further detail here.
4. Organizations should also consider the issue of provider independence. If they use a service that very few providers offer, it will be difficult to switch to a new provider at short notice, for example for security reasons. In fact, even changing provider in the medium term might be difficult in this scenario. Compliance requirements can further limit the options open to companies here.

Coding assistants can significantly speed up the development of parts of applications or entire applications. As a result, they have attracted enormous attention. Even people with little or no experience in programming are using them. Organizations need to be aware that coding assistants can open up new vulnerabilities to supply chain attacks. Most importantly, organizations need to know how to protect against these attacks.

A coding assistant is basically an interactive client software that runs on a developer’s computer. It communicates with LLMs and suggests commands to be executed. It can even execute these commands independently. This creates a loop between the human developer and the coding assistant. The loop can be extended or customized using Model Context Protocol (MCP) servers and rules files. Both MCP servers and rules are potential bases for supply chain attacks.

MCP servers can handle certain requests without an LLM. Instead, they use their own services to provide answers. This is often more precise or more reliable. Typically, these requests are tasks such as retrieving real-time data or doing arithmetic operations. However, MCP servers are inherently insecure [7]. The developers did not build security into the protocol from the outset. Instead, they treated security as an afterthought, and it is still being handled with a patchwork approach. It is therefore not surprising that we are seeing successful attacks on MCP servers that aim to take control of them [8]. These attacks have even affected MCP servers from well-known manufacturers [9].

If an attacker takes over an MCP server, they can customize the responses that it gives to a coding assistant and insert malicious instructions. Particularly critical: coding assistants usually run with the privileges of the logged-in user — and for developers, this often means admin rights! — and they frequently execute actions such as installing dependencies without critical scrutiny from the developers.

A developer computer with a coding assistant is considered compromised if two things take place: Firstly, the coding assistant receives instructions from a compromised MCP server. And secondly, the developer allows the coding assistant to execute the action without thoroughly reviewing it first.

Rules are system-level instructions that tell coding assistants how to behave. These rules are recorded in so-called rules files. For example, a rule in a rules file may state that a specific development pattern must be followed when creating services. Rules files are an interesting target for attackers. They can inject a rule stating that database queries should be written in a way that makes them vulnerable to SQL injections, for example.

One such attack technique is the “Rules File Backdoor” [10]. With this technique, the attacker inserts hidden Unicode characters into the rules file. These characters contain a malicious message that the attacker wants the coding assistant to receive. Here is an example that would introduce SQL injections:

Attackers can try to manipulate the rules file for a project themselves, for example if it is an open-source project. Alternatively, they can manipulate an online template for rules files and then use social engineering to trick developers into using this malicious template.

Development teams should take a number of steps to make sure they are using coding assistants safely:

1. Developers are the first line of defense. They must pay attention and carefully check the code that coding assistants generate. In particular, they must check the actions to be performed before they are implemented.
2. Before using rules files or parts of rules files, developers must review them very critically.
3. Deciding whether to trust an MCP server must be a conscious choice. What’s more, developers must decide to what extent they will trust it. For example, is it a public MCP server or one that you operate yourself behind a VPN? This makes a big difference. Threat modeling can help you assess the security implications.
4. Privileges should be limited to the minimum necessary. This general principle also applies when operating an MCP server. For developers with admin rights, consider sandboxing. This approach can contain the effects of an attack as far as possible.

The number of supply chain attacks is steadily increasing. Not only that: They are also becoming more and more sophisticated. Companies have a duty to make their software developers aware of these risks. Developers, for their part, are the first line of defense against such attacks. They must be vigilant and detect attacks before they cause damage.

[1] https://www.encryptionconsulting.com/top-10-supply-chain-attacks-that-shook-the-world/
[2] https://msrc.microsoft.com/blog/2023/09/results-of-major-technical-investigations-for-storm-0558-key-acquisition/
[3] https://www.wiz.io/blog/storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr
[4] https://cloud.google.com/blog/topics/threat-intelligence/north-korea-supply-chain/
[5] https://jumpcloud.com/blog/security-update-incident-details
[6] https://martinfowler.com/articles/agile-threat-modelling.html
[7] https://scribe.rip/%EF%B8%8F-the-s-in-mcp-stands-for-security-91407b33ed6b
[8] https://blog.jaisal.dev/articles/mcp
[9] https://thehackernews.com/2025/07/critical-vulnerability-in-anthropics.html
[10] https://www.pillar.security/blog/new-vulnerability-in-github-copilot-and-cursor-how-hackers-can-weaponize-code-agents