Supply chain attack modelling using MITRE ATT&CK for technical practitioners

Supply chain risk is often discussed in broad terms, but that is not enough when you need to design detections, choose controls, or brief stakeholders on what could actually happen. For technical teams, the useful question is not simply whether a supplier is trusted. It is how a compromise in a supplier, software update path, managed service, or integration could progress through your environment.

That is where MITRE ATT&CK is helpful. ATT&CK gives you a common language for describing adversary behaviour across the attack lifecycle. Used well, it lets you model supply chain compromise as a set of realistic techniques, then connect those techniques to telemetry, detections, and control gaps. Used badly, it becomes a labelling exercise that produces a neat matrix and very little operational value.

This article focuses on a practical approach for UK SMEs. The aim is not to build an enterprise-scale threat intelligence function. It is to create a model that is specific enough to guide action, but light enough for a small team to maintain.

Why supply chain attack modelling is different from general threat modelling

Where supplier, software, and service dependencies change the attack surface

General threat modelling usually starts with your own systems, users, and trust boundaries. Supply chain modelling adds another layer: the systems and people that can influence your environment without being direct employees or internal administrators.

For an SME, that typically includes:

• Software vendors that deliver updates, plugins, or libraries.
• Managed service providers with remote administrative access.
• Cloud and SaaS integrations that exchange tokens, API keys, or webhooks.
• Outsourced developers or support teams with access to repositories and pipelines.
• Hardware, firmware, and device suppliers that affect endpoint or network trust.

The key difference is that compromise may enter through a trusted path. That means your usual perimeter assumptions can fail. A malicious update, a stolen supplier credential, or abuse of an integration token may look legitimate to your tooling until the attacker starts using it in ways that deviate from normal behaviour.

How MITRE ATT&CK helps structure supply chain scenarios without overcomplicating the model

ATT&CK is useful because it describes observable techniques rather than abstract risk statements. Instead of saying “supplier compromise could be bad”, you can model a sequence such as:

• Initial access through a trusted software update channel.
• Execution of a payload on a managed endpoint.
• Persistence through scheduled tasks, services, or cloud app abuse.
• Privilege escalation via stolen credentials or delegated access.
• Lateral movement into identity, endpoint, or cloud control planes.
• Collection and exfiltration of data from business systems.

That structure helps you ask better questions. Which logs would show this? Which controls would interrupt it? Which assumptions are we making about the supplier’s security posture? Which parts of the chain are most likely in our environment?

Define the modelling scope and trust boundaries

Map first-party systems, suppliers, integrations, and update paths

Start with a simple asset and dependency map. You do not need a perfect architecture repository. You need enough detail to understand where trust enters and where it can be abused.

For each service or product, capture:

• Owner and business purpose.
• Supplier or service provider.
• Authentication method, such as SSO, API key, certificate, or local account.
• Update mechanism, such as auto-update, package repository, CI/CD pipeline, or remote support tool.
• Administrative access path, including VPN, bastion host, or privileged SaaS role.
• Data exchanged, especially sensitive or regulated data.

It helps to draw three zones: internal systems, supplier-managed systems, and shared trust paths. The shared trust paths are often where the interesting attack scenarios sit. Examples include a remote management platform, a software build pipeline, a code signing process, or an identity federation relationship.

Identify which assets, identities, and data flows are in scope

Supply chain modelling becomes more useful when you include identities and data flows, not just servers and applications. In many incidents, the attacker is not trying to “break into a server” in the traditional sense. They are trying to abuse a trusted identity or a trusted path.

Include in scope:

• Human identities with privileged access.
• Service accounts and API tokens.
• CI/CD runners and build agents.
• Code repositories and package registries.
• Cloud tenant admin roles.
• Endpoints used by support staff or third parties.

Then map the data flows that matter most. For example, a supplier portal may not hold your crown jewels, but it may provide access to support tickets, reset workflows, or customer records. Those flows often become the attacker’s stepping stones.

Build supply chain attack scenarios from ATT&CK techniques

Technique selection for initial access, execution, persistence, and privilege escalation

Once the scope is clear, choose ATT&CK techniques that reflect the likely progression of a supply chain compromise. Do not try to cover every technique in the framework. Focus on the ones that fit your environment and the supplier relationship.

Useful starting points often include:

• Initial Access: trusted relationship abuse, supply chain compromise, valid accounts, phishing if supplier staff are in scope.
• Execution: command and scripting interpreters, signed binary proxy execution, user execution of malicious update content.
• Persistence: scheduled tasks, services, startup items, cloud application abuse, token persistence.
• Privilege Escalation: valid accounts, token theft, exploitation of exposed management interfaces, abuse of delegated admin rights.
• Credential Access: credential dumping, token theft, key material theft, browser session theft.
• Lateral Movement: remote services, cloud service discovery, internal remote access tools, remote desktop protocols.
• Exfiltration and Impact: archive collected data, exfiltration over web services, data encrypted for impact, service disruption.

