@aegis-scan/skills 0.1.1 → 0.2.1

package/skills/defensive/aegis-native/tenant-isolation-defense/SKILL.md

@@ -0,0 +1,225 @@
+<!-- aegis-local: AEGIS-native skill, MIT-licensed; mirrors @aegis-wizard/cli multi-tenant pattern + addresses AEGIS scanner finding: tenant-isolation-checker (CWE-639). -->
+
+---
+name: defensive-tenant-isolation
+description: "Multi-tenant SaaS isolation methodology. Covers tenant_id flow design, secureApiRouteWithTenant primitive usage, JWT-based tenant injection patterns, defense against IDOR + tenant-bypass, AEGIS tenant-isolation-checker remediation, public-route exception handling, and regression-test discipline. Use when designing multi-tenant Supabase or PostgreSQL applications, fixing tenant-isolation-checker findings, or auditing for cross-tenant data leakage."
+---
+
+# Tenant Isolation Defense — Multi-Tenant SaaS Methodology
+
+## When to use this skill
+
+- Designing a new multi-tenant SaaS — get the isolation invariant right from commit 0.
+- Reviewing an existing multi-tenant codebase for cross-tenant exposure.
+- Fixing AEGIS `tenant-isolation-checker` (CWE-639) findings.
+- Auditing IDOR-class findings (CWE-639 Insecure Direct Object Reference).
+- Hardening before a SOC 2 audit.
+
+## The core invariant
+
+**Every database query touching tenant-scoped data MUST filter by `tenant_id`, AND the `tenant_id` MUST come from the authenticated session — never from request input.**
+
+Two failure modes:
+
+1. **Missing filter** — query returns rows from all tenants. Catastrophic.
+2. **Filter sourced from request input** — attacker sends `?tenant_id=victim-tenant-uuid` and reads anyone's data. Equally catastrophic.
+
+## The secure pattern
+
+### Server-side primitive
+
+```typescript
+// lib/security/secureApiRouteWithTenant.ts (AEGIS scaffold ships this)
+
+import { createClient } from '@supabase/supabase-js';
+
+export async function secureApiRouteWithTenant<T>(
+  req: Request,
+  handler: (ctx: { supabase: SupabaseClient; userId: string; tenantId: string }) => Promise<T>
+): Promise<Response> {
+  const supabase = createClient(
+    process.env.NEXT_PUBLIC_SUPABASE_URL!,
+    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
+    { global: { headers: { Authorization: req.headers.get('Authorization') ?? '' } } }
+  );
+
+  const { data: { user }, error } = await supabase.auth.getUser();
+  if (error || !user) return new Response('Unauthorized', { status: 401 });
+
+  const { data: profile } = await supabase
+    .from('profiles')
+    .select('tenant_id')
+    .eq('id', user.id)
+    .single();
+
+  if (!profile?.tenant_id) {
+    return new Response('Forbidden', { status: 403 });
+  }
+
+  // tenant_id is always derived from the session, never from the request body
+  return handler({
+    supabase,
+    userId: user.id,
+    tenantId: profile.tenant_id,
+  });
+}
+```
+
+### Usage in API routes
+
+```typescript
+// app/api/invoices/route.ts
+
+export async function GET(req: Request) {
+  return secureApiRouteWithTenant(req, async ({ supabase, tenantId }) => {
+    const { data, error } = await supabase
+      .from('invoices')
+      .select('*')
+      .eq('tenant_id', tenantId);  // tenant_id from session, NOT from query params
+
+    if (error) return Response.json({ error }, { status: 500 });
+    return Response.json(data);
+  });
+}
+```
+
+## Anti-patterns the scanner flags
+
+### Anti-pattern 1 — Missing `tenant_id` filter
+
+```typescript
+// FLAGGED by tenant-isolation-checker (CWE-639)
+const { data } = await supabase
+  .from('invoices')
+  .select('*');  // returns ALL tenants' invoices — cross-tenant leak
+
+// FIX
+const { data } = await supabase
+  .from('invoices')
+  .select('*')
+  .eq('tenant_id', sessionTenantId);
+```
+
+### Anti-pattern 2 — `tenant_id` from request input
+
+```typescript
+// FLAGGED by tenant-isolation-checker (CWE-639)
+const { searchParams } = new URL(req.url);
+const tenantId = searchParams.get('tenant_id');
+const { data } = await supabase
+  .from('invoices')
+  .select('*')
+  .eq('tenant_id', tenantId);  // attacker sets ?tenant_id=victim — IDOR
+
+// FIX — always source tenant_id from session
+const { tenantId } = await getAuthenticatedSession(req);
+```
+
+### Anti-pattern 3 — `tenant_id` in mutation body
+
+```typescript
+// FLAGGED — mass-assignment + tenant-isolation
+const body = await req.json();
+await supabase.from('invoices').insert(body);  // body can carry attacker's tenant_id
+
+// FIX — strip tenant_id from input, inject from session
+const body = MutationSchema.parse(await req.json());
+await supabase.from('invoices').insert({
+  ...body,
+  tenant_id: sessionTenantId,  // session-sourced, overrides any body field
+});
+```
+
+## Public-route exceptions (rare, document each)
+
+A small set of routes legitimately operate without a tenant scope:
+
+- Auth/login endpoints (no tenant context exists yet at this point)
+- Public marketing pages (no DB read at all, ideally)
+- Health-check endpoints (no DB read)
+- Webhook receivers from trusted vendors (verified by signature, then dispatched into tenant-scoped logic)
+
+Document each exception explicitly:
+
+```typescript
+// app/api/auth/login/route.ts
+// AEGIS-EXCEPTION: tenant-isolation N/A — login endpoint runs before tenant context exists.
+// Verified safe via signed-cookie + supabase-auth-helpers; no direct DB writes here.
+export async function POST(req: Request) {
+  /* ... */
+}
+```
+
+The `aegis scan` config supports per-finding suppression with rationale; see `docs/suppressions.md`.
+
+## Multi-axis tenant scoping
+
+Some apps need MORE than `tenant_id` — for example, organizations within tenants, or divisions within organizations:
+
+```sql
+CREATE TABLE invoices (
+  id uuid PRIMARY KEY,
+  tenant_id uuid NOT NULL,        -- Customer org
+  organization_id uuid,            -- Sub-unit within the customer
+  user_id uuid NOT NULL,           -- Creator
+  -- ...
+);
+
+-- RLS policy enforces all three when applicable
+CREATE POLICY "tenant + org + user scoping"
+ON public.invoices FOR SELECT
+USING (
+  tenant_id IN (SELECT tenant_id FROM profiles WHERE id = auth.uid())
+  AND (organization_id IS NULL OR organization_id IN (
+    SELECT organization_id FROM organization_members WHERE user_id = auth.uid()
+  ))
+);
+```
+
+## Regression-test pattern
+
+```typescript
+// __tests__/tenant-isolation.test.ts
+describe('Tenant Isolation', () => {
+  it('user from tenant A cannot read tenant B documents', async () => {
+    await seedTenant('A', { documents: [{ id: 'a1' }] });
+    await seedTenant('B', { documents: [{ id: 'b1' }] });
+
+    const sessionA = await createSession('A');
+    const res = await fetch('/api/documents', {
+      headers: { Authorization: `Bearer ${sessionA.token}` },
+    });
+    const docs = await res.json();
+    expect(docs).toHaveLength(1);
+    expect(docs[0].id).toBe('a1');  // not b1
+  });
+
+  it('tenant_id in request body is ignored', async () => {
+    await seedTenant('A', {});
+    await seedTenant('B', { documents: [{ id: 'b1' }] });
+
+    const sessionA = await createSession('A');
+    const res = await fetch('/api/documents', {
+      method: 'POST',
+      headers: { Authorization: `Bearer ${sessionA.token}` },
+      body: JSON.stringify({ tenant_id: 'B', name: 'attack' }),  // attacker tries to set tenant
+    });
+    const created = await res.json();
+    expect(created.tenant_id).toBe('A');  // session-sourced wins
+  });
+});
+```
+
+Run this on every CI run. Tenant-isolation regressions silently leak data; you need a test that fails LOUDLY when the invariant breaks.
+
+## How AEGIS helps
+
+- `tenant-isolation-checker` (CWE-639) — flags Supabase queries missing `tenant_id` and queries where `tenant_id` is sourced from request input.
+- `mass-assignment-checker` (CWE-915) — flags unvalidated body → `.insert()`.
+- `aegis-wizard/cli` scaffold — ships `secureApiRouteWithTenant`, the `tenants` + `profiles` schema with the auto-profile-on-signup trigger, and an exemplary API route demonstrating the composition pattern.
+
+## See also
+
+- `defensive-rls-defense` skill — the RLS counterpart that complements API-route-level isolation.
+- AEGIS patterns library — `docs/patterns/index.md` § "Multi-tenant Supabase pattern".
+- AEGIS-finding suppression docs — `docs/suppressions.md`.

