Mapping application vulnerabilities to MITRE ATT&CK

For many UK SMEs, vulnerability management still starts and ends with a list of findings. A scanner reports a SQL injection issue, a pen test highlights weak access control, and a bug bounty submission flags a session handling problem. The problem is not usually a lack of findings. It is turning those findings into decisions that engineering, security, and leadership can all act on.

That is where mapping application vulnerabilities to MITRE ATT&CK can help. ATT&CK is not a vulnerability catalogue. It is a model of attacker behaviour, organised into tactics and techniques. Used well, it gives you a common language for describing how a weakness could be used, what the attacker would try next, and where your controls or telemetry might break down.

For technical practitioners, the value is practical. You can connect a weakness in the codebase to an abuse path, then use that context to prioritise remediation, improve detection, and test whether compensating controls actually reduce risk.

Why map application vulnerabilities to ATT&CK

How ATT&CK helps engineering and security teams speak the same language

Engineering teams often think in terms of defects, libraries, endpoints, and release cycles. Security teams often think in terms of attack paths, exposure, and blast radius. ATT&CK sits between those viewpoints. It lets you describe a vulnerability in terms of what an attacker can do with it, rather than only what the scanner called it.

For example, a weak file upload control is not just an input validation issue. Depending on the context, it may support initial access, execution, persistence, or data theft. A broken access control issue may enable privilege escalation, lateral movement within the application, or unauthorised data access. ATT&CK gives you a structured way to express that chain.

Where vulnerability data fits alongside CWE, CVE, and threat modelling

ATT&CK should sit alongside, not replace, existing sources of truth. CWE is useful for naming the underlying weakness class, such as improper authorisation or injection. CVE is useful where a specific product or component has a published vulnerability identifier. Threat modelling helps you reason about trust boundaries, assets, and likely abuse cases before a defect becomes a finding.

A practical workflow is to use CWE to classify the weakness, CVE where applicable to identify the affected component, and ATT&CK to describe the attacker behaviour that the weakness enables. That combination gives you a more complete picture than any one source alone.

What this mapping does and does not tell you

ATT&CK mapping is useful, but it has limits. It does not prove exploitation. It does not tell you whether a vulnerability is exploitable in your environment without context. It does not replace testing, logging, or risk assessment.

What it does give you is a disciplined way to answer questions such as: if this weakness is abused, what technique is the attacker likely to use next, what identity or application controls might stop them, and what telemetry would show the attempt?

Start with the vulnerability source data

Using SAST, DAST, SCA, bug bounty findings, and pen test results

Good mapping starts with clean source data. Most SMEs will have a mix of findings from static application security testing (SAST), dynamic application security testing (DAST), software composition analysis (SCA), manual penetration testing, and occasionally bug bounty or responsible disclosure reports.

Each source has different strengths. SAST is good for code-level weakness patterns. DAST is better at runtime behaviour. SCA highlights dependency and transitive dependency risk. Manual testing often adds the context that automated tools miss, such as authentication state, business logic abuse, or chained exploitation.

Do not try to map every raw tool output directly to ATT&CK. First, normalise the finding into a consistent record that includes the affected asset, the weakness, the evidence, the exposure, and the likely abuse path.

Normalising findings into a common schema

A lightweight schema is usually enough. For each finding, capture:

• Asset or application name
• Environment, such as production, staging, or internal
• Weakness class, ideally mapped to CWE
• Evidence or reproduction notes
• Authentication context, such as unauthenticated, standard user, or privileged user
• Internet exposure or internal-only access
• Potential business impact
• Proposed ATT&CK tactic and technique
• Confidence level

This structure helps avoid the common mistake of treating all findings as equal. A low-risk issue in a non-production environment should not be prioritised the same way as a remotely reachable weakness in a customer-facing API.

Separating weakness, exploit path, and business impact

Keep three ideas distinct. The weakness is the technical flaw. The exploit path is how an attacker would use it. The business impact is what matters to the organisation if the path succeeds.