The value is in the chain, not the individual technique. A supplier compromise that only reaches a low-value workstation is less important than one that reaches your identity provider, source control, or backup platform.

How to represent software update abuse, credential compromise, and trusted relationship abuse

Three supply chain patterns appear frequently in modelling exercises.

Software update abuse is where a trusted update mechanism is used to deliver malicious code or configuration. Model the path from update signing or distribution to endpoint execution. Ask whether you verify signatures, whether updates are staged, and whether endpoints can report unusual post-update behaviour.

Credential compromise is where attacker access to a supplier account or token is used against your environment. Model how the credential is created, stored, rotated, and monitored. If a supplier has access to your tenant, your remote support platform, or your code repository, treat that identity as a high-value target.

Trusted relationship abuse is where the attacker uses a legitimate integration, remote support channel, or federated trust to move into your environment. This is common in SaaS and managed service scenarios. The model should show what “normal” looks like, what telemetry exists, and which actions should be rare enough to alert on.

For each scenario, write a short narrative in the form: “If the supplier account is compromised, the attacker can do X, which enables Y, which leads to Z.” Keep it concrete. A good scenario is specific enough that an engineer can imagine the logs it would generate.

Use evidence to prioritise realistic scenarios

Inputs from supplier assurance, SBOMs, logs, and incident history

Not every plausible scenario deserves equal attention. Prioritisation should be evidence-led.

Useful inputs include:

• Supplier assurance responses that describe access controls, logging, and incident handling.
• SBOMs, or software bills of materials, which show what components are present in a product or service.
• Identity and access logs showing how supplier accounts are actually used.
• Endpoint and cloud telemetry from systems that receive supplier updates or remote support.
• Past incidents, near misses, and support tickets involving unusual supplier activity.

If you have no evidence for a scenario, treat it as a hypothesis rather than a priority. If you do have evidence, such as repeated remote support sessions from a supplier account outside normal hours, that scenario should move up the list.

For SMEs, a simple scoring model is usually enough. Score each scenario on:

• Likelihood, based on exposure and observed behaviour.
• Impact, based on business process disruption, data sensitivity, and recovery cost.
• Control weakness, based on how many preventive and detective controls are missing or weak.

You can use a 1 to 5 scale, but avoid false precision. The point is to compare scenarios consistently, not to pretend you can calculate exact probabilities.

How to rank scenarios by likelihood, impact, and control weakness

A practical method is to rank scenarios in a workshop and then validate the top few against telemetry and architecture evidence. For example:

1. List the top five supplier-dependent assets.
2. For each one, identify the most credible compromise path.
3. Score the path for likelihood, impact, and control weakness.
4. Review whether existing monitoring would detect the key steps.
5. Decide whether the scenario needs a new control, a better detection, or simply acceptance of residual risk.

This approach avoids over-investing in low-value scenarios. It also helps you explain why one supplier relationship needs more scrutiny than another.

Translate scenarios into detections and controls

Detection engineering ideas for SIEM, EDR, and cloud telemetry

Supply chain modelling is only useful if it changes what you monitor. Each scenario should produce at least one detection idea and one control idea.

Examples of useful telemetry include:

• SIEM alerts for unusual administrative actions by supplier accounts.
• EDR detections for new services, scheduled tasks, or unsigned binaries after a software update.
• Cloud audit logs for changes to federation settings, API permissions, or privileged roles.
• Repository logs for unusual branch protection changes, token creation, or CI/CD pipeline edits.
• Network telemetry for unexpected outbound connections after update installation or remote support sessions.

Where possible, write detections in behavioural terms rather than static indicators. For example, instead of alerting only on a known bad hash, alert on a supplier-managed endpoint that installs a new service and then makes outbound connections to a rare destination within a short window.

If you use Sigma, KQL, or another query language, keep the rule tied to the ATT&CK technique and the business context. That makes it easier to maintain when the supplier tool changes but the behaviour remains suspicious.

Control mapping to identity, endpoint, network, and change management safeguards

Controls should interrupt the scenario at more than one point. For supply chain risk, the most effective safeguards are often boring but reliable.

Common control themes include:

• Identity: phishing-resistant MFA for privileged access, just-in-time privilege, conditional access, separate admin accounts, and tight control of service principals.
• Endpoint: application control, tamper protection, least privilege, and restrictions on local admin rights.
• Network: segmentation, egress filtering, and restricted management paths for supplier access.
• Change management: staged rollouts, code signing validation, approval gates for pipeline changes, and rollback plans for updates.
• Monitoring: centralised logging, alerting on rare administrative actions, and review of supplier access patterns.

