rtexit-method 0.1.0 → 0.1.2

package/packaged-assets/.agents/skills/rt-remediation-roadmap/template.md

@@ -0,0 +1,28 @@
+# Remediation Roadmap Template
+
+## Prioritization Logic
+
+Prioritize by severity, exploitability, internet exposure, affected data, dependency chains, and business owner urgency.
+
+| Priority | Finding | Severity | Owner | Action | Timeline | Validation |
+|---:|---|---|---|---|---|---|
+| 1 | F-XXX | Critical | [team] | [action] | 0-7 days | [test] |
+
+## Immediate: 0-7 Days
+
+- [ ] Contain externally exposed critical issues.
+- [ ] Rotate exposed secrets.
+- [ ] Disable vulnerable functionality if required.
+
+## Short Term: 8-30 Days
+
+- [ ] Patch affected components.
+- [ ] Add authorization and input validation tests.
+- [ ] Harden identity and network controls.
+
+## Long Term: 31-90 Days
+
+- [ ] Add secure SDLC guardrails.
+- [ ] Add attack surface monitoring.
+- [ ] Add recurring control validation.
+

package/packaged-assets/.agents/skills/rt-risk-matrix/SKILL.md

@@ -0,0 +1,232 @@
+---
+name: rt-risk-matrix
+description: "Generate risk matrix (Likelihood x Impact) for all engagement findings. Plots each finding on 5x5 risk grid, calculates residual risk, and produces executive heat map visualization. Shows risk distribution and helps prioritize remediation. Uses CVSS scores as input and adds business context."
+---
+
+# rt-risk-matrix Skill
+
+## Purpose and When to Use
+
+The `rt-risk-matrix` skill generates a structured risk matrix for all findings produced during an RTExit engagement. It translates raw technical findings (CVSS scores, vulnerability classifications) into a business-contextualized risk view by plotting each finding on a 5x5 Likelihood x Impact grid, calculating residual risk scores, and producing an executive-ready heat map visualization.
+
+Use this skill when:
+
+- An engagement is complete or near-complete and findings need to be prioritized for the client.
+- The client requires an executive summary with visual risk communication (heat map).
+- You need to calculate residual risk after applying existing or proposed controls.
+- Remediation prioritization is needed across a large set of heterogeneous findings.
+- A risk register deliverable is required as part of the reporting package.
+
+---
+
+## Step-by-Step Workflow
+
+### Step 1: Gather Findings Input
+
+Collect all findings from the engagement. Accepted input formats:
+
+- JSON findings export from RTExit pipeline (`findings.json`)
+- CVSS vector strings (v3.0 or v3.1) per finding
+- Manual finding entries with title, description, likelihood, and impact ratings
+
+Each finding should include at minimum:
+
+- Finding ID or title
+- CVSS base score (or manual likelihood/impact values)
+- Affected asset or component
+- Existing controls (if any, for residual risk calculation)
+
+### Step 2: Map CVSS to Likelihood and Impact
+
+The skill decomposes CVSS scores into the two matrix axes:
+
+| CVSS Range | Risk Level | Matrix Value |
+|------------|------------|--------------|
+| 9.0 - 10.0 | Critical   | 5            |
+| 7.0 - 8.9  | High       | 4            |
+| 4.0 - 6.9  | Medium     | 3            |
+| 2.0 - 3.9  | Low        | 2            |
+| 0.0 - 1.9  | Informational | 1         |
+
+Likelihood derives from CVSS Attack Vector, Attack Complexity, and Privileges Required sub-scores. Impact derives from Confidentiality, Integrity, and Availability impact sub-scores.
+
+If CVSS is unavailable, prompt for manual 1-5 ratings on each axis.
+
+### Step 3: Plot the 5x5 Risk Grid
+
+Each finding is placed on the grid using coordinates (Likelihood, Impact). The resulting heat map zones are:
+
+```
+Impact
+  5 | MED  HIGH  CRIT  CRIT  CRIT
+  4 | LOW  MED   HIGH  CRIT  CRIT
+  3 | LOW  LOW   MED   HIGH  CRIT
+  2 | LOW  LOW   LOW   MED   HIGH
+  1 | LOW  LOW   LOW   LOW   MED
+      1     2     3     4     5   --> Likelihood
+```
+
+Color zones:
+- CRIT (red): Immediate action required
+- HIGH (orange): Action within sprint/week
+- MED (yellow): Action within release cycle
+- LOW (green): Accept or defer
+
+### Step 4: Calculate Residual Risk
+
+For each finding, apply existing controls to reduce the inherent risk:
+
+- Identify compensating controls from asset inventory or client input.
+- Apply control effectiveness rating (None / Partial / Effective).
+- Recalculate likelihood and/or impact after control application.
+- Plot residual risk position on a second overlay of the same grid.
+
+Residual risk score formula:
+
+```
+Residual Risk = Inherent Risk x (1 - Control Effectiveness %)
+```
+
+Control effectiveness mappings:
+
+| Control State | Effectiveness |
+|---------------|---------------|
+| None          | 0%            |
+| Partial       | 30%           |
+| Effective     | 60%           |
+| Strong        | 80%           |
+
+### Step 5: Produce Heat Map Visualization
+
+Generate a text-based or exportable heat map suitable for the report:
+
+- ASCII grid for inline report embedding.
+- Finding IDs annotated at their grid coordinates.
+- Separate overlays for inherent and residual risk.
+- Legend with finding ID to title mapping.
+
+### Step 6: Generate Risk Distribution Summary
+
+Produce a summary table showing finding counts per risk zone:
+
+```
+Zone         | Inherent Count | Residual Count | Delta
+-------------|----------------|----------------|------
+Critical     | X              | X              | -X
+High         | X              | X              | -X
+Medium       | X              | X              | -X
+Low          | X              | X              | -X
+```
+
+### Step 7: Output Remediation Priority List
+
+Sort all findings by risk score (descending) and output a prioritized remediation list:
+
+- Finding ID, title, risk zone, recommended action, and suggested timeline.
+- Flag any findings where residual risk remains Critical after controls.
+
+---
+
+## Integration with RTExit Scripts and Other Skills
+
+### RTExit Script Integration
+
+- `findings.json` — primary input; produced by the main RTExit evidence collection pipeline.
+- `asset-inventory.json` — used to identify existing controls per asset for residual risk calculation.
+- `report-builder` script — consumes the risk matrix output (`risk-matrix.json`) to embed the heat map and priority table in the final report.
+- `cvss-calculator` utility — invoked automatically if CVSS vectors are present and need decomposition.
+
+### Skill Dependencies and Handoffs
+
+| Skill | Relationship |
+|-------|-------------|
+| `rt-findings-classifier` | Run before this skill to ensure findings are categorized and CVSS-scored. |
+| `rt-executive-summary` | Consumes the heat map and risk distribution table produced by this skill. |
+| `rt-remediation-roadmap` | Ingests the prioritized finding list to build a phased remediation plan. |
+| `rt-report-builder` | Embeds all outputs from this skill into the deliverable report. |
+
+Recommended skill execution order:
+
+```
+rt-findings-classifier -> rt-risk-matrix -> rt-remediation-roadmap -> rt-executive-summary -> rt-report-builder
+```
+
+---
+
+## Example Outputs and Interactions
+
+### Example 1: Basic Invocation
+
+User prompt:
+> Run the risk matrix for this engagement. Findings are in findings.json.
+
+Skill response:
+> Loading 14 findings from findings.json. Mapping CVSS scores to likelihood/impact axes.
+> Plotting 5x5 risk grid... done.
+> Calculating residual risk using controls from asset-inventory.json... done.
+> Risk distribution: Critical: 3, High: 5, Medium: 4, Low: 2.
+> Heat map and priority list ready. Exporting risk-matrix.json and risk-heatmap.txt.
+
+### Example 2: Manual Rating Input
+
+When CVSS scores are absent, the skill prompts:
+
+> Finding: "Unencrypted backup storage"
+> No CVSS score found. Please rate:
+> - Likelihood (1=Rare, 2=Unlikely, 3=Possible, 4=Likely, 5=Almost Certain): 3
+> - Impact (1=Negligible, 2=Minor, 3=Moderate, 4=Major, 5=Catastrophic): 5
+> Inherent risk zone: CRITICAL (3x5=15). Existing controls? (None/Partial/Effective/Strong): Partial
+> Residual risk zone: HIGH (adjusted score: 10.5).
+
+### Example 3: Heat Map Output (ASCII)
+
+```
+         RISK HEAT MAP - ACME Corp Engagement (2026-05-31)
+         Inherent Risk | O = finding location
+
+Impact
+  5 |  .    .    F04  F01  F03
+  4 |  .    F12  F07  F02  .
+  3 |  F14  F11  F08  F05  .
+  2 |  F13  .    F10  F09  .
+  1 |  .    .    .    .    F06
+       1    2    3    4    5    Likelihood
+
+Legend:
+F01 - SQL Injection in login endpoint         [CRITICAL]
+F02 - Default credentials on admin panel      [CRITICAL]
+F03 - Remote code execution via file upload   [CRITICAL]
+...
+```
+
+### Example 4: Prioritized Remediation List Output
+
+```
+Priority | ID  | Title                              | Zone     | Action          | Timeline
+---------|-----|------------------------------------|----------|-----------------|----------
+1        | F01 | SQL Injection in login endpoint    | Critical | Patch & retest  | Immediate
+2        | F03 | RCE via file upload                | Critical | Patch & retest  | Immediate
+3        | F02 | Default credentials on admin panel | Critical | Rotate & harden | 24 hours
+4        | F05 | Outdated TLS configuration         | High     | Update config   | 1 week
+...
+```
+
+---
+
+## Practical Usage Tips
+
+- Run `rt-findings-classifier` first to ensure all findings have valid CVSS scores before invoking this skill. Missing scores cause manual prompting which slows execution.
+
+- When clients have strong existing controls, request the control inventory upfront. Residual risk often shifts the priority conversation significantly in executive presentations.
+
+- For engagements with more than 20 findings, group findings by asset or finding category before plotting. Overcrowded grids lose readability in executive reports.
+
+- Always produce both inherent and residual heat maps. The delta between the two maps is often the most compelling visual for demonstrating the value of existing security investments.
+
+- If a finding remains Critical after all controls are applied (residual risk still Critical), flag it explicitly in the executive summary as an unmitigated critical exposure requiring immediate escalation.
+
+- The ASCII heat map is suitable for markdown reports and terminal output. For formal PDF deliverables, pass the `risk-matrix.json` output to the `rt-report-builder` skill which renders a styled visual version.
+
+- Business context matters. After the technical risk calculation, review each Critical and High finding with the client's business impact in mind. A Critical technical finding on a non-production, air-gapped system may be re-rated once business context is applied. Document any manual overrides with justification.
+
+- Save `risk-matrix.json` to the engagement archive. It serves as the baseline for future engagements, allowing trend analysis and control improvement tracking over time.

