How do software supply chain attacks happen?

Most people think of cyber attacks as something that targets a password, a computer, or a website directly. Software supply chain attacks work differently. They involve trusted software, updates, plugins, development tools, code repositories, automation systems or third party services that already have access to important systems.

This guide explains how these attacks happen, why trusted tools can become attractive targets, and what practical controls help reduce the risk.

Supporting visual reference. This image summarises the topic at a high level. The written guide below provides the full explanation and practical guidance.

Use the links below to jump to the section most relevant to your question.

• What is a software supply chain attack?
• Why attackers target trusted tools
• Why developer tools and security tools can be high value targets
• Why API keys, tokens and secrets matter
• How this affects small organisations
• Practical steps to reduce risk
• What this does not mean
• Further reading
• Further Guidance and Support

A software supply chain attack happens when attackers compromise something that other people or organisations trust. Instead of attacking the final target directly, they attack software, updates, plugins, tools, libraries, automation systems or suppliers that already have access.

This could involve a compromised software update, a malicious plugin, a poisoned code library, a tampered developer tool, a browser extension, a build workflow, a supplier account or a third party integration.

The risk comes from trust. If a tool is already allowed to run, update, connect, scan, deploy or access data, a compromise of that tool may give attackers a route that ordinary users and administrators do not immediately suspect.

Trusted tools can be attractive targets because they often sit close to important systems. They may be allowed through security controls, run automatically, access cloud services, connect to websites, read configuration files or interact with administrator accounts.

This is different from a simple malicious email attachment. In a supply chain attack, the tool may already be familiar, approved or widely used. The user may not see anything unusual because the compromise is hidden inside a trusted process.

This is why software supply chain security is not only a developer issue. It also affects websites, cloud accounts, password managers, browser extensions, backup tools, remote access tools, plugins and third party services used by small organisations.

Developer tools and security tools can be especially attractive because they often handle sensitive information. They may scan infrastructure files, run inside build pipelines, access repositories, store configuration data, connect to cloud platforms or hold tokens used by automated systems.

A recent report by The Register described an ongoing supply chain campaign affecting security and developer tools, including Trivy, KICS, Checkmarx related tooling, GitHub Actions, Open VSX plugins and Bitwarden CLI. The report highlighted the risk of attackers gaining access to developer secrets, cloud credentials, SSH keys, Kubernetes configuration files, GitHub tokens, CI secrets, npm publishing access and downstream environments.

The important lesson is not limited to those specific tools. It is that useful tools can become powerful access points if they are compromised, over privileged, or connected to systems without enough review.

Security tools should therefore be treated as powerful tools, not automatically safe tools. Their access should be understood, limited where possible, and reviewed over time.

A password is not the only form of access. Modern systems often use keys, tokens and stored credentials so that services can connect automatically without a person typing a password each time.

Examples include API keys, access tokens, refresh tokens, SSH keys, app passwords, OAuth consent, cloud credentials, CI secrets, backup codes and configuration files.

These items may allow one system to access another system. If they are exposed, copied, stored insecurely or left active after they are no longer needed, they can become a route into cloud services, code repositories, websites, backup platforms or business data.

For small organisations, the practical point is that access should not only be reviewed at user account level. Third party apps, plugins, automation tools and integrations may also hold access that needs to be understood.

A small organisation may not write software or run a development team, but it can still depend on software supply chains. Most organisations use third party platforms and tools every day.

Examples include WordPress themes and plugins, browser extensions, website forms, payment plugins, email marketing integrations, Microsoft 365 apps, Google Workspace apps, backup platforms, remote access tools, security tools, DNS platforms, CDN platforms, accounting integrations and supplier portals.

The risk is not that these tools should be avoided. The risk is that access can accumulate quietly. Old plugins may remain installed. Unused integrations may keep permissions. Supplier accounts may stay active after a project ends. Admin consent may be granted once and never reviewed again.

Good security means knowing which tools are connected, what they can access, whether they are still needed, and who is responsible for reviewing them.

Reducing software supply chain risk starts with understanding which tools and services have access. This includes tools installed on devices, plugins used on websites, apps connected to cloud accounts, and suppliers with administrative or remote access.

Useful steps include:

• Keep an inventory of third party apps, plugins, extensions and integrations.
• Remove unused tools, plugins, browser extensions and connected apps.
• Limit administrator permissions to accounts and tools that genuinely need them.
• Use separate administrator accounts where appropriate.
• Review app consent and third party permissions in Microsoft 365 and Google Workspace.
• Rotate exposed or old API keys, tokens and secrets.
• Avoid storing secrets in plain text files or shared documents.
• Keep WordPress plugins, themes and core software updated.
• Use reputable sources for software, plugins and extensions.
• Review supplier access periodically and remove access that is no longer required.
• Use multi factor authentication for administrator accounts.
• Use logging and alerts where available.
• Maintain backups so that recovery is possible if a trusted system is affected.

These steps reduce risk, but they do not guarantee that a supply chain incident cannot happen. Technology changes, suppliers change, tools are updated, and new vulnerabilities are discovered. Access should therefore be reviewed periodically as part of wider security and resilience planning.

This does not mean open source software is unsafe by default. It does not mean all third party tools should be avoided. It does not mean small organisations need the same processes as large software companies.

It does mean trusted access should be understood, limited and reviewed. A tool that can access email, files, websites, code, cloud accounts or backups should be considered part of the security picture.

The aim is not to reject useful tools. The aim is to avoid unmanaged trust.

The following sources may be useful if you would like to explore the standards, terminology, and real world examples in more detail.

• NCSC: Assessing supply chain security
• NCSC: Preventing lateral movement
• The Register: Ongoing supply chain attack targeting security and developer tools
• CISA: Software supply chain security guidance
• OWASP: Software Component Verification Standard
• OWASP: Top 10 CI CD Security Risks
• GitHub: Secret scanning documentation
• Microsoft: Review permissions granted to enterprise applications
• Microsoft: Configure how users consent to applications

This guide forms part of a broader layered security approach. For structured guidance on security and resilience planning, see our Security and Resilience page.

For information about practical implementation and ongoing support, you can review our IT services and local IT support coverage across London, Hertfordshire, and Essex.

Return to all guides

Author
Elías Sánchez
IT Support Consultant
Evening Computing
London, United Kingdom

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
01 May 2026