MITRE ATT&CK для Product Security: как связать pentest, threat modeling, CI/CD и реальные сценарии атак

Матрицу MITRE ATT&CK обычно ассоциируют с SOC, threat hunting и red team. Это база. Но она может быть полезна намного раньше — на этапе threat modeling, pentest, архитектурного review и CI/CD. И не только для инциденщиков, но и в теме Product Security. В статье разбираю, как перейти от isolated finding к attack path и связать attacker behavior с preventive controls, что такое security validation, причем тут runtime detection и release risk на примерах public API, SSRF → cloud, Kubernetes и software supply chain. Отдельно покажу, почему vulnerability нельзя автоматически превращать в ATT&CK technique и в каких Product Security сценариях ATT&CK лучше вообще не использовать.

В чем недопонимание потенциала MITRE ATT&CK

Когда говорят про MITRE ATT&CK, в голове обычно сразу появляются SOC, SIEM, threat hunting, red team и огромная цветная матрица, которую кто-то заботливо раскрасил в ATT&CK Navigator. Как уже писал в анонсе это база, все так и есть. Product Security же живёт вроде бы в другом мире: Secure SDLC, threat modeling, SAST/SCA/DAST, code review, pentest, API security, Kubernetes, cloud, CI/CD, release gates и security architecture.

Из-за этого ATT&CK часто воспринимают как инструмент, который становится полезным уже после релиза, когда продукт атакуют и нужно понять, что именно делает злоумышленник. На практике я бы смотрел на неё шире.

ATT&CK может стать общим языком между:

• pentest findings;
• abuse cases и threat model;
• AppSec и DevSecOps controls;
• cloud и Kubernetes security;
• red team и adversarial testing;
• detection engineering;
• incident response;
• release risk и security ownership.

Но есть важное условие: не надо превращать ATT&CK в ещё один каталог уязвимостей. И так, ниже в этом материале разберём, как использовать MITRE ATT&CK именно в Product Security: от отдельного finding до attack path, preventive controls, security testing, telemetry и release decision. Let's Go, парни!

TL;DR: модель в одной минуте

Если оставить от всей статьи одну идею, я бы оставил эту:

Weakness / Finding
        ↓
Attacker Action
        ↓
ATT&CK Technique
        ↓
Attack Path
        ↓
Preventive Control
        ↓
Validation
        ↓
Telemetry / Detection
        ↓
Owner + Risk Decision

Например:

SSRF
 ↓
Attacker queries cloud metadata
 ↓
T1552.005 — Cloud Instance Metadata API
 ↓
Temporary cloud credentials
 ↓
Attacker uses the credentials
 ↓
T1078.004 — Valid Accounts: Cloud Accounts
 ↓
Cloud discovery / data access

Главный принцип здесь простой:

Мы мэппим не название vulnerability. Мы мэппим действие атакующего, которое эта vulnerability делает возможным.

И если вы не можете одним предложением сказать, что именно делает attacker, ATT&CK ID, скорее всего, пока ставить рано.

ATT&CK — это не каталог уязвимостей

MITRE ATT&CK — это knowledge base тактик и техник adversary behavior.

Упрощенно:

• Tactic отвечает на вопрос: зачем attacker выполняет действие?
• Technique / Sub-technique отвечает на вопрос: каким способом он достигает этой цели?

Например:

• Initial Access — получить первоначальный доступ;
• Execution — выполнить код или команды;
• Credential Access — получить credentials;
• Discovery — понять, где attacker оказался и что ему доступно;
• Lateral Movement — двигаться дальше;
• Collection — собрать данные;
• Exfiltration — вывести их;
• Impact — нарушить работу, изменить или уничтожить данные и системы.

Если prevention когда-нибудь не сработает, увидим ли мы это поведение в production?
Но основная мысль всё равно остаётся прежней:

ATT&CK описывает поведение атакующего, а не дефект в коде.

CWE, CVE, OWASP, STRIDE и ATT&CK отвечают на разные вопросы

Частая ошибка — пытаться выбрать один «главный» framework. На практике они работают на разных слоях. Смотрим таблицу ниже.

Отсюда полезное разделение:

CWE / OWASP
Что сломано?