package/packaged-assets/.agents/skills/rt-rules-of-engagement/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: rt-rules-of-engagement
+description: "Define and document Rules of Engagement (RoE) for the Red Team engagement. Covers testing permissions, prohibited actions, escalation procedures, emergency stop criteria, data handling, and evidence retention. Creates rules-of-engagement.md."
+---
+
+# rt-rules-of-engagement
+
+# Rules of Engagement Workflow
+
+## Step 1 — Testing Permissions Matrix
+For each activity, confirm with client: Permitted / Not permitted / With conditions
+
+**Automated Testing:**
+- Vulnerability scanners (Nessus, Nuclei, OpenVAS)
+- Web application scanners (Burp Suite, OWASP ZAP)
+- Port scanners (Nmap, Masscan)
+- Password spraying tools
+
+**Manual Exploitation:**
+- Web vulnerability exploitation
+- Network exploitation
+- Credential stuffing/brute force
+- Privilege escalation attempts
+
+**Advanced Techniques:**
+- Social engineering (phishing, vishing)
+- Physical security testing
+- DoS/DDoS simulation (with prior notice)
+- Persistent backdoors (document + remove)
+- Data exfiltration PoC (minimum sample)
+
+## Step 2 — Prohibited Actions (Always)
+List activities NEVER permitted regardless of scope:
+- Destroying or corrupting production data
+- Taking production systems offline
+- Accessing out-of-scope systems
+- Sharing client data with third parties
+- Storing credentials beyond engagement period
+
+## Step 3 — Emergency Stop Criteria
+Define conditions that require IMMEDIATE testing halt:
+- Discovery of ongoing real-world attack
+- Inadvertent access to systems outside scope
+- Production system becomes unavailable
+- Client requests immediate stop
+- Discovery of criminal activity evidence
+
+Emergency stop procedure:
+1. Stop all testing immediately
+2. Notify CISO/security contact
+3. Preserve evidence of current state
+4. Wait for written authorization to resume
+
+## Step 4 — Escalation Procedures
+When to escalate to CISO:
+- Critical RCE found on production system
+- Active data breach indicators found
+- Credentials for extremely sensitive systems discovered
+- Scope creep detected
+
+## Step 5 — Save RoE Document
+Create: `_rtexit-output/docs/engagement/rules-of-engagement.md`

