Supply chain attack modelling using MITRE ATT&CK

Supply chain risk is often discussed as a supplier problem, but for security teams it is better treated as an attack path problem. The practical question is not simply whether a supplier is trustworthy. It is how a compromise of that supplier, their software, their credentials, or their support channels could be used to reach your environment, your data, or your customers.

That is where MITRE ATT&CK is useful. ATT&CK is a knowledge base of adversary techniques, so it gives you a common language for describing how an attack unfolds. For supply chain scenarios, that means moving beyond a generic list of third parties and into a structured model of initial access, persistence, privilege escalation, lateral movement, and impact. Used well, it helps you connect supplier trust boundaries to control gaps and detection coverage. It also makes it easier to explain risk to stakeholders in terms of business effect rather than abstract concern.

If you already use threat modelling methods such as STRIDE or attack path analysis, ATT&CK does not replace them. It adds operational detail. A data flow diagram shows where trust boundaries exist. ATT&CK helps you ask how an adversary could exploit those boundaries. If you are already mapping detections and controls to ATT&CK, the same technique can be extended to supplier-driven scenarios, which keeps the model consistent across architecture, engineering, and monitoring work. For a broader view of technique mapping, see mapping detections and controls to MITRE ATT&CK.

What MITRE ATT&CK adds to supply chain threat modelling

A supplier register tells you who your dependencies are. A risk questionnaire tells you what they claim to do. ATT&CK helps you model how those dependencies might be abused in practice. That matters because supply chain incidents rarely begin with a dramatic, obvious event. They often start with something that looks legitimate: a signed update, a support session, a remote management tool, a package dependency, a CI/CD token, or a trusted account.

The value of a technique-based model is that it is specific enough to support action. Instead of saying “a supplier compromise could affect us”, you can say “a compromise of the build service could lead to malicious artefact distribution through trusted update channels, followed by execution on endpoints and credential theft”. That level of precision helps you decide which controls matter most, which telemetry you need, and where to focus validation.

ATT&CK also helps with consistency. Different teams often describe the same issue in different ways. Procurement may talk about assurance. Engineering may talk about dependency integrity. SOC analysts may talk about suspicious remote access. ATT&CK gives those teams a shared reference point. That is particularly useful for UK SMEs, where the security function is usually small and people need a model that can be maintained without excessive overhead.

Define the supply chain scope before mapping techniques

Before you map techniques, define what “supply chain” means in your environment. Many teams start too broadly and end up with a model that is too vague to use. A better approach is to separate the dependency types that create different attack surfaces.

Start by identifying the supplier categories that matter most:

• Software suppliers, including SaaS platforms, on-premises products, libraries, and managed services.
• Service suppliers, including outsourced support, MSPs, hosting providers, and maintenance partners.
• Identity dependencies, such as federated sign-in, SSO, delegated admin, and privileged support accounts.
• Build-chain dependencies, including source repositories, CI/CD systems, package registries, signing services, and release pipelines.

For each category, document the trust boundary and the integration point. Ask what the supplier can reach, what credentials they hold, what network paths exist, and what data they can see or modify. A simple table is often enough at first: supplier, dependency type, access path, privileged actions, data exposure, and recovery complexity.

This is also where you should distinguish between direct and indirect dependencies. A direct supplier may be the company you contract with. An indirect dependency may be a package maintainer, cloud sub-processor, or remote support platform they rely on. In practice, indirect dependencies are often where visibility is weakest. If you need a reminder of how third-party software can introduce risk through transitive relationships, it is worth revisiting how third-party software introduces cyber risk for UK SMEs.

For SMEs, the scope should be limited to the dependencies that could realistically affect confidentiality, integrity, availability, or fraud exposure. You do not need to model every vendor relationship in the business. Focus on the suppliers that can change code, move data, administer systems, or interrupt operations.

Map likely adversary objectives across the supply chain

Once the scope is clear, map the attacker’s objectives rather than starting from controls. In supply chain incidents, the adversary usually wants one of four things: trusted access, code execution, credential access, or operational impact. ATT&CK is useful because it lets you describe the technique chain that supports each objective.

For initial access, common patterns include abuse of trusted remote access, compromise of supplier credentials, malicious updates, and exploitation of public-facing supplier services. In ATT&CK terms, you may be looking at techniques associated with valid accounts, phishing, external remote services, or software supply chain compromise. The important point is not to force a perfect taxonomy, but to capture the realistic route into your environment.