For example, a missing authorisation check is the weakness. The exploit path may be an attacker changing an object identifier to access another customer record. The business impact could be unauthorised disclosure of personal data, contractual breach, or loss of customer trust. ATT&CK helps describe the exploit path, but you still need the business context to prioritise correctly.

Build a practical mapping method

Map weakness classes to ATT&CK tactics and techniques

Start with the most likely attacker objective, then work backwards. If a weakness allows unauthorised access to an account, the relevant tactic may be Valid Accounts or Privilege Escalation. If it enables code execution on a server, the tactic may be Execution. If it allows data extraction, Collection or Exfiltration may be relevant.

Do not force a one-to-one relationship. A single weakness can support several techniques, and a single technique can be enabled by several weakness classes. The goal is not perfect taxonomy. The goal is useful operational context.

Use CWE as the bridge between findings and ATT&CK

CWE is often the best bridge between vulnerability data and ATT&CK. A finding labelled as CWE-79, for example, tells you the weakness is cross-site scripting. From there, you can assess whether the likely attacker behaviour is session theft, user impersonation, or malicious action in a victim browser session. The ATT&CK mapping should reflect the actual abuse path in your application, not just the weakness label.

Similarly, broken access control findings may map to techniques involving valid account abuse, privilege escalation, or data discovery, depending on the application design. Injection flaws may map to execution or server-side compromise if the application context supports it. The bridge is the abuse path, not the scanner output alone.

Record confidence levels where the mapping is inferred rather than observed

Not every mapping will be equally certain. Some will be directly observed in testing. Others will be inferred from the weakness and deployment context. Record that difference.

A simple confidence scale works well: high when exploitation was demonstrated, medium when the path is plausible and supported by evidence, and low when the mapping is speculative. This matters because ATT&CK can otherwise create false precision. A low-confidence mapping is still useful, but it should not drive the same decisions as a confirmed abuse path.

Common application vulnerability patterns and ATT&CK techniques

Injection flaws, command execution, and server-side compromise

Injection flaws remain one of the clearest examples of where vulnerability data maps to ATT&CK. If an application accepts untrusted input and passes it into a command, query, or interpreter without proper handling, the likely outcome may be execution on the server, access to sensitive data, or compromise of the application runtime.

In ATT&CK terms, the relevant technique will depend on the exact path. A database injection issue may support collection or exfiltration of data. A command injection issue may support execution. A deserialisation flaw may support execution or persistence if the application context allows it. The important point is to map the actual attacker action, not just the weakness class.

Authentication and session weaknesses leading to valid account abuse

Weak passwords, poor session management, missing multi-factor authentication, and token leakage can all lead to valid account abuse. In ATT&CK language, this often aligns with Valid Accounts, Credential Access, or Account Manipulation, depending on the scenario.

For practitioners, the useful question is not only whether the login control is weak, but what the attacker can do once they are in. Can they reset other users’ passwords? Can they access administrative functions? Can they pivot into cloud services or support tooling? Those answers determine whether the issue is a nuisance or a material risk.

Access control failures, data exposure, and privilege escalation paths

Broken object-level authorisation, missing role checks, insecure direct object references, and over-permissive APIs often lead to unauthorised access or privilege escalation. These are common in SaaS platforms and line-of-business applications where business logic is more complex than the underlying framework.

ATT&CK mapping here is often about the next step in the chain. If a standard user can read another user’s records, the technique may be Data from Information Repositories or Collection. If the user can invoke administrative actions, Privilege Escalation or Valid Accounts may be more appropriate. If the application exposes internal metadata or secrets, that may support discovery or credential access.

Prioritise remediation using ATT&CK context

Weighting internet exposure, exploitability, and blast radius

ATT&CK context becomes most valuable when you combine it with exposure and blast radius. A remotely reachable issue in a customer-facing application with a known abuse path should usually outrank a similar weakness in an internal tool with strong network controls and limited data access.