package/packaged-assets/.agents/skills/rt-rules-of-engagement/workflow.md

@@ -0,0 +1,68 @@
+# Workflow - rt-rules-of-engagement
+
+## Purpose
+
+This workflow standardizes how $skill is executed inside RTExit. It is designed for authorized engagements, evidence-first documentation, and consistent handoff into reporting.
+
+## Authorization Gate
+
+Before execution, confirm:
+
+- SEAD exists and explicitly covers the target asset or activity.
+- Rules of Engagement define allowed techniques, rate limits, and stop conditions.
+- The operator knows the evidence handling rules.
+- Any active or sensitive validation has client approval.
+
+If any item is unclear, pause and invoke 
+
+## Required Inputs
+
+| Input | Source | Notes |
+|---|---|---|
+| Engagement reference | _rtexit/config.toml or SEAD | Used in output names. |
+| Target asset(s) | Scope document | Must be explicitly approved. |
+| Operator name | Config/user context | Used in timeline entries. |
+| Evidence directory | _rtexit-output/docs/evidence/ | Store logs, screenshots, and artifacts. |
+| Finding tracker | _rtexit-output/docs/findings/ | Create/update findings when confirmed. |
+
+## Execution Steps
+
+1. Load current engagement configuration.
+2. Read scope, exclusions, and current findings.
+3. Build a small test plan for this skill with target, expected control, and evidence type.
+4. Run the lowest-risk validation first.
+5. Capture baseline behavior before proof behavior.
+6. Record exact timestamp, account/role used, and affected asset.
+7. Stop when evidence is sufficient; avoid unnecessary data access.
+8. Create or update findings through the RTExit finding tracker.
+9. Map remediation owner and recommended timeline.
+10. Add a timeline entry and evidence chain entry.
+
+## Evidence Requirements
+
+| Evidence | Required? | Notes |
+|---|---|---|
+| Command or action summary | Yes | Redact secrets and tokens. |
+| Screenshot or transcript | If useful | Store under evidence folder. |
+| Request/response pair | For web/API | Redact cookies and bearer tokens. |
+| Config excerpt | For cloud/infra | Include only relevant lines. |
+| Business impact note | Yes | Explain why it matters. |
+
+## Autodoc Commands
+
+`ash
+python _rtexit/scripts/autodoc_engine.py log --skill rt-rules-of-engagement --phase auto --cmd "workflow execution" --output "summary"
+python _rtexit/scripts/finding_tracker.py list
+`
+
+## Completion Criteria
+
+- Scope and authorization are referenced.
+- Evidence is stored and redacted.
+- Findings are added or explicitly marked as not found.
+- Remediation guidance is actionable.
+- Timeline and chain of custody are updated where applicable.
+
+## Handoff
+
+Send confirmed findings to 