**ATT&CK**
Что attacker сделает с этим дальше?

**Product Security**
Как разорвать путь и доказать, что он разорван?

Четыре правила нормального ATT&CK mapping

Прежде чем переходить к кейсам, я бы ввёл четыре простых правила.

Правило 1. Начинайте с глагола атакующего

Не так:

уязвимость SSRF → T1552.005

А так:

Attacker использует SSRF, чтобы запросить cloud instance metadata и получить временные credentials → T1552.005.

Technique должна описывать действие, а не просто ассоциироваться с названием finding.

Правило 2. Не путайте prerequisite и выполненную technique

Например, excessive Kubernetes RBAC ещё не означает T1610 — Deploy Container. Он только создаёт prerequisite.

T1610 появляется, когда adversary действительно использует доступ для развёртывания контейнера.

Точно так же украденный cloud token ещё не означает T1078.004 — Valid Accounts: Cloud Accounts. Эта technique становится релевантной, когда attacker использует valid cloud credentials.

Правило 3. Не мэппите следующий шаг только потому, что он возможен

Attack path может выглядеть так:

Exploit
 ↓
Credential Access
 ↓
Discovery
 ↓
Collection
 ↓
Exfiltration

Но если вы доказали только первые два шага, не надо автоматически красить следующие три.

Разделяйте:

• observed — действие реально наблюдалось;
• validated — действие воспроизведено в controlled test;
• feasible — архитектура делает его реально достижимым;
• hypothetical — теоретически возможно, но evidence пока нет.

Правило 4. Если ATT&CK ничего не добавляет — не используйте её

Не каждый Product Security risk нужно мэппить.

Например, business-logic flaw в payout API может позволить изменить реквизиты получателя или обойти approval workflow. Это может быть критический риск, даже если ATT&CK mapping получается натянутым.

В таком случае лучше оставить:

Business Abuse Case
 → Security Requirement
 → Control
 → Test
 → Monitoring

чем ставить случайный ATT&CK ID ради красивой таблицы. Это не недостаток ATT&CK. Просто она решает другой класс задач.

Product Security mapping: от finding к attack path

Я бы использовал такую рабочую цепочку:

Asset / Crown Jewel
        ↓
Data Flow / Trust Boundary
        ↓
Abuse Case / Finding
        ↓
Attacker Action
        ↓
ATT&CK Technique(s)
        ↓
Attack Path + Business Impact
        ↓
Preventive Control
        ↓
Security Validation
        ↓
Telemetry / Detection
        ↓
Owner + Release Decision

Это принципиально отличается от стандартного workflow:

Critical finding → Jira → developer → fixed.

Для Product Security важен не только факт исправления дефекта.

Нужно понять:

1. какой asset или trust boundary затронут;
2. что именно attacker сможет сделать;
3. какой следующий шаг становится достижимым;
4. где находится реальный business impact;
5. какой control разрывает path;
6. как проверить этот control;
7. увидим ли мы атаку, если control обойдут;
8. кто владеет residual risk;
9. можно ли после этого выпускать продукт.

Кейс №1. Public-facing API: RCE — это только начало

Представим обычную архитектуру:

Internet
   ↓
API Gateway
   ↓
Public API
   ↓
Application Service
   ↓
Kubernetes / VM
   ↓
Cloud Services / Database / Storage

Pentest находит vulnerability, позволяющую добиться server-side code execution. В классическом AppSec report можно написать:

Critical RCE in public API.

Это правильно, но для Product Security слишком плоско.

Шаг 1. Как attacker попадает внутрь?

Если exploitation публичного приложения используется как initial access, здесь хорошо ложится:

T1190 — Exploit Public-Facing Application.

Но сама по себе RCE не означает, что мы должны автоматически добавить ещё пять Execution techniques. Сначала нужно посмотреть, что происходит после exploitation.

Шаг 2. Что реально умеет compromised process?

Product Security должен спросить:

• от какого OS user работает процесс;
• какие filesystem permissions у него есть;
• можно ли запустить shell или interpreter;
• какие environment variables доступны;
• какие secrets смонтированы;
• какой service account / workload identity используется;
• доступен ли Kubernetes API;
• доступен ли cloud metadata endpoint;
• какой outbound traffic разрешён;
• какие internal services достижимы;
• можно ли обратиться к database/storage напрямую.

