[devteamaegis]

What does this PR do?

Closes #654.

The Data Exfiltration finding only matched five read actions, although its risk definition already says rds:CopyDBSnapshot and rds:CreateDBSnapshot "can be used to exfiltrate RDS database contents". A policy allowing those on * was not flagged.

This takes option 1 from the issue: a second list, reported under the same Data Exfiltration finding. No new finding type, and no UI or schema change.

• READ_ONLY_DATA_EXFILTRATION_ACTIONS keeps its name (still read-only) and gains ssm:GetParameterHistory (Read; returns past values, decrypted with WithDecryption).
• New SNAPSHOT_AND_EXPORT_DATA_EXFILTRATION_ACTIONS (all Write in policy_sentry): rds:CreateDBSnapshot, rds:CopyDBSnapshot, rds:CreateDBClusterSnapshot, rds:CopyDBClusterSnapshot, rds:StartExportTask, ec2:CreateSnapshot, ec2:CreateSnapshots, ec2:CopySnapshot, ec2:CreateInstanceExportTask, ec2:ExportImage, dynamodb:ExportTableToPointInTime.
• PolicyDocument.allows_data_exfiltration_actions and PolicyFinding.data_exfiltration match DATA_EXFILTRATION_ACTIONS (the two lists combined). exclude-actions still suppresses any of them.

Left out: secretsmanager:BatchGetSecretValue. policy_sentry has it as List level with no resource type, so it can only be granted on *, and cloudsplaining flags any allowed wildcard-only action. AWS also requires secretsmanager:GetSecretValue on each secret (API reference). So BatchGetSecretValue on * plus GetSecretValue on secret:app/* can only read app/*, but it would be flagged. When GetSecretValue is on *, that is already flagged. Happy to add it if you'd rather accept the noise.

Tests

• test/scanning/test_data_exfiltration_actions.py: no duplicates, and every action in DATA_EXFILTRATION_ACTIONS is detected when allowed on *. This guards against names policy_sentry doesn't recognise, like test_privilege_escalation_methods.py does.
• test_policy_document.py: wildcard-capable actions are flagged; restrictable-only actions (rds:StartExportTask, dynamodb:ExportTableToPointInTime) are flagged on *; ARN-scoped grants are not flagged.
• test_policy_finding.py: PolicyFinding reports them, and exclude-actions suppresses them.
• 3 of the new tests fail on main; all 136 pass on this branch.

Example data: regenerated utils/example-iam-data.json and sampleData.js (kept in sync) and index.html. just generate-report reorders lists on each run, so I kept HEAD's ordering and applied only the semantic change (~80 lines instead of ~18k). just compare-reports: "no findings dropped (77 added, 0 removed)". The additions are in AmazonRDSFullAccess, AmazonEC2FullAccess and the overly permissive teaching policies. Updated docs/glossary/data-exfiltration.md.

Open question: the description string (RISK_DEFINITION["DataExfiltration"] and its copy in glossary.js) still says "certain read-only IAM actions". Rewording it touches ~10 exact-string test expectations and needs a dist/ rebuild, so I left it out to keep this small. Glad to do it here or in a follow-up.

Note: #625 edits the same lines in PolicyFinding.data_exfiltration. If it merges first, the conflict resolution is to put DATA_EXFILTRATION_ACTIONS in its union.

What gif best describes this PR or how it makes you feel?

n/a

Completion checklist

• Additions and changes have unit tests
• pre-commit hooks and tests are passing (just lint, just unit-tests, just type-check, npm test, just safety-scan)
• The pull request has been appropriately labeled using the provided PR labels
• If the UI contents or JavaScript files have been modified, generate a new example report (no UI/JS source changes; example data and index.html regenerated)

This was investigated and written with an AI coding agent (Claude) working on my behalf.