package/packaged-assets/.agents/skills/rt-scenario-c001/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: rt-scenario-c001
+description: "C-001: Cloud IAM privilege-escalation path assessment. Domain: cloud. Authorized scenario for identifying overpermissive identities, escalation-capable permissions, detection opportunities, and least-privilege remediation."
+---
+
+# C-001: Cloud IAM Escalation Path
+
+## Overview
+
+Cloud IAM escalation often results from combinations of permissions that look harmless alone but create administrative impact together. This scenario identifies those paths without modifying production privileges unless explicitly approved.
+
+| Field | Value |
+|---|---|
+| Domain | Cloud |
+| Objective | Find privilege-escalation paths |
+| Required Access | Read-only IAM/security review role preferred |
+| Detection Risk | Low for read-only review |
+| Primary Impact | Cloud account/subscription/project compromise |
+
+## Prerequisites
+
+- Cloud accounts/subscriptions/projects in scope.
+- Approved role and API access.
+- Permission boundaries for validation.
+- Change freeze rules understood.
+- Break-glass contact available.
+
+## Risk Patterns
+
+| Pattern | Example Control Gap |
+|---|---|
+| Policy Attachment | Identity can grant itself broader permissions. |
+| Role Passing | Identity can pass privileged roles to compute. |
+| Function/Automation Update | Identity can modify code running as privileged role. |
+| Key Creation | Identity can create credentials for privileged principals. |
+| Trust Policy Weakness | External or unintended principals can assume roles. |
+
+## Workflow
+
+1. Inventory identities, groups, roles, service principals, and workload identities.
+2. Identify high-value permissions and admin-equivalent roles.
+3. Build escalation path candidates.
+4. Validate with policy simulation or read-only evidence.
+5. Document affected identity, target role, required permissions, and impact.
+6. Recommend the earliest permission removal that breaks the path.
+
+## MITRE ATT&CK Mapping
+
+| Phase | Tactic | Technique |
+|---|---|---|
+| Access | Initial Access | Valid Cloud Accounts |
+| Escalation | Privilege Escalation | Abuse Elevation Control Mechanism |
+| Defense | Defense Evasion | Modify Cloud Compute Infrastructure |
+
+## Evidence
+
+- Identity ARN/object ID.
+- Relevant policy statements.
+- Trust relationship.
+- Simulation output.
+- Business owner if known.
+
+## Remediation
+
+- Apply least privilege.
+- Use permission boundaries.
+- Restrict role passing.
+- Separate deployment and runtime roles.
+- Monitor IAM policy changes.
+- Require approval for privileged role changes.
+