Если attacker действительно начинает выполнять shell-команды, тогда можно рассматривать релевантную Command and Scripting Interpreter sub-technique. Но не надо выводить её только из слова RCE — mapping должен следовать фактическому действию.

### Шаг 3. Где blast radius?
Допустим, application workload имеет доступ к cloud instance metadata.

Следующий action:

Attacker обращается к metadata endpoint за credentials.

Это уже сильный mapping на:
T1552.005 — Unsecured Credentials: Cloud Instance Metadata API.

И тут появляется хороший Product Security-вопрос:

Даже если application layer когда-нибудь будет скомпрометирован, что сможет получить этот workload и куда он сможет пойти дальше?

Controls:

• workload identity вместо долгоживущих static credentials;
• least privilege IAM;
• hardened metadata access;
• egress restrictions;
• минимизация secrets в environment/config;
• network segmentation;
• минимальные permissions к internal APIs и storage.

То есть один AppSec finding начинает влиять на architecture и blast radius, а не только на код vulnerable endpoint.

## Кейс №2. SSRF → cloud metadata → credentials → data
SSRF — один из самых наглядных примеров, потому что сама MITRE для T1552.005 прямо рассматривает сценарий доступа к cloud metadata через SSRF.

Представим public-facing application с SSRF. Плоский triage:

SSRF. High/Critical. Исправить URL validation.

Attack-path подход:

SSRF
  ↓
Attacker queries Cloud Metadata API
  ↓
Temporary Credentials
  ↓
Attacker uses Cloud Account / Workload Identity
  ↓
Cloud Discovery
  ↓
Cloud Storage Access
  ↓
Collection / Exfiltration

Здесь возможны разные ATT&CK techniques — но только когда соответствующее действие реально происходит или подтверждено как feasible.

Обрати внимание на разницу между T1526 и T1580. Не надо ставить оба ID «на всякий случай».

Если attacker выясняет, какие cloud services доступны identity — это один тип discovery. Если enumerates конкретную cloud infrastructure — другой. Technique выбирается по действию, а не по желанию сделать chain длиннее.

Как это превращается в Product Security controls

Теперь security review перестаёт быть разговором об одной SSRF. Мы проверяем устойчивость продукта к целой post-exploitation chain. И особенно полезно, если chain разрывается раньше:

SSRF
 ↓
Metadata unreachable
 ↓
STOP

или:

Credentials obtained
 ↓
IAM role cannot access sensitive data
 ↓
STOP

Это уже evidence того, что defense-in-depth реально уменьшает blast radius.

Кейс №3. Kubernetes: misconfiguration ещё не technique

Допустим, security review обнаружил:

• container запускается как root;
• разрешён privileged: true;
• используется опасный hostPath;
• service account имеет избыточный RBAC;
• NetworkPolicy отсутствует.

Это серьёзные security weaknesses. Но сам список ещё не является ATT&CK chain. Нужен attacker action. Представим, что workload уже скомпрометирован, а его service account позволяет создавать pods.

Тогда возможна цепочка:

Compromised workload
       ↓
Attacker uses excessive Kubernetes permissions
       ↓
Deploys privileged container
       ↓
Mounts / accesses host resources
       ↓
Escapes to host
       ↓
Accesses other workloads / node resources

Здесь уже появляются:

• T1610 — Deploy Container — когда adversary действительно разворачивает container;
• T1611 — Escape to Host — когда происходит выход из containerized environment к host.

Product Security controls

• run as non-root;
• запрет privileged containers;
• минимизация Linux capabilities;
• read-only root filesystem где возможно;
• seccomp / AppArmor / SELinux;
• Pod Security Admission / equivalent admission policy;
• запрет опасных hostPath mounts;
• запрет host PID / IPC / network без необходимости;
• least privilege Kubernetes RBAC;
• отдельные service accounts для workloads;
• NetworkPolicy;
• минимизация Kubernetes API access;
• audit logging.

Validation

Не только manifest scanning. Полезнее проверить сам attacker path:

• может ли compromised service account создать новый pod;
• может ли он создать privileged pod;
• может ли mount host filesystem;
• доступны ли node credentials / sockets;
• можно ли обращаться к Kubernetes API из workload;
• можно ли добраться до соседних workloads.

Runtime

Telemetry тоже следует из attack path:

• создание privileged pods;
• неожиданные DaemonSets;
• новые hostPath mounts;
• изменения RBAC;
• выдача cluster-level privileges;
• аномальные API calls от workload identities;
• запуск контейнеров из неожиданных images/registries.

В итоге одна цепочка связывает AppSec, platform security, Kubernetes hardening, policy-as-code и runtime detection.

Кейс №4. CI/CD: когда valid signature ничего не гарантирует

Product Security сегодня отвечает не только за application code, но и за то, как этот код превращается в production artifact.

Представим сценарий:

1. attacker получает developer или CI credential;
2. меняет pipeline definition или referenced build script;
3. CI выполняет malicious step;
4. build создаёт изменённый artifact;
5. legitimate signing system подписывает artifact;
6. release попадает в production или к downstream customers.

При этом формально всё может выглядеть хорошо:

• SAST — passed;
• SCA — passed;
• image scan — passed;
• signature — valid.

Но доверенный build path уже контролируется attacker.

T1677 и T1195 — не одно и то же. Это место особенно важно не смешивать.

T1677 — Poisoned Pipeline Execution описывает malicious execution внутри CI/CD pipeline: прямое изменение pipeline configuration, indirect execution через referenced scripts/tests или запуск malicious code через public pipeline execution.

А T1195 — Supply Chain Compromise описывает manipulation продукта или delivery mechanism до получения конечным потребителем.
**
У него есть, в частности:**

• T1195.001 — Compromise Software Dependencies and Development Tools;
• T1195.002 — Compromise Software Supply Chain.

Поэтому:

Attacker edits your CI pipeline and steals secrets
→ T1677 is a strong mapping

А если manipulated build/dependency затем становится механизмом compromise для downstream consumer:

Compromised build / dependency
→ malicious release
→ downstream victim installs / receives it
→ T1195 becomes relevant to the supply-chain path

Не каждый CI compromise автоматически надо называть T1195.

Product Security controls

Repository / SCM

• protected branches;
• mandatory review;
• CODEOWNERS для pipeline и security-sensitive files;
• phishing-resistant MFA;
• short-lived authentication;
• минимизация personal access tokens;
• audit privileged changes.

CI/CD

• protected pipeline definitions;
• isolated / ephemeral runners;
• least privilege CI identity;
• separation build / deploy / signing authority;
• secrets только на тех stages, где они реально нужны;
• запрет untrusted PR на privileged runners;
• контроль third-party actions/plugins;
• immutable or tightly controlled runner images.

Artifact integrity

• provenance;
• SBOM;
• signatures;
• immutable artifact storage;
• promotion одного и того же artifact между environments вместо повторной сборки;
• reproducible/verifiable builds там, где это практически оправдано.

Release governance

• independent approval для high-risk production changes;
• audit trail;
• rollback;
• kill switch;
• разделение прав на source, build, signing и deployment.

И здесь есть хороший принцип:

Valid signature подтверждает, что artifact прошёл через signing authority. Она не доказывает, что build process до подписания был trustworthy.

Поэтому supply-chain threat model должен смотреть на всю цепочку:

Source
  ↓
Build Configuration
  ↓
Dependencies
  ↓
Runner
  ↓
Artifact
  ↓
Signing
  ↓
Registry
  ↓
Deployment / Distribution

Как встроить ATT&CK в pentest, а не просто приклеить ID к отчёту

Pentest отлично интегрируется в такую модель, если перестать воспринимать его как PDF со списком findings. Для каждого high-risk finding я бы добавлял четыре вопроса:

1. Какое конкретное действие attacker теперь может выполнить?
2. Какой prerequisite нужен для следующего шага?
3. Какая ATT&CK technique описывает этот action, если такая техника действительно есть?
4. Какой control разрывает следующий шаг?

Пример:

Так pentest finding превращается в security engineering input, а не просто remediation ticket.

Что получает red team