After initial access, the attacker’s next goal is usually to expand trust. That can mean persistence through long-lived tokens, service accounts, API keys, or remote management tooling. It can also mean privilege escalation via delegated admin rights, over-permissioned service principals, or build system credentials. In many environments, the supplier compromise itself is not the end state. It is the bridge to your own identity plane, endpoint fleet, or production environment.

From there, lateral movement and collection become the main concern. If the compromised supplier account can reach multiple tenants, multiple environments, or multiple business units, the blast radius can grow quickly. This is why identity and access design matters so much in supply chain modelling. If you need a deeper view of access boundaries, designing least privilege access using IAM and RBAC is a useful companion topic.

Build a practical ATT&CK mapping for common supply chain scenarios

A useful model should be scenario-based. For most UK SMEs, the highest-value scenarios are not exotic. They are the ones that combine trust, reach, and weak visibility.

Scenario one is third-party software compromise. A vendor release pipeline is compromised, a package is tampered with, or a signed update is abused. The attacker’s technique chain may include supply chain compromise, code execution through trusted software, credential access from the endpoint, and then discovery or lateral movement. The key modelling question is which systems trust that software enough to execute it automatically, and which identities or secrets it can reach once installed.

Scenario two is abuse of supplier credentials or support channels. A managed service provider account, remote support tool, or delegated admin role is compromised. The attacker may use valid accounts, remote services, and privilege escalation to move into your environment without triggering the same controls that would stop an external intrusion. This is especially relevant where supplier access is exempt from normal conditional access, device compliance, or session recording requirements.

Scenario three is compromise of build and release infrastructure. A CI/CD system, source control platform, or signing service is targeted. The attacker may attempt to alter build artefacts, inject malicious dependencies, or steal tokens that allow release manipulation. For teams that rely on automated deployment, this is one of the most important areas to model because the compromise can scale rapidly across all customers or all internal environments.

Scenario four is dependency poisoning through packages or libraries. This is not always a direct supplier breach. Sometimes the risk comes from a maintainer account, a typo-squatted package, or a dependency update that introduces malicious code. If your software estate depends on open-source packages, the attack path should include package integrity, provenance, and the trust placed in build-time retrieval.

For teams working on software assurance, it can help to align this modelling with implementing software supply chain assurance controls for technical teams, because the same artefacts that create risk are often the ones you need to verify.

Use ATT&CK to prioritise controls and detections

Once the technique chain is clear, map controls to the points where they break the chain or reduce dwell time. In supply chain scenarios, the most effective controls are usually those that reduce trust, constrain privilege, and improve provenance.

For identity, use strong authentication, conditional access, short-lived tokens, just-in-time privilege, and separate admin accounts for supplier access. Where possible, require supplier access to come through controlled jump points or remote support workflows rather than direct administrative reach. If a supplier needs elevated access, make it time-bound and auditable. Avoid standing access that persists after the support task has finished.

For build and release pipelines, protect signing keys, isolate build runners, pin dependencies where appropriate, and use provenance checks for artefacts. If you can, separate the systems that build code from the systems that approve or deploy it. That reduces the chance that a single compromised account can alter both the artefact and the release decision. Build logs should be retained long enough to support investigation, and release events should be correlated with source control and identity activity.

For software integrity, use code signing, package verification, and dependency controls that are proportionate to the risk of the application. Not every application needs the same level of scrutiny, but anything that can reach sensitive data, payment flows, or privileged internal systems deserves stronger checks.

For detection, think in terms of observable technique indicators. Examples include unusual supplier logins, access from unfamiliar geographies, new remote management sessions, unexpected token creation, changes to build definitions, unsigned or newly signed artefacts, and release activity outside normal change windows. The goal is not to detect every possible supply chain compromise. It is to detect the stages that are most likely to occur in your environment and most likely to matter.

If you are already building detections in a SIEM, ATT&CK can help you structure the coverage. A Sigma rule for suspicious remote access, a Sentinel query for unusual service principal activity, or a correlation rule for build changes followed by privileged deployment can all be mapped back to the same technique chain. That makes it easier to see where you have strong coverage and where you are relying on assumptions.

Model the attack path from supplier compromise to business impact

Technical modelling is only useful if it connects to business impact. For supply chain scenarios, the main impact categories are data exposure, service disruption, fraud, and recovery cost. A supplier compromise may not immediately breach your perimeter, but it can still create material harm if it affects production systems, customer data, or payment operations.