package/packaged-assets/.agents/skills/rt-scenario-c002/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: rt-scenario-c002
+description: "C-002: Object storage exposure assessment for S3/Azure Blob/GCS. Domain: cloud. Authorized scenario for public access review, sensitive data sampling, logging validation, and remediation."
+---
+
+# C-002: Object Storage Data Exposure
+
+## Overview
+
+Object storage frequently holds backups, exports, logs, application assets, and sensitive documents. Misconfigured public access or overly broad IAM can expose data at large scale.
+
+| Field | Value |
+|---|---|
+| Domain | Cloud Storage |
+| Objective | Validate storage exposure and data sensitivity |
+| Required Access | Cloud inventory/read role or approved public review |
+| Detection Risk | Low |
+| Primary Impact | Sensitive data disclosure |
+
+## Prerequisites
+
+- Storage accounts/buckets/projects in scope.
+- Sampling rules and data redaction requirements.
+- Approval for public access checks.
+- Logging review access if possible.
+
+## Workflow
+
+1. Inventory buckets/containers and owners.
+2. Review public access blocks, ACLs, bucket policies, and IAM grants.
+3. Review encryption, versioning, lifecycle, and logging.
+4. Sample approved objects only.
+5. Classify exposed data: secrets, backups, PII, logs, source code, reports.
+6. Prioritize by exposure, sensitivity, and business owner.
+
+## Risk Indicators
+
+- Public listing.
+- Public object read.
+- Broad `allUsers` or equivalent grants.
+- Cross-account wildcard access.
+- Backup files in internet-accessible buckets.
+- Logs containing tokens or credentials.
+
+## MITRE ATT&CK Mapping
+
+| Phase | Tactic | Technique |
+|---|---|---|
+| Discovery | Discovery | Cloud Storage Object Discovery |
+| Collection | Collection | Data from Cloud Storage |
+| Exfiltration | Exfiltration | Exfiltration to Cloud Storage |
+
+## Evidence
+
+- Bucket/container name.
+- Policy excerpt.
+- Public access state.
+- Redacted object sample metadata.
+- Logging status.
+
+## Remediation
+
+- Block public access.
+- Remove broad IAM grants.
+- Encrypt sensitive storage.
+- Add access logging and alerting.
+- Move backups to restricted accounts.
+- Add data classification and retention controls.
+

