How DCV maps AWS GuardDuty, Security Hub and Config Rules to the ATT&CK matrix, and how to extend the mappings.
AWS finding catalogues are large and structured by service, not by adversary behaviour. GuardDuty alone publishes 100+ active finding types. Without a mapping back to ATT&CK techniques, it's impossible to answer the question 'how would we detect Valid Accounts abuse in this account?' from the finding inventory.
DCV maintains the mapping so coverage analysis becomes a database join: per-account finding inventory joined against the mapper, joined against the ATT&CK matrix, equals coverage by tactic.
Not every finding is equally good evidence of a technique. A GuardDuty 'Recon:EC2/PortProbeUnprotectedPort' is a strong signal for T1595 Active Scanning (confidence 0.9). A 'Discovery:IAMUser/AnomalousBehavior' is a weaker signal that could be many things (confidence 0.75 for T1078 Valid Accounts).
DCV stores per-finding confidence weights from the MITRE Center for Threat-Informed Defense Security Stack Mappings project, plus its own additions. Coverage scoring uses the weights so a hundred low-confidence findings doesn't outweigh ten high-confidence ones.
When AWS publishes a new finding type, DCV needs the new mapping to surface it in coverage. The mapping lives in a single source file per AWS service; adding entries is a small Python PR with the new finding key, the technique id list and confidence per technique.