When ranking scenarios, consider three dimensions. First is likelihood, which depends on the supplier’s exposure, the access they hold, and the maturity of their own controls. Second is blast radius, which is the number of systems, users, or customers that could be affected if the supplier path is abused. Third is recovery effort, which includes containment, rebuild, validation, customer communication, and any contractual or operational knock-on effects.

For example, a compromise of a low-privilege SaaS tool used by a single team may be inconvenient but contained. A compromise of a remote support platform with tenant-wide administrative access is a different class of risk. Likewise, a malicious package in a development dependency may be limited if it never reaches production, but much more serious if it is embedded in a release pipeline that deploys automatically.

This is where attack path thinking is valuable. You are not just asking whether a supplier can be compromised. You are asking what the attacker can do next, what they can reach, and how quickly you can detect and contain it. That is a more realistic basis for prioritisation than a simple high, medium, low supplier score.

Operationalise the model in a small security team

For a small team, the model needs to be lightweight enough to maintain. A good starting point is a spreadsheet or simple repository that records each key supplier scenario, the relevant ATT&CK techniques, the controls in place, the telemetry available, and the owner for each gap.

ATT&CK Navigator can be useful for visualising coverage, especially if you want to show which techniques are covered by controls, detections, or both. It is not a substitute for analysis, but it does help make gaps visible. If you maintain detections as code, keep the mapping alongside the rule content so the relationship does not drift over time.

For validation, purple-team style exercises are often the most practical approach. You do not need to emulate a full supply chain compromise. Instead, test the stages that matter most to your model. For example, can you detect unusual supplier access, a change to a build definition, the creation of a new token, or a release from an unexpected identity? If you already use controlled adversary simulation, simulating adversary techniques safely with Atomic Red Team can support this kind of validation work.

Keep the model current. Suppliers change their tooling, you change your architecture, and telemetry coverage evolves. Review the model after major supplier onboarding, access changes, platform migrations, or incidents. A model that is not maintained quickly becomes a historical document rather than an operational tool.

Common mistakes when modelling supply chain attacks

The first common mistake is focusing only on software vendors. Service providers, identity providers, and support partners can be just as important, especially where they hold privileged access or can influence production systems. If you only model product supply chains, you will miss a large part of the real exposure.

The second mistake is treating supplier assurance as the same thing as attack modelling. Questionnaires and due diligence are useful, but they do not show how an attacker would actually move through your environment. ATT&CK helps you bridge that gap by translating supplier trust into concrete technique chains.

The third mistake is overengineering the model. Some teams try to model every supplier, every technique, and every possible outcome. That usually produces a document that is too large to use. Start with the suppliers and systems that can cause the most harm, then expand only where the risk justifies it.

The fourth mistake is failing to connect the model to monitoring and response. If the model does not influence access design, logging, alerting, or incident playbooks, it is unlikely to change outcomes. The point is to improve decision-making, not to produce a neat diagram.

Practical next steps for UK SMEs

If you want to start without overcomplicating it, choose three supplier scenarios that matter most to your business. One should involve software or build-chain trust, one should involve privileged service access, and one should involve identity or remote support. For each scenario, document the likely ATT&CK techniques, the controls that interrupt the chain, and the telemetry that would show you something unusual.

Then ask three practical questions. What would the attacker want next? What would they be able to reach? How would we know? Those questions are usually enough to expose the most important gaps.

From there, prioritise the controls that reduce standing trust, improve provenance, and tighten supplier access. If you already have a SIEM, use it to validate the most important detection points. If you do not, start with the logs that would help you investigate supplier access, build changes, and privileged activity. For a broader operational view of third-party risk, Supply Chain Resilience for UK SMEs is a useful companion read.

If you need help turning the model into a practical programme, or want support aligning it with an ISO 27001-aligned ISMS, a consultant can help you structure the work without making it heavier than it needs to be. The aim is to make supply chain risk visible, measurable, and manageable in the context of your own environment.

For tailored support, speak to a consultant.

Frequently asked questions

How does MITRE ATT&CK help with supply chain risk?

It gives you a structured way to describe how a supplier compromise could unfold, from initial access through to persistence, lateral movement, and impact. That makes it easier to map controls and detections to specific attack paths.

What is the best way to start modelling supplier compromise without overengineering it?

Pick the three supplier scenarios that matter most to your business, define the trust boundaries, map the likely ATT&CK techniques, and identify the controls and logs that would interrupt or reveal the attack. Start small and expand only where the risk justifies it.