package/packaged-assets/.agents/skills/rt-scenario-c003/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: rt-scenario-c003
+description: "C-003: Cloud metadata exposure risk assessment through SSRF or workload misconfiguration. Domain: cloud. Authorized scenario for IMDS protection, workload identity minimization, and SSRF remediation."
+---
+
+# C-003: Metadata Exposure Risk
+
+## Overview
+
+Applications running on cloud compute may have access to metadata services and workload credentials. If an SSRF or egress flaw reaches metadata endpoints, a web vulnerability can become cloud identity compromise.
+
+| Field | Value |
+|---|---|
+| Domain | Cloud / Web |
+| Objective | Assess metadata credential exposure risk |
+| Required Access | In-scope app and cloud workload context |
+| Detection Risk | Medium for active validation |
+| Primary Impact | Workload credential exposure |
+
+## Prerequisites
+
+- Application endpoint in scope.
+- Cloud workload identified.
+- SSRF testing approved.
+- Metadata access rules defined.
+- No harvesting live credentials unless explicitly authorized.
+
+## Workflow
+
+1. Map URL-fetching or webhook features in the application.
+2. Identify cloud workload and assigned role/identity.
+3. Review metadata service hardening: IMDSv2 or provider equivalent.
+4. Validate SSRF using benign callback or safe metadata endpoint.
+5. Determine role blast radius from IAM policy review.
+6. Recommend SSRF and cloud identity hardening.
+
+## Safe Evidence
+
+Prefer:
+
+- Metadata service configuration.
+- Egress path proof to controlled callback.
+- IAM role policy summary.
+- Blocked metadata request screenshot.
+
+Avoid collecting live temporary credentials unless approved.
+
+## MITRE ATT&CK Mapping
+
+| Phase | Tactic | Technique |
+|---|---|---|
+| Initial Access | Initial Access | Exploit Public-Facing Application |
+| Credential Access | Credential Access | Cloud Instance Metadata API |
+| Valid Access | Defense Evasion / Persistence | Cloud Accounts |
+
+## Detection
+
+- Web requests to metadata IPs.
+- Unusual egress from application servers.
+- Temporary credential use from unexpected IPs.
+- IAM API enumeration after web-layer anomaly.
+
+## Remediation
+
+- Enforce IMDSv2 or equivalent.
+- Block metadata IP access from application fetchers.
+- Add URL allowlists and DNS/IP validation.
+- Remove unnecessary workload permissions.
+- Add egress filtering.
+- Monitor cloud credential use.
+

package/packaged-assets/.agents/skills/rt-scenario-c004/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: rt-scenario-c004
+description: "C-004: Serverless function code and deployment pipeline security assessment. Domain: cloud. Authorized scenario for function IAM, event validation, secrets handling, dependency risk, and CI/CD controls."
+---
+
+# C-004: Serverless Code and Event Injection Risk
+
+## Overview
+
+Serverless functions can become high-impact if event inputs are trusted, deployment roles are overprivileged, secrets are exposed, or dependencies are unreviewed. This scenario assesses the path from function input or pipeline weakness to business impact.
+
+| Field | Value |
+|---|---|
+| Domain | Cloud / Serverless |
+| Objective | Assess function abuse and deployment risk |
+| Required Access | Cloud read role and app/API context |
+| Detection Risk | Low to Medium |
+| Primary Impact | Privileged function misuse or data access |
+
+## Prerequisites
+
+- Functions and triggers in scope.
+- Source/deployment pipeline review approved if available.
+- Test event source or staging function preferred.
+- Secret handling rules.
+
+## Workflow
+
+1. Inventory functions, triggers, runtime, and owners.
+2. Review execution roles and environment variables.
+3. Review event validation and input parsing.
+4. Review deployment permissions and CI/CD approval flow.
+5. Review dependencies and runtime patching.
+6. Model impact if the function or deployment role is abused.
+
+## Assessment Areas
+
+| Area | Checks |
+|---|---|
+| IAM | Execution role least privilege. |
+| Secrets | Environment variables, secret manager usage, rotation. |
+| Triggers | Public HTTP, queues, storage events, scheduled jobs. |
+| Input Validation | Schema checks and unsafe dynamic execution. |
+| CI/CD | Who can deploy, approve, rollback, and modify env vars. |
+| Observability | Logs, alerts, tracing, anomaly detection. |
+
+## MITRE ATT&CK Mapping
+
+| Phase | Tactic | Technique |
+|---|---|---|
+| Execution | Execution | Serverless Execution |
+| Credential Access | Credential Access | Unsecured Credentials |
+| Privilege | Privilege Escalation | Cloud Administration Command |
+
+## Evidence
+
+- Function list.
+- Role policy summary.
+- Trigger map.
+- Redacted environment variable names.
+- Pipeline permission screenshot.
+
+## Remediation
+
+- Minimize execution roles.
+- Move secrets to managed secret stores.
+- Validate event schemas.
+- Add deployment approvals.
+- Scan dependencies.
+- Alert on function updates and unusual invocations.
+