Для red team ATT&CK mapping — привычная вещь, но Product Security добавляет другой фокус. Red team может проверить не только «можем ли мы выполнить technique», а какие product controls должны были остановить путь раньше.

Например:

T1190 — public application exploited
 ↓
Product control failed
 ↓
T1552.005 — metadata queried
 ↓
Cloud boundary failed
 ↓
T1078.004 — cloud identity used
 ↓
IAM boundary failed
 ↓
T1530 — storage data collected

После exercise обсуждение становится намного полезнее:

• какой control отсутствовал;
• какой существовал, но был bypassed;
• какой сработал;
• где detection появился слишком поздно;
• где attack path остановился;
• какой team владеет remediation.

Это уже не просто «red team дошёл до цели», а проверка многослойной security architecture продукта.

Threat modeling + ATT&CK

STRIDE и ATT&CK иногда пытаются противопоставлять. На мой взгляд, гораздо полезнее использовать их вместе. STRIDE помогает задавать design-time вопросы:

• можно ли spoof identity;
• можно ли tamper data;
• есть ли repudiation problem;
• возможен information disclosure;
• можно ли вызвать denial of service;
• возможна privilege escalation.

ATT&CK добавляет другой слой:

Как подобное поведение может выглядеть в реальном adversary operation?

Представим data flow:

User
 ↓
Web / Mobile
 ↓
API
 ↓
Identity Provider
 ↓
Backend
 ↓
Database
 ↓
Cloud Storage

После определения assets и trust boundaries я бы не открывал всю Enterprise Matrix и не шёл слева направо по каждой клетке. Лучше начать с attacker objectives и релевантных surfaces.

Для internet-facing SaaS могут быть полезны:

• Initial Access;
• Credential Access;
• Discovery;
• Persistence;
• Collection;
• Exfiltration;
• Impact.

Для cloud-native продукта:

• cloud account abuse;
• metadata / credential access;
• cloud discovery;
• storage access;
• cloud resource modification;
• logging / defense impairment.

Для Kubernetes:

• container execution/deployment;
• cluster credentials;
• container escape;
• discovery;
• lateral movement.

Для software factory:

• Poisoned Pipeline Execution;
• credential abuse;
• dependency/development-tool compromise;
• software supply-chain compromise.

ATT&CK становится не заменой threat model, а библиотекой attacker behavior, которая помогает расширить threat modeling session реальными post-exploitation сценариями.

От ATT&CK к controls: Mitigations и D3FEND

Есть ещё один полезный нюанс. ATT&CK содержит Enterprise Mitigations — классы defensive measures, способных снижать вероятность успешного выполнения techniques.

Но Product Security controls часто намного конкретнее:

• deny hostPath;
• require non-root;
• pin GitHub Action to immutable commit;
• block workload access to metadata;
• require step-up auth for payout change;
• separate signing identity from build identity.

Поэтому ATT&CK Mitigations можно использовать как reference, но не обязательно заставлять всю engineering control library жить внутри ATT&CK taxonomy. Если нужен именно defensive knowledge graph, можно дополнительно посмотреть на MITRE D3FEND, который ориентирован на cybersecurity countermeasures и связи defensive techniques с offensive behavior.

Практический подход может быть таким:

ATT&CK
What does the attacker do?

Product Security Controls / ASVS / Cloud & K8s Policies
What prevents it in our product?

D3FEND / ATT&CK Mitigations
What defensive patterns may complement the design?

От prevention к detection: не заканчиваем на fix

Product Security иногда слишком сильно уходит в shift-left. Shift-left полезен, но продукт после релиза не исчезает. Поэтому для critical attack path я бы всегда задавал два вопроса:

1. Как мы предотвращаем этот behavior?
2. Как мы поймём, что он происходит, если prevention обойдут?

Современная ATT&CK detection-модель хорошо поддерживает этот подход.

Например, для T1552.005 у MITRE есть Detection Strategy DET0001, ориентированная на обращения к cloud metadata endpoint, включая direct access и SSRF-related patterns. Это хороший пример связи design и telemetry.

Если metadata access является важным security boundary, Product Security может потребовать:

• network telemetry для metadata requests;
• workload identity context;
• cloud audit logs;
• correlation с необычным последующим API usage;
• alerting для workload, который обычно metadata не запрашивает.

То же самое для Kubernetes:

• privileged pod creation;
• RBAC modifications;
• неожиданные DaemonSets;
• access к sensitive cluster resources.

И для CI/CD:

• изменение pipeline definitions;
• запуск workflow из необычного context;
• доступ build job к signing secrets;
• изменение trusted dependency/action;
• anomalous artifact publication.

Так Product Security начинает влиять не только на secure code, но и на security observability продукта.

Простой шаблон для threat model / Jira / security backlog

Не обязательно строить отдельную дорогую платформу. Можно добавить несколько полей в существующий security backlog.

Например:

Asset: payments-api
Crown jewel: payout data
Trust boundary: Internet -> API

**Finding:** SSRF in webhook validation
Severity: High

Attacker action:**
  Query cloud instance metadata through SSRF

**ATT&CK:**
  validated:
    - T1552.005
  feasible_if_credentials_are_used:
    - T1078.004
  feasible_if_storage_is_reachable:
    - T1530

**Attack path:**
  SSRF -> metadata -> temporary credentials -> cloud storage

**Business impact:**
  Unauthorized access to payout/customer data

**Preventive controls:**
  - outbound destination allowlist
  - hardened metadata access
  - scoped workload identity
  - least privilege storage policy

**Validation:**
  - SSRF regression test
  - metadata reachability test
  - IAM effective-permission test
  - negative storage authorization test

**Detection:**
  - metadata access telemetry
  - unusual cloud API enumeration
  - abnormal storage reads

**Owner:** Payments Platform
Release status: Blocked until metadata/credential path is broken
Residual risk: Low after control validation

Обратите внимание на поля validated и feasible. Они помогают не превращать ATT&CK mapping в утверждение, будто вся цепочка уже была реально выполнена.

Как использовать ATT&CK Navigator в Product Security

ATT&CK Navigator удобен для визуализации coverage.

Но здесь есть ловушка. Очень легко получить красивую матрицу, в которой половина cells зелёная, четверть жёлтая, и никто не может объяснить, что именно означает цвет.

Я бы не начинал с вопроса:

Сколько процентов MITRE ATT&CK мы закрываем?

Для Product Security это почти всегда слишком абстрактно. Полезнее сделать несколько отдельных layers.

Layer 1 — Threat Relevance

Techniques, реально релевантные конкретному product architecture и threat model.

Layer 2 — Preventive Coverage

Где существует реальный preventive control.

Layer 3 — Validation Coverage

Какие controls проверены через:

• pentest;
• adversarial testing;
• CI/CD tests;
• cloud/Kubernetes assessment;
• architecture review.

Layer 4 — Detection Coverage

Какие relevant techniques видны через production telemetry и detections.

Layer 5 — Known Gaps

Самый полезный слой.

Например:

Эти семь behaviors релевантны продукту, но для трёх у нас нет validated prevention, а для двух — detection. Вот это уже security roadmap.

ATT&CK как мост между AppSec, DevSecOps, Cloud и SOC

Одна из постоянных организационных проблем в security — разные команды говорят на разных языках.

AppSec:

SSRF in public service.

Cloud Security:

Workload role is overprivileged.

SOC:

Unexpected API enumeration from service identity.

DevOps:

Это обычный pod с access к AWS API.

Product Security может соединить их:

AppSec
SSRF in public service
        ↓
ATT&CK / Attack Path
T1552.005 -> T1078.004 -> discovery -> T1530
        ↓
Cloud Security
Metadata + IAM blast radius
        ↓
DevSecOps
Egress / workload identity / policy-as-code
        ↓
SOC / Detection
Metadata access + unusual cloud API activity

Теперь разные команды обсуждают один attack path, а не четыре независимых тикета. Для меня это одна из самых сильных сторон ATT&CK в Product Security.

Как встроить ATT&CK в Secure SDLC

Не надо добавлять отдельный двадцатистраничный процесс. Mapping можно встроить в существующие точки SDLC.

Получается feedback loop:

Threat Model
    ↓
Engineering Controls
    ↓
Security Validation
    ↓