When triaging, consider:

• Is the application internet-facing?
• Does exploitation require authentication?
• Is the affected function high value, such as payments, identity, or admin?
• Can the attacker move from one account to many?
• Would the issue enable follow-on techniques such as credential theft or data exfiltration?

This approach helps avoid overreacting to noisy findings while still giving serious attention to weaknesses that support meaningful attacker behaviour.

Distinguishing high-risk techniques from low-value findings

Some findings look severe on paper but have limited practical impact in your environment. Others appear modest but unlock a larger attack path. ATT&CK helps separate those cases.

For example, a low-severity XSS issue in an isolated admin portal may be less important than a moderate-severity access control flaw in a public API that exposes customer records. The technique mapping, combined with exposure and asset value, gives a better prioritisation signal than severity alone.

Using ATT&CK to support backlog triage and risk acceptance

Once mapped, the finding can be used in backlog planning. Engineering teams can group fixes by root cause, such as input handling, authorisation, or session management. Security teams can see which attacker behaviours are most enabled across the estate. Leadership can make more informed decisions about what to fix now, what to mitigate, and what to accept temporarily.

If a finding is being deferred, the ATT&CK mapping is useful evidence for the risk note. It shows the likely abuse path and the controls that currently reduce it. That makes risk acceptance more explicit and easier to revisit later.

Operationalise the mapping in engineering workflows

Adding ATT&CK tags to Jira, Azure DevOps, or GitHub issues

Do not leave the mapping in a spreadsheet that nobody uses. Add ATT&CK tags to the issue record in Jira, Azure DevOps, or GitHub Issues. A short field such as ATT&CK technique, confidence, and abuse path is usually enough.

That allows teams to search for recurring patterns. If multiple issues map to the same technique, you may have a systemic control gap rather than isolated defects. It also helps product and platform teams see where design changes could remove an entire class of issue.

Feeding mappings into SIEM, SOAR, and vulnerability management dashboards

Where the tooling exists, feed the mapping into your SIEM or vulnerability management dashboard. This is especially useful if you already correlate application logs, identity events, and WAF alerts. A mapped vulnerability can then be linked to relevant detections or response playbooks.

For example, if a weakness could support account abuse, you may want to review alerts for unusual login patterns, password reset activity, token reuse, or administrative actions from new locations. If a weakness could support server-side execution, you may want to check whether endpoint telemetry, container logs, or web server logs would show the abuse.

Linking remediation to secure coding standards and release gates

Mapping is most effective when it feeds back into engineering standards. If repeated findings map to the same ATT&CK technique, update secure coding guidance, code review checklists, or release gates to address the root cause.

For example, if several issues map to account abuse, strengthen authentication requirements, session handling, and privileged action controls. If several map to execution or injection, reinforce input validation, output encoding, and safe API usage. The point is to turn incident patterns into engineering guardrails.

Use the mapping to improve detection and response

Turning application weaknesses into detection hypotheses

Every mapped vulnerability should raise a detection question. If this weakness were exploited, what would we expect to see? Which logs would show it? Which control would stop it? Which alert would tell us the control failed?

This is a useful way to build detection hypotheses. A broken access control issue may justify monitoring for unusual object access patterns. A session weakness may justify monitoring for token reuse or impossible travel. A server-side execution path may justify monitoring for unexpected process creation, outbound connections, or web shell indicators.

Identifying telemetry gaps across logs, WAF, API gateways, and identity systems

ATT&CK mapping often exposes telemetry gaps. You may discover that the application logs the request but not the user identity, or that the identity platform sees the login but the API gateway does not capture the object identifier being accessed. Without that context, it is hard to confirm abuse.

Review telemetry across the stack: application logs, WAF events, API gateway logs, identity provider logs, database audit logs, and endpoint telemetry where relevant. The aim is not to log everything. It is to log the right things to support the abuse paths you care about.