For SMEs, the best control is often the one that reduces both attack likelihood and operational ambiguity. For example, if a supplier needs remote support, route it through a controlled access platform with session logging rather than allowing direct, persistent access to production systems.

Operationalise the model in a small team

Lightweight workshop format, ownership, and review cadence

You do not need a large programme to keep this useful. A lightweight quarterly workshop is often enough.

A practical format is:

• 30 minutes to review changes in suppliers, integrations, and privileged access.
• 30 minutes to update the top scenarios and their ATT&CK mappings.
• 30 minutes to review detections, incidents, and gaps.
• 15 minutes to assign actions and owners.

Keep ownership clear. One person should own the model, but the inputs should come from security, infrastructure, application, procurement, and service owners. If the model sits only with the security team, it will drift away from reality.

Document the model in a format that is easy to update. A spreadsheet, wiki page, or GRC record can work if it captures the essentials: scenario, ATT&CK techniques, evidence, controls, detections, owner, and review date.

How to keep the model current as suppliers, products, and integrations change

Supply chain risk changes quickly when suppliers change tooling, merge with another company, alter support arrangements, or introduce new integrations. Build review triggers into your process.

Update the model when:

• A new supplier gets privileged access.
• A product starts auto-updating from a new repository or channel.
• A SaaS integration gains broader permissions.
• A managed service changes its support model or access method.
• You detect a supplier-related incident or near miss.

It is also worth linking the model to procurement and change management. If a new supplier is being onboarded, ask what trust path they need, what telemetry you will receive, and what happens if the relationship ends.

Common modelling mistakes and how to avoid them

Treating all suppliers as equal risk

Not every supplier deserves the same level of scrutiny. A payroll portal and a remote administration provider are not equivalent. Prioritise based on access, privilege, data sensitivity, and blast radius. A low-risk supplier with no privileged access should not consume the same effort as a provider that can alter production systems.

Focusing on compliance artefacts instead of attack paths

Questionnaires, policies, and certificates have value, but they do not tell you how an attacker would move through your environment. If your model stops at “supplier has MFA” or “supplier completed a questionnaire”, it is incomplete. Keep asking: what would the attacker do next, what would we see, and what would stop them?

That is the real strength of ATT&CK in supply chain modelling. It turns a vague concern into a sequence of testable assumptions. For a small team, that is usually the difference between a document that sits on a shelf and a model that improves detection and resilience.

If you want to take this further, start with one high-value supplier relationship and one realistic compromise path. Model it end to end, map the ATT&CK techniques, and then check whether your current logs and controls would actually support detection and response. That single exercise often reveals more value than a broad but shallow review of every supplier.

For UK SMEs, the goal is not perfect coverage. It is proportionate coverage of the supplier paths that matter most to the business.

Speak to a consultant if you want help turning supplier dependencies into a practical threat model, or if you need support aligning the model with an ISO 27001-aligned ISMS, control set, or monitoring roadmap.

Frequently asked questions

How do I start modelling a supply chain attack using MITRE ATT&CK?

Start with a simple map of your own systems, suppliers, integrations, and update paths. Then identify where trust enters your environment, such as remote support tools, software updates, API keys, or delegated admin access. From there, choose a small set of ATT&CK techniques that reflect how a compromise could realistically progress in your setting.

What should I include in scope for supply chain attack modelling?

It is usually worth including identities, not just systems. That means privileged users, service accounts, API tokens, CI/CD runners, build agents, cloud admin roles, and any endpoints used by suppliers or support staff. Data flows matter too, especially where support portals, reset workflows, or repositories could be used as stepping stones.

Which ATT&CK techniques are most useful for supply chain scenarios?

The article highlights techniques across initial access, execution, persistence, privilege escalation, credential access, lateral movement, collection, and exfiltration. In practice, the most relevant ones are often trusted relationship abuse, valid accounts, token theft, scheduled tasks, services, and cloud application abuse. The right choice depends on how your suppliers connect to your environment.

Why are trust boundaries so important in supply chain modelling?

Supply chain compromise often enters through a path that looks legitimate to your tools, such as a signed update, a supplier credential, or an integration token. That means your normal perimeter assumptions may not hold. Drawing clear trust boundaries helps you see where a trusted path could be abused and where detection or control gaps may exist.

How does ATT&CK help with detections and controls for supplier risk?

ATT&CK gives you a common language for linking a scenario to observable behaviour. Once you have a likely sequence of techniques, you can ask which logs would show it, which controls might interrupt it, and where your assumptions are weakest. That makes the model more useful than a general risk statement, because it points towards practical detection and control work.