package/skills/mitre-mapped/README.md

@@ -1,10 +1,38 @@
-# MITRE-Mapped Skills
+# MITRE-Mapped Skills — `mitre-mapped/`
 
-Reserved for cherry-picked skills from an upstream cybersecurity
-framework-mapped skills source, with MITRE ATT&CK / D3FEND / NIST
-CSF mappings applied. Target: `skills-v0.2`.
+Skills that cross-walk AEGIS scanner findings to MITRE ATT&CK Enterprise,
+ATLAS (AI/ML threats), D3FEND (defensive countermeasures), NIST CSF 2.0,
+and NIST AI RMF. Use these to translate AEGIS reports into the MITRE
+language your SIEM / EDR / IR tooling already speaks.
 
-Per-skill quality-audit is required before integration. The upstream-
-source details and integration-matrix are tracked in the repository's
-internal planning tree; ask the maintainer for access if you are
-contributing to the framework-mapped-skills effort.
+## Sources
+
+| Source dir | License | Skills |
+|---|---|---|
+| `aegis-native/` | MIT (AEGIS-original) | 3 |
+
+## AEGIS-native skills
+
+| Skill | Coverage |
+|---|---|
+| `mapping-overview` | Top-level cross-walk: per-CWE → ATT&CK technique, plus tactic-level coverage summary. ATLAS overlay for AI/LLM threats. D3FEND defensive-countermeasure mapping. NIST CSF 2.0 + NIST AI RMF function-level alignment. |
+| `t1190-exploit-public-app` | Deep-dive on T1190 (Exploit Public-Facing Application) coverage — SQLi, XSS, SSRF, RCE, command-injection, file-upload, auth-bypass. |
+| `t1078-valid-accounts` | Deep-dive on T1078 (Valid Accounts) coverage — credential leakage detection, JWT-format detection, cloud-credential protection, T1078.001-004 sub-technique map. |
+
+License: MIT. See top-level [`ATTRIBUTION.md`](../../ATTRIBUTION.md) for
+attribution chain.
+
+## Roadmap
+
+Future expansions:
+
+- Per-tactic deep-dive skills for high-coverage tactics (Credential Access TA0006, Exfiltration TA0010, Privilege Escalation TA0004).
+- ATLAS-specific deep-dive on AML.T0051 (Direct + Indirect Prompt Injection).
+- D3FEND countermeasure-recommendation skill that turns AEGIS findings into specific D3FEND-technique recommendations.
+
+## See also
+
+- AEGIS scanner inventory in the top-level `README.md` — authoritative per-scanner CWE list.
+- MITRE ATT&CK — https://attack.mitre.org/
+- MITRE ATLAS — https://atlas.mitre.org/
+- MITRE D3FEND — https://d3fend.mitre.org/