Validating whether compensating controls reduce the attack path

Mapping also helps validate compensating controls. If a vulnerability cannot be fixed immediately, ask whether rate limiting, stronger authorisation checks, WAF rules, network segmentation, or additional monitoring meaningfully reduce the attacker’s options.

Do not assume a control is effective because it exists. Use the ATT&CK mapping to test whether it interrupts the relevant technique. If it does not, it may provide comfort without real risk reduction.

A lightweight workflow for UK SMEs

A simple spreadsheet or ticketing model for smaller teams

Smaller teams do not need a complex GRC platform to start. A spreadsheet or ticketing template can work if it is consistent. The key is to keep the model simple enough that people actually use it.

A practical workflow is:

1. Capture the finding from the scanner, test, or disclosure report.
2. Assign the CWE and affected asset.
3. Describe the likely abuse path in plain English.
4. Map to one or more ATT&CK techniques.
5. Record confidence and exposure.
6. Assign remediation owner and due date.
7. Note any compensating controls or detection gaps.

Minimum fields to capture for each mapped finding

If you want the smallest useful dataset, capture these fields: asset, weakness, CWE, ATT&CK technique, confidence, authentication requirement, internet exposure, business impact, owner, and status. That is enough to support triage and trend analysis without creating unnecessary overhead.

When to move from manual mapping to automation

Manual mapping is fine at low volume. As the number of findings grows, automation becomes worthwhile. You may want to auto-tag common CWE-to-ATT&CK relationships, pre-populate mappings from scanner output, or enrich tickets with asset criticality and exposure data.

Move to automation when manual handling starts to slow remediation, when the same mappings recur often, or when you need reporting across multiple teams. Even then, keep human review for ambiguous cases. ATT&CK mapping is useful precisely because it adds judgement, not just labels.

Common pitfalls and how to avoid them

Overmapping every finding to a technique

Not every issue needs a detailed ATT&CK mapping. A low-impact configuration issue may not justify it. Overmapping creates noise and reduces trust in the process. Focus on findings that materially affect attacker behaviour, exposure, or response planning.

Treating ATT&CK as a vulnerability taxonomy

ATT&CK is about behaviour, not defects. If you use it as a substitute for CWE or CVE, the mapping will become muddled. Keep the layers separate: weakness, exploit path, attacker behaviour, and impact.

Ignoring context such as authentication state, trust boundaries, and deployment model

Context changes everything. The same weakness can have very different implications depending on whether the application is internet-facing, behind single sign-on, containerised, multi-tenant, or handling regulated data. Always include the deployment and trust context in the mapping.

For UK SMEs, the practical value of ATT&CK is not academic precision. It is better prioritisation, clearer engineering conversations, and more relevant detection work. If you can show how a vulnerability supports a realistic attacker technique, you are much better placed to decide what to fix, what to monitor, and what to accept for now.

If you want help turning vulnerability findings into a more structured remediation and detection workflow, speak to a consultant.

Frequently asked questions

Is MITRE ATT&CK a vulnerability classification framework?
No. ATT&CK describes attacker behaviour, not vulnerabilities. It is best used alongside CWE, CVE, and threat modelling to explain how a weakness could be abused in practice.

How should a small engineering team start mapping findings without creating too much overhead?
Start with a simple schema in your ticketing tool or spreadsheet. Capture the weakness, CWE, likely abuse path, ATT&CK technique, confidence, exposure, and owner. Focus on high-impact findings first, then automate only when the manual process becomes repetitive.

Should every vulnerability have an ATT&CK technique assigned?
No. Only map findings where the attacker behaviour adds useful context for prioritisation, detection, or remediation planning. If the mapping is speculative or low value, it may be better to leave it untagged.

Can ATT&CK help with detection engineering as well as remediation?
Yes. Once you know the likely attacker behaviour, you can define the telemetry you need to detect it, identify gaps in logging, and test whether compensating controls are actually reducing the attack path.