Production Telemetry
    ↓
Incidents / Threat Intelligence
    ↓
Updated Threat Model

Так ATT&CK становится живым инструментом, а не compliance-таблицей.

Минимальный вариант, с которого можно начать завтра

Если ATT&CK пока живёт только у SOC/red team, не надо запускать большой transformation project. Возьмите один critical product.

Шаг 1. Выберите crown jewels

Например:

• customer data;
• payment flow;
• production deployment;
• signing keys;
• cloud control plane.

Шаг 2. Выберите 5–10 realistic attack paths

Не techniques. Именно paths.
Например:

Public API exploit
→ workload identity
→ cloud storage

или:

Developer account
→ CI pipeline
→ signing
→ production release

Шаг 3. Для каждого шага сформулируйте attacker action

Если action нельзя сформулировать — mapping ещё сырой.

Шаг 4. Добавьте ATT&CK только там, где есть точное соответствие

Не пытайтесь заполнить каждую строку.

Шаг 5. Для каждой relevant technique укажите

• prerequisite;
• preventive control;
• validation method;
• telemetry/detection;
• owner.

Шаг 6. Проведите targeted security test

Не «пентест всего интернета», а проверку конкретного path.

Шаг 7. Зафиксируйте evidence

Например:

• validated;
• blocked;
• detected;
• not tested;
• accepted risk.

Шаг 8. Обновляйте mapping после изменений

Триггеры:

• major architecture change;
• новый cloud service;
• новая CI/CD platform;
• material pentest finding;
• incident;
• значимое изменение threat intelligence.

Этого уже достаточно, чтобы ATT&CK начала приносить практическую пользу.

Какие метрики действительно полезны

• % critical attack paths с validated preventive controls;
• % critical attack paths с detection coverage;
• % high-impact techniques с defined owner;
• количество attack paths, где следующий шаг остаётся feasible после remediation;
• количество release blockers по high-impact paths;
• время от finding до validated control;
• количество повторных findings, указывающих на один systematic control gap;
• количество critical paths, проверенных adversarial testing;
• coverage релевантных, а не всех существующих ATT&CK techniques.

Для Product Security lead/director это уже нормальный разговор о risk reduction, а не о раскрашивании framework.

Итог

MITRE ATT&CK не делает Product Security за нас. Она не заменяет:

• secure architecture;
• threat modeling;
• OWASP ASVS;
• code review;
• SAST/SCA/DAST;
• pentest;
• cloud hardening;
• Kubernetes security;
• secure CI/CD;
• detection engineering;
• incident response.

Но она может связать эти дисциплины в одну понятную цепочку. Для меня главный смысл выглядит так:

Vulnerability говорит, где продукт слаб. ATT&CK помогает описать, что adversary делает с этой слабостью дальше. Product Security должен разорвать attack path — и уметь доказать, что он разорван.

Поэтому вместо вопроса:

На какую технику MITRE замэппить этот finding?

я бы задавал другой:

Какое конкретное действие attacker выполняет, какой следующий шаг оно открывает и на каком этапе мы этот путь предотвращаем, проверяем и детектируем?

Тогда ATT&CK перестаёт быть матрицей «для SOC и red team» и становится вполне практичным инструментом Product Security.

Полезные источники

• MITRE ATT&CK
• Enterprise ATT&CK Matrix
• ATT&CK Updates — current release
• ATT&CK Data & Tools
• ATT&CK Navigator
• Enterprise Mitigations
• Detection Strategies
• Analytics
• Data Components
• T1190 — Exploit Public-Facing Application
• T1552.005 — Cloud Instance Metadata API
• DET0001 — Detect Access to Cloud Instance Metadata API
• T1078.004 — Valid Accounts: Cloud Accounts
• T1526 — Cloud Service Discovery
• T1580 — Cloud Infrastructure Discovery
• T1530 — Data from Cloud Storage
• T1610 — Deploy Container
• T1611 — Escape to Host
• T1677 — Poisoned Pipeline Execution
• T1195 — Supply Chain Compromise
• T1195.001 — Compromise Software Dependencies and Development Tools
• T1195.002 — Compromise Software Supply Chain
• MITRE D3FEND