package/skills/mitre-mapped/aegis-native/mapping-overview/SKILL.md

@@ -0,0 +1,129 @@
+<!-- aegis-local: AEGIS-native skill, MIT-licensed; cross-walks AEGIS scanner findings to MITRE ATT&CK Enterprise v15 (latest stable as of 2026-04-27). -->
+
+---
+name: mitre-mapping-overview
+description: "Top-level cross-walk between AEGIS scanner findings and MITRE ATT&CK Enterprise v15 techniques. Provides the per-finding-CWE → ATT&CK-technique mapping with rationale, plus per-tactic coverage summary. Use when integrating AEGIS findings into a MITRE-aligned threat-model, mapping AEGIS reports to D3FEND defensive countermeasures, building executive risk reports framed in MITRE language, or aligning AEGIS coverage with NIST CSF 2.0 / NIST AI RMF tagged controls."
+---
+
+# MITRE ATT&CK Mapping — AEGIS Scanner Findings
+
+## Why this matters
+
+Many security teams operate in MITRE-language. AEGIS findings are CWE-tagged; this skill translates them into ATT&CK techniques so AEGIS reports can be consumed alongside SIEM / EDR / IR-tool reports without manual re-mapping.
+
+**Mapping target:** MITRE ATT&CK Enterprise v15 (https://attack.mitre.org/).
+**Companion frameworks:** MITRE D3FEND v1.0 (defensive countermeasures), NIST CSF 2.0, NIST AI RMF.
+
+## Coverage summary by tactic
+
+ATT&CK has 14 tactics (TA0001..TA0040). AEGIS findings concentrate on a subset:
+
+| Tactic | ATT&CK ID | AEGIS coverage strength |
+|---|---|---|
+| Initial Access | TA0001 | High — SQLi/XSS/SSRF/RCE/auth-bypass |
+| Execution | TA0002 | Medium — eval injection, prompt injection, command injection |
+| Persistence | TA0003 | Low — most persistence is post-RCE; AEGIS's mass-assignment + auth findings prevent the entry point |
+| Privilege Escalation | TA0004 | Medium — RLS bypass, JWT misuse, role-escalation patterns |
+| Defense Evasion | TA0005 | Low — out of scope for static analysis |
+| Credential Access | TA0006 | High — entropy-scanner, jwt-detector, next-public-leak, crypto-auditor |
+| Discovery | TA0007 | Low — defensive scanner |
+| Lateral Movement | TA0008 | Out of scope — runtime-only |
+| Collection | TA0009 | Low — sensitive-data flagging via PII patterns |
+| Command and Control | TA0011 | Out of scope — runtime-only |
+| Exfiltration | TA0010 | Medium — SSRF, server-component data leak (CWE-200) |
+| Impact | TA0040 | Low — DoS findings (CWE-770, CWE-1333) |
+
+Out-of-scope tactics are intentionally not covered — AEGIS is a SAST + light DAST tool, not an EDR.
+
+## Per-CWE → ATT&CK mapping
+
+The complete mapping lives in the AEGIS scanner inventory; the high-leverage entries are:
+
+| AEGIS scanner | CWE | ATT&CK technique | ATT&CK ID |
+|---|---|---|---|
+| `taint-analyzer` (SQLi) | CWE-89 | Exploit Public-Facing Application | T1190 |
+| `template-sql-checker` | CWE-89 | Exploit Public-Facing Application | T1190 |
+| `sql-concat-checker` | CWE-89 | Exploit Public-Facing Application | T1190 |
+| `xss-checker` | CWE-79 | Drive-by Compromise (when stored XSS used as initial access) | T1189 |
+| `ssrf-checker` | CWE-918 | Cloud Metadata Discovery / Internal Service Discovery | T1552.005 / T1538 |
+| `path-traversal-checker` | CWE-22 | Exploit Public-Facing Application | T1190 |
+| `crypto-auditor` (eval injection) | CWE-94 | Command and Scripting Interpreter | T1059 |
+| `prompt-injection-checker` | CWE-77, CWE-1426 | Direct/Indirect Prompt Injection (ATLAS) | AML.T0051.000 / AML.T0051.001 |
+| `auth-enforcer` | CWE-285, CWE-306 | Valid Accounts | T1078 |
+| `middleware-auth-checker` | CWE-285 | Valid Accounts | T1078 |
+| `jwt-checker` | CWE-327, CWE-345 | Forge Web Credentials (Web Cookies / SAML / Tokens) | T1606 |
+| `jwt-detector` | CWE-798 | Valid Accounts (cloud accounts) | T1078.004 |
+| `next-public-leak` | CWE-200, CWE-798 | Unsecured Credentials (Credentials in Files) | T1552.001 |
+| `entropy-scanner` | CWE-798 | Unsecured Credentials | T1552 |
+| `tenant-isolation-checker` | CWE-639 | Authorization Bypass / IDOR | T1565 (Data Manipulation) when used for cross-tenant write; T1530 (Data from Cloud Storage) for read |
+| `rls-bypass-checker` | CWE-863 | Authorization Bypass | T1078 (Valid Accounts) when service_role escalates |
+| `rsc-data-checker` | CWE-200 | Sensitive Data Discovery / Exfiltration Over Web Service | T1530 / T1567 |
+| `mass-assignment-checker` | CWE-915 | Modify Authentication Process | T1556 |
+| `open-redirect-checker` | CWE-601 | Spearphishing Link | T1566.002 |
+| `cors-checker` | CWE-346 | Cross-Origin / Browser Session Hijack | T1539 |
+| `csrf-checker` | CWE-352 | Drive-by Compromise (CSRF as initial access) | T1189 |
+| `header-checker` | CWE-693 | Generic — defense-in-depth, maps to D3FEND DOM-ALL |
+| `cookie-checker` | CWE-614, CWE-1004 | Steal Web Session Cookie | T1539 |
+| `timing-safe-checker` | CWE-208 | Brute Force | T1110 |
+| `upload-validator` | CWE-434 | Exploitation for Privilege Escalation (file upload to RCE) | T1068 |
+
+## ATLAS — AI/ML threat model overlay
+
+For AI/LLM-touching findings, AEGIS also maps to MITRE ATLAS (Adversarial Threat Landscape for AI Systems):
+
+| AEGIS scanner | ATLAS technique | ATLAS ID |
+|---|---|---|
+| `prompt-injection-checker` (direct) | LLM Prompt Injection: Direct | AML.T0051.000 |
+| `prompt-injection-checker` (indirect) | LLM Prompt Injection: Indirect | AML.T0051.001 |
+| `prompt-injection-checker` (system prompt extraction) | Retrieve Sensitive ML Capabilities | AML.T0019 |
+
+ATLAS is the AI-specific companion to ATT&CK. For LLM apps, both maps are relevant simultaneously.
+
+## D3FEND — defensive countermeasure mapping
+
+D3FEND is MITRE's defensive countermeasure ontology. AEGIS findings naturally map to D3FEND techniques the scanner is enforcing:
+
+| AEGIS scanner | D3FEND technique | What the scanner enforces |
+|---|---|---|
+| `ssrf-checker` | Outbound Traffic Filtering | D3-OTF |
+| `crypto-auditor` | Strong Password Policy / Cryptographic Authentication | D3-SPP / D3-CA |
+| `csrf-checker` | Authentication Cache Invalidation / Session Token | D3-ACI |
+| `header-checker` | Domain Account Monitoring (via CSP/HSTS) | D3-DAM |
+| `auth-enforcer` | Process Self-Modification Detection | D3-PSMD |
+| `tenant-isolation-checker` | Resource Access Pattern Analysis | D3-RAPA |
+| `rate-limit-checker` | Inbound Traffic Filtering | D3-ITF |
+
+## NIST CSF 2.0 — high-level alignment
+
+NIST CSF 2.0 organizes around 6 functions: Govern, Identify, Protect, Detect, Respond, Recover. AEGIS contributes primarily to:
+
+- **Identify (ID)** — `supply-chain`, `dep-confusion-checker`, `getAllScanners()` registry, scanner-coverage README all support asset-management + threat-identification.
+- **Protect (PR)** — every defensive scanner contributes (auth, crypto, headers, cookies, CSP, CSRF, SSRF, RLS, etc.).
+- **Detect (DE)** — `[LOW-CONFIDENCE]` PR badge + per-finding confidence-rules support detection-of-detection-gaps.
+- **Respond (RS)** — out of scope (runtime-only).
+- **Recover (RC)** — out of scope.
+- **Govern (GV)** — the OWASP-APTS conformance posture (`docs/compliance/owasp-apts/`) directly contributes to GV.PO (Policy) and GV.OV (Oversight).
+
+## NIST AI RMF — AI/LLM-specific alignment
+
+For LLM-touching code, AEGIS contributes to NIST AI RMF Map / Measure / Manage functions:
+
+- **Map** — `prompt-injection-checker` identifies AI risk surface.
+- **Measure** — confidence-scoring on AI-related findings; FP rate disclosure.
+- **Manage** — `aegis fix` provides a remediation workflow for AI-related findings.
+
+## How to use this mapping
+
+1. **For executive reports** — translate each AEGIS finding's CWE to its ATT&CK technique using the per-CWE table; group by tactic for a "what the attacker could do with what we ship" narrative.
+2. **For threat models** — overlay AEGIS scanner coverage onto your team's threat model. Gaps in tactics (TA0008 lateral movement, TA0011 C2) need other tools (EDR, SIEM, network).
+3. **For compliance crosswalk** — when an auditor asks "what NIST CSF controls does this tool implement?", point to the function-level alignment above.
+4. **For SOC integration** — if your SIEM ingests SARIF, the SARIF emitter already includes the CWE; configure the SIEM to tag inbound findings with the corresponding ATT&CK technique using this mapping table.
+
+## See also
+
+- `mitre-t1190-exploit-public-app` skill — deep-dive on T1190 coverage.
+- `mitre-t1078-valid-accounts` skill — deep-dive on T1078 coverage.
+- AEGIS scanner inventory in `README.md` — authoritative per-scanner CWE list.
+- MITRE ATT&CK — https://attack.mitre.org/
+- MITRE ATLAS — https://atlas.mitre.org/
+- MITRE D3FEND — https://d3fend.mitre.org/

package/skills/mitre-mapped/aegis-native/t1078-valid-accounts/SKILL.md

@@ -0,0 +1,136 @@
+<!-- aegis-local: AEGIS-native skill, MIT-licensed; deep-dive on MITRE ATT&CK T1078 (Valid Accounts) coverage in AEGIS. -->
+
+---
+name: mitre-t1078-valid-accounts
+description: "MITRE ATT&CK T1078 (Valid Accounts) — deep-dive coverage map for AEGIS credential-protection scanner family. T1078 is one of the most consistently top-3 Initial Access techniques (Verizon DBIR multi-year). Covers stolen credentials, weak credentials, default accounts, cloud-IAM credentials, and JWT-format credentials. Use when responding to T1078 alerts, building credential-coverage reports, or determining which AEGIS scanners speak to a specific T1078 sub-technique."
+---
+
+# T1078 — Valid Accounts
+
+## Why T1078 matters
+
+ATT&CK technique T1078 captures any compromise where the attacker uses credentials they obtained (stolen, leaked, default, weak). Sub-techniques cover Default (T1078.001), Domain (T1078.002), Local (T1078.003), and Cloud (T1078.004) accounts.
+
+T1078 is consistently top-3 in Verizon DBIR. Credential-leak via source-code is among the most common entry-points; AEGIS's credential-protection scanner family is purpose-built for this.
+
+## AEGIS coverage map — credential-protection scanner family
+
+AEGIS ships four scanners that detect credentials at code-review time, plus the `safeFetch` SSRF defense that protects cloud-metadata-IMDSv2-credential-theft adjacent paths.
+
+### entropy-scanner (CWE-798)
+
+Shannon-entropy-based detection of high-entropy strings in source code. Catches credentials that don't match a known format (e.g., random API tokens, custom secret formats).
+
+- **What it catches:** any string with entropy > threshold (configurable).
+- **What it misses:** low-entropy credentials (passwords like `Password123!`), structured credentials that look "normal" (e.g., a UUID-shaped token).
+- **Sister scanners:** `gitleaks` (external wrapper) covers known-format credentials; `trufflehog` (external) covers verified-credential validation.
+
+### jwt-detector (CWE-798)
+
+Detects literal JWT tokens (`eyJ...` strings) hardcoded in source. Catches:
+
+- Service-role tokens shipped in source.
+- Demo / development tokens accidentally committed.
+- Tokens copy-pasted into code as hard-coded auth.
+
+Comment-aware via `stripComments` — excluded from doc strings and inline `// example: eyJ...` comments to avoid false positives on documentation.
+
+### next-public-leak (CWE-200, CWE-798)
+
+Specialty scanner for Next.js — catches:
+
+- Secrets accidentally prefixed `NEXT_PUBLIC_*` (which Next.js bundles into client code).
+- Server-only env vars read in `'use client'` files (which leaks the value to the bundle).
+
+This is a Next.js-specific T1078.004 (Cloud Accounts) protection because cloud credentials prefixed `NEXT_PUBLIC_` end up in every browser session of every user.
+
+### crypto-auditor (CWE-326, CWE-327, CWE-338, CWE-798)
+
+Detects:
+
+- Weak hash algorithms (MD5, SHA-1) used for security purposes (not just checksumming).
+- Insecure RNG (`Math.random()` for security tokens — biased + predictable).
+- Hardcoded secret literals (a separate detection path from entropy-scanner; catches structured-format secrets).
+- `eval()` injection (CWE-94, adjacent to T1059 but listed here because crypto-auditor is the scanner).
+
+## T1078 sub-technique coverage
+
+### T1078.001 — Default Accounts
+
+| Vector | AEGIS scanner | Strength |
+|---|---|---|
+| Default credentials shipped in source | `entropy-scanner`, `crypto-auditor` | medium (depends on default value entropy) |
+| Default-admin route without auth gate | `auth-enforcer` (CWE-285, CWE-306) | strict |
+
+### T1078.002 — Domain Accounts
+
+Out of scope for SAST — domain accounts are an Active-Directory-runtime concern.
+
+### T1078.003 — Local Accounts
+
+Partially in scope:
+
+| Vector | AEGIS scanner | Strength |
+|---|---|---|
+| Hardcoded local-account password in source | `entropy-scanner`, `crypto-auditor` | strict-when-entropy-high |
+| Service-role-key (Supabase) in source | `next-public-leak`, `entropy-scanner`, `jwt-detector` | strict (multi-layer) |
+
+### T1078.004 — Cloud Accounts
+
+Highest-leverage AEGIS coverage:
+
+| Vector | AEGIS scanner | Strength |
+|---|---|---|
+| AWS access key in source | `entropy-scanner` (AKIA prefix detection) | strict |
+| GCP service-account JSON in source | `entropy-scanner`, `gitleaks` (external) | strict |
+| Anthropic / OpenAI API keys in source | `entropy-scanner`, `crypto-auditor` | strict |
+| Cloud-metadata-IMDS-credential exfil via SSRF | `ssrf-checker` (cloud-metadata IP block-rules) | strict |
+| `NEXT_PUBLIC_` cloud-secret leak | `next-public-leak` | strict (Next.js-specific) |
+
+## What T1078 patterns AEGIS does NOT cover
+
+- **Credential stuffing detection** — runtime concern; no SAST coverage.
+- **Brute-force detection** — runtime concern (rate-limit-checker covers the *prevention* side: missing rate-limit on auth endpoints).
+- **MFA-fatigue / push-bombing** — runtime-only.
+- **Compromised-credential-database lookup** — needs a real-time API like HaveIBeenPwned; out of scope for SAST.
+
+For these, integrate AEGIS findings with your SIEM / EDR / IdP.
+
+## Defensive playbook (T1078 prevention)
+
+### Source-code-side (AEGIS does this)
+
+1. Run `aegis scan .` in CI; fix every `entropy-scanner`, `jwt-detector`, `next-public-leak`, `crypto-auditor` BLOCKER finding.
+2. Wire `gitleaks` (external wrapper) for known-format-credentials coverage.
+3. Wire `trufflehog` (external wrapper) for verified-credential validation.
+4. Pin pre-commit hooks (`.husky/pre-push` runs `aegis scan --fail-on-blocker`).
+
+### Operational-side (out of AEGIS scope)
+
+1. Use a secret manager (Vault, 1Password, AWS Secrets Manager). Never `.env` files in production.
+2. Rotate credentials on a schedule; rotate immediately on any credential-related finding.
+3. Enable MFA on every cloud-IAM root account.
+4. Use short-lived credentials (AWS STS, GCP service account impersonation) wherever possible.
+5. Audit IAM roles quarterly — least-privilege is a journey, not a one-shot.
+
+### Detection-side (out of AEGIS scope)
+
+1. SIEM rules for impossible-travel logins.
+2. EDR rules for service-account login from unexpected sources.
+3. Cloud-provider GuardDuty / Security Hub findings for anomalous IAM use.
+
+## Response runbook (post-credential-leak)
+
+1. **Rotate immediately** — every credential pattern AEGIS flags is potentially compromised; assume worst case.
+2. **Audit usage logs** — for each rotated credential, pull the access log for the leak window.
+3. **Identify reach** — for each authenticated session, what data / actions did it touch?
+4. **Notify** — GDPR Art. 33 if PII reached; SEC-rule disclosures if material; vendor contracts if vendor-credentials.
+5. **Patch** — remove the credential from source; replace with secret-manager reference.
+6. **Post-incident review** — was there a control gap? Should AEGIS scanner sensitivity be tuned? Should pre-commit hooks be tightened?
+
+## See also
+
+- `mitre-mapping-overview` skill — top-level scanner-to-technique mapping.
+- `defensive-rls-defense` — Supabase service-role-key safety.
+- AEGIS scaffold's `lib/security/secureApiRouteWithTenant` primitive — wires session-sourced authentication automatically.
+- MITRE ATT&CK T1078 — https://attack.mitre.org/techniques/T1078/

package/skills/mitre-mapped/aegis-native/t1190-exploit-public-app/SKILL.md

@@ -0,0 +1,108 @@
+<!-- aegis-local: AEGIS-native skill, MIT-licensed; deep-dive on MITRE ATT&CK T1190 (Exploit Public-Facing Application) coverage in AEGIS. -->
+
+---
+name: mitre-t1190-exploit-public-app
+description: "MITRE ATT&CK T1190 (Exploit Public-Facing Application) — deep-dive coverage map for AEGIS scanners. T1190 is the most common Initial Access pattern (Verizon DBIR 2024 #1). Covers SQL injection, XSS, SSRF, command injection, deserialization, and authentication bypass. Use when responding to T1190 alerts, building T1190-coverage reports, or determining which AEGIS scanners speak to a specific T1190 sub-pattern."
+---
+
+# T1190 — Exploit Public-Facing Application
+
+## Why T1190 matters
+
+ATT&CK technique T1190 is the **#1 Initial Access vector** in Verizon DBIR 2024. It captures any vulnerability in an internet-facing application that lets an attacker execute code, read data, or pivot. Covered sub-patterns include SQL injection, XSS leading to session hijack, SSRF reaching internal services, RCE via deserialization, command injection, file-upload exploits, and auth-bypass.
+
+A defense in depth program that doesn't have strong T1190 coverage is incomplete by definition.
+
+## AEGIS coverage map
+
+AEGIS contributes the following defensive scanners to T1190 coverage:
+
+### SQL injection — taint-analyzer + template-sql-checker + sql-concat-checker
+
+| Vector | AEGIS scanner | Strength |
+|---|---|---|
+| Same-file taint (request → template → query) | `taint-analyzer` | strict-30/30 benchmark |
+| Cross-file taint | `taint-analyzer` | medium-confidence |
+| Template-literal SQL via `.rpc()` / `.execute()` / `.query()` / `.$queryRawUnsafe()` | `template-sql-checker` | strict |
+| String concatenation SQL | `sql-concat-checker` | strict |
+
+**T1190 sub-pattern coverage:** error-based, UNION-based, blind, second-order — all covered at the taint-source-to-sink level. AEGIS doesn't generate live SQL payloads (that's siege-mode + Strix/PTAI). It catches the vulnerable pattern at code-review time.
+
+### XSS — xss-checker + taint-analyzer
+
+| Vector | AEGIS scanner | Notes |
+|---|---|---|
+| Reflected (response includes user input) | `xss-checker`, `taint-analyzer` | per-CWE: `DOMPurify.sanitize()` recognized as sanitizer; `parseInt()`, `encodeURIComponent()` partial-recognized per context |
+| Stored XSS (DB writes user content used in HTML) | `xss-checker`, `taint-analyzer` | mass-assignment + render-without-sanitizer pattern |
+| DOM-based XSS | `xss-checker` (lints `innerHTML` + `dangerouslySetInnerHTML`) | partial |
+
+### SSRF — ssrf-checker + taint-analyzer
+
+| Vector | AEGIS scanner | Notes |
+|---|---|---|
+| Direct fetch from user input | `ssrf-checker`, `taint-analyzer` | RFC 1918 / link-local literal recognition; `isForbiddenIP` helper recognition |
+| URL-position-only check | `ssrf-checker` | only the first arg of `fetch(url, …)` counts; tainted values in headers/body do not |
+| Library-wrapper hoisting | `ssrf-checker` (Z4 heuristic) | exported fetch-wrappers where the URL is a parameter no longer emit at the wrapper site |
+| DNS rebinding | not detected by SAST | requires runtime defense (`safeFetch` with pinned IP) — see `defensive-ssrf` skill |
+
+### Command injection — crypto-auditor (eval injection) + cli `getChangedFiles` hardening
+
+| Vector | AEGIS scanner | Notes |
+|---|---|---|
+| `eval(userInput)`, `Function(userInput)()` | `crypto-auditor` (CWE-94) | strict |
+| Shell injection via `execSync(template-literal)` | `taint-analyzer` (CWE-78) | strict via sink-list |
+| Prompt-injection-as-cmd-injection (LLM tool-use) | `prompt-injection-checker` (CWE-77, CWE-1426) | ATLAS-aligned |
+
+### File-upload exploits — upload-validator
+
+`upload-validator` flags uploads without magic-byte validation (CWE-434), which is the entry-point for path-traversal-via-filename, executable-upload-then-execute, and content-type confusion attacks.
+
+### Authentication bypass — auth-enforcer + middleware-auth-checker + jwt-checker
+
+| Vector | AEGIS scanner | Notes |
+|---|---|---|
+| Missing auth guard on API route | `auth-enforcer` (CWE-285, CWE-306) | per-route detection |
+| RBAC gap | `auth-enforcer` (CWE-285) | role-check pattern detection |
+| Next.js middleware auth-bypass (CVE-2025-29927) | `middleware-auth-checker` (CWE-285) | `x-middleware-subrequest` header pattern |
+| JWT 'none' algorithm | `jwt-checker` (CWE-327) | strict |
+| JWT weak signing | `jwt-checker` (CWE-345) | partial |
+
+### Server-Component data-leak — rsc-data-checker
+
+CWE-200 — Server Components passing full DB records to client. T1190-adjacent because the leaked data may include credentials or session tokens that enable downstream compromise.
+
+## What T1190 sub-patterns AEGIS does NOT cover
+
+- **Deserialization (CWE-502)** — AEGIS has no `deserialization-checker` today; this is a known gap. The Strix/PTAI/Pentest-Swarm-AI wrappers cover it via their own DAST testing during siege-mode.
+- **XML External Entity (XXE)** — same as above, runtime-only via wrappers.
+- **Server-Side Template Injection (SSTI)** — same as above.
+- **HTTP Request Smuggling** — runtime-only via wrappers.
+
+These gaps are documented in `README.md` § "Honest limitations" and in the `@aegis-scan/skills` offensive-skills library (`offensive/snailsploit-fork/{deserialization,xxe,ssti,request-smuggling}/SKILL.md`) so red-team agents know to test these classes manually.
+
+## Detection-side — how to know you're under T1190 attack
+
+ATT&CK technique procedures cite these detection signals, which your SIEM should already be ingesting:
+
+- WAF logs flagging known SQLi/XSS/SSRF payloads.
+- Anomalous outbound connections from server-side processes (SSRF reach indicator).
+- 5xx error spikes correlated with specific input patterns (probing).
+- New process spawns from web-server contexts (RCE indicator).
+- `npm install` / `pip install` events on production hosts (post-RCE persistence).
+
+AEGIS doesn't run at runtime; SIEM/EDR/WAF do. AEGIS prevents the vulnerable code from shipping in the first place — preventive, not detective.
+
+## Response runbook (post-T1190 detection)
+
+1. **Containment** — block the offending source IP at the WAF / load balancer.
+2. **Forensics** — pull the request log for the affected window; identify the specific endpoint that was exploited.
+3. **AEGIS finding cross-reference** — run `aegis history . --blame` filtered to the affected file/path; identify whether AEGIS had previously flagged this endpoint.
+4. **Patch** — depending on the sub-pattern, follow `defensive-ssrf` / `defensive-rls-defense` / `defensive-tenant-isolation` skills.
+5. **Post-incident** — file a regression test that the patched endpoint cannot be re-exploited; add to AEGIS canary fixtures if the sub-pattern was novel.
+
+## See also
+
+- `mitre-mapping-overview` skill — top-level scanner-to-technique mapping.
+- `defensive-ssrf` / `defensive-rls-defense` / `defensive-tenant-isolation` — defensive playbooks.
+- AEGIS taint-analyzer engine — `README.md` § "Taint Analysis Engine".
+- MITRE ATT&CK T1190 — https://attack.mitre.org/techniques/T1190/