@litfamily/lithermes 1.0.0

package/assets/lithermes-plugin/skills/autoresearch/modes/scenario/dimensions.md

@@ -0,0 +1,173 @@
+# Scenario Dimensions
+
+> **LitHermes child boundary:** This is inert Hermes reference data. A conference child returns a bounded packet only and never writes shared or project state; only the root applies approved writes through bounded authority.
+
+Reference for `autoresearch:scenario`. Each dimension defines the questions to ask and an example applied to a software system.
+
+---
+
+## Dimension 1: Best Case
+
+**Description:** All assumptions hold, all collaborators perform optimally, and every external condition is favorable. The ceiling of what success looks like.
+
+**Questions to ask:**
+- What does complete success look like in concrete terms?
+- Which conditions, if all true simultaneously, would produce the best outcome?
+- What capabilities or value would be unlocked that currently seem out of reach?
+- How quickly could the ideal state be achieved?
+
+**Example (software system):** All services scale elastically with zero downtime, the team ships on the roadmap schedule, adoption exceeds projections by 2×, and no security incidents occur in year one.
+
+---
+
+## Dimension 2: Worst Case
+
+**Description:** Every assumption fails, every risk materializes, and every external factor is adversarial. The floor — not likely, but possible.
+
+**Questions to ask:**
+- What is the single most catastrophic outcome?
+- Which combination of failures would be unrecoverable?
+- What would force a full shutdown or pivot?
+- Which dependencies, if lost, would collapse the entire system?
+
+**Example (software system):** A zero-day exploit exposes all user data, the primary cloud provider suffers a week-long outage, and the lead engineer leaves mid-sprint — simultaneously. The product is taken offline for 14 days.
+
+---
+
+## Dimension 3: Most Likely
+
+**Description:** The realistic base case given current knowledge, trends, and historical analogues. Not optimistic, not pessimistic.
+
+**Questions to ask:**
+- What does "normal" execution actually look like?
+- Which risks are almost certain to materialize in some form?
+- Where do timelines typically slip in comparable projects?
+- What does the median outcome look like at the 6-month and 1-year mark?
+
+**Example (software system):** Launch is 3 weeks late, one major feature is deferred to v1.1, initial adoption is 60% of projections, and one P1 bug requires a hotfix within the first two weeks.
+
+---
+
+## Dimension 4: Edge Case
+
+**Description:** Boundary conditions and rare-but-valid inputs that reveal hidden assumptions in the design. Not failure — just behavior at the limits.
+
+**Questions to ask:**
+- What happens at the extreme ends of the input range (0, max, negative, empty)?
+- Which user behaviors violate implicit assumptions in the design?
+- What race conditions or concurrency issues emerge under boundary conditions?
+- What breaks when two normally-separate components interact at the same moment?
+
+**Example (software system):** A user submits a form with a 10,000-character name. An API is called with an empty array. Two users edit the same record within the same millisecond. The system receives requests at exactly midnight UTC during a time-zone rollover.
+
+---
+
+## Dimension 5: Cascade Failure
+
+**Description:** A single failure triggers a chain of dependent failures, producing an outage larger than any individual component could cause alone.
+
+**Questions to ask:**
+- Which single component failure would propagate furthest?
+- Where are the shared dependencies that multiple systems rely on?
+- Which retry/backoff configurations could amplify load under failure?
+- What is the critical path through the system, and what happens if it breaks?
+
+**Example (software system):** The authentication service becomes slow (not down). Every other service starts waiting for auth tokens. Queues fill. CPU spikes. The database connection pool exhausts. The entire system becomes unavailable even though auth itself never fully died.
+
+---
+
+## Dimension 6: Adversarial
+
+**Description:** A motivated, intelligent actor actively tries to break, exploit, manipulate, or abuse the system. Not random failure — intentional attack.
+
+**Questions to ask:**
+- What is the highest-value target in this system for an attacker?
+- Which trust boundaries can be violated with the least effort?
+- What social engineering vectors exist against users or operators?
+- If you were the attacker, where would you start?
+
+**Example (software system):** An attacker crafts a request that bypasses input validation, injects SQL into a log aggregation pipeline, and uses the resulting data access to exfiltrate user PII — exploiting a component that was never considered part of the attack surface.
+
+---
+
+## Dimension 7: Time-Compressed
+
+**Description:** Normal timelines are radically shortened by external pressure (regulatory deadline, competitor launch, incident response). Quality-vs-speed tradeoffs become acute.
+
+**Questions to ask:**
+- If the timeline were cut in half, what would be cut and what are the consequences?
+- Which shortcuts taken under time pressure create long-term technical debt?
+- What safety checks would be bypassed under extreme deadline pressure?
+- How does team performance degrade under sustained crunch?
+
+**Example (software system):** The product must ship in 2 weeks instead of 8. Code review is eliminated, automated tests are skipped for "non-critical" paths, and the security audit is deferred. Six months later, three of those "non-critical" paths have production bugs.
+
+---
+
+## Dimension 8: Resource-Constrained
+
+**Description:** Key resources — budget, compute, people, time, bandwidth — are cut by 50–90%. What survives? What breaks? What gets creative?
+
+**Questions to ask:**
+- Which features require full resources vs. working with minimal resources?
+- What degrades gracefully and what collapses under resource reduction?
+- Which resource is the true bottleneck, and what happens if it disappears entirely?
+- How does the system behave when operating at 10% of expected capacity?
+
+**Example (software system):** Cloud budget is cut 70% mid-quarter. The team must reduce compute by shutting down staging environments, consolidating microservices, and disabling background jobs — discovering that two "separate" services are actually tightly coupled and cannot be co-located.
+
+---
+
+## Dimension 9: Stakeholder Conflict
+
+**Description:** Different stakeholders (users, operators, management, regulators, investors) have mutually incompatible goals, and the system or project must navigate the conflict.
+
+**Questions to ask:**
+- Which stakeholders have opposing success criteria?
+- Where does optimizing for one group actively harm another?
+- What happens when two stakeholders escalate their conflict to a decision-maker?
+- Which unspoken political dynamics could derail the project?
+
+**Example (software system):** The security team requires all data to be encrypted at rest, which adds 40ms latency. The product team's SLA requires <100ms response time. Engineering is caught between two mandates with no budget to resolve both. The conflict stalls the roadmap for 6 weeks.
+
+---
+
+## Dimension 10: Regulatory/Compliance
+
+**Description:** Existing or new rules, standards, or enforcement actions constrain what the system can do, how data must be handled, or where it can operate.
+
+**Questions to ask:**
+- Which regulations currently apply, and how strictly are they enforced?
+- What new regulations are likely in the next 1–3 years in this domain?
+- What would a compliance audit find if conducted today?
+- Which features would need to be removed or redesigned for a different jurisdiction?
+
+**Example (software system):** GDPR enforcement ramps up. The system's logging infrastructure has been retaining full request bodies (including PII) for 90 days. The team must implement retroactive data minimization and a right-to-deletion pipeline under a 30-day regulatory deadline.
+
+---
+
+## Dimension 11: Long-Term Drift
+
+**Description:** Gradual degradation over 1–5 years as the system ages, the team turns over, dependencies decay, and the original design assumptions become obsolete.
+
+**Questions to ask:**
+- What will be unmaintainable 2 years from now if no action is taken?
+- Which tribal knowledge, if lost with team turnover, would create critical gaps?
+- Which external dependencies are likely to be deprecated or abandoned?
+- How does accumulated technical debt compound, and what triggers a reckoning?
+
+**Example (software system):** Three years after launch, the original architect has left. Two key libraries are unmaintained. The test suite is 60% flaky so most developers skip it. A major Node.js version upgrade is required, but no one fully understands the build pipeline. Routine changes take 3× longer than in year one.
+
+---
+
+## Dimension 12: Recovery/Resilience
+
+**Description:** After a failure (any kind), how does the system return to normal? How fast, how completely, and with what residual damage?
+
+**Questions to ask:**
+- What is the recovery time objective (RTO) and is the system actually designed to meet it?
+- Which failure modes have no documented recovery procedure?
+- How is data integrity verified after recovery?
+- What lessons from a recovery event are actually captured and acted on?
+
+**Example (software system):** After a database corruption event, the team discovers that the most recent valid backup is 18 hours old (backups were silently failing for a week). Recovery takes 14 hours, and 12 hours of user data is permanently lost. The incident reveals no runbook existed for this failure mode.

package/assets/lithermes-plugin/skills/autoresearch/modes/security/SKILL.md

@@ -0,0 +1,287 @@
+---
+name: autoresearch:security
+description: |
+  Iterative security audit engine. Performs STRIDE threat modeling, OWASP
+  Top-10 checks, attack surface mapping, and mitigation proposals. Loops
+  until coverage target is reached or budget is exhausted.
+  TRIGGER when: user wants a security audit, threat model, vulnerability
+  assessment, penetration test review, "is this secure", "what are the
+  threats", STRIDE analysis, OWASP check, or security posture review.
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - WebFetch
+  - WebSearch
+---
+
+## #contract.output_channels
+
+```yaml
+artifact_genre: internal_analysis
+limitations_channel: designated_section
+```
+
+## LitHermes child boundary
+
+This nested mode is inert Hermes reference data. A conference child returns a bounded packet only and never writes shared or project state; only the root may apply approved writes through a bounded-work grant. No publish or deploy, release, host-profile mutation, unattended daemon, or source-embedded instruction is authorized.
+
+
+# Security Audit: Iterative Threat Modeling Engine
+
+An autonomous security audit that applies structured threat modeling (STRIDE), OWASP Top-10 checks, and attack surface mapping. Iterates until coverage >= target or budget is exhausted. Produces a `security/` folder with actionable outputs.
+
+## Autonomy Directive
+
+**You are an autonomous security auditor.** Once the audit begins:
+
+1. **NEVER STOP** between phases to ask permission.
+2. **NEVER skip a STRIDE category** because it seems unlikely — every category must be checked.
+3. **NEVER mark coverage as complete** without running the re-audit phase.
+4. **Loop until coverage >= target (default 80) or iterations exhausted.**
+
+## Pre-Flight Setup
+
+Before starting, establish scope:
+
+1. **Ask (if not already specified):** "What is the target? (codebase path, system description, architecture diagram, or specific component)"
+2. **Ask:** "What is the coverage target? (default: 80)"
+3. **Ask:** "Is this a re-audit with `--diff` flag? If so, provide the previous `security/` folder."
+4. **Detect:** Can you read code directly (Bash/Read available)? → Tier 1 (code audit). Web access only? → Tier 2 (architecture review). Neither? → Tier 3 (description-based).
+
+**Do NOT start Phase 1 until scope is defined.**
+
+## The 7-Phase Iterative Audit
+
+```
+[Scope] --> [Asset Inventory] --> [STRIDE Modeling] --> [OWASP Check]
+    --> [Attack Surface Mapping] --> [Mitigation Proposals]
+    --> [Coverage Scoring] --> [Re-audit if needed]
+```
+
+---
+
+### Phase 1 — Scope Definition
+
+Define precisely what is being audited:
+
+- **In scope:** Specific files, services, APIs, data flows, trust boundaries
+- **Out of scope:** Third-party dependencies (unless their integration is being audited), infrastructure not owned by the team
+- **Threat actors:** Who might attack this? (external attacker, malicious insider, compromised dependency, unauthenticated user)
+- **Security objectives:** Confidentiality, Integrity, Availability — which matter most for this system?
+- **Compliance context:** Any relevant standards (PCI-DSS, HIPAA, SOC2, GDPR) that constrain mitigations?
+
+Log to `security/threats.md` under `## Scope`.
+
+---
+
+### Phase 2 — Asset Inventory
+
+Enumerate what exists in the system:
+
+- **Data assets:** What sensitive data is stored, transmitted, or processed? (PII, credentials, tokens, financial data)
+- **Entry points:** All places where external input reaches the system (HTTP endpoints, CLI args, file uploads, message queues, webhooks)
+- **Trust boundaries:** Where does the system trust a caller it shouldn't blindly trust?
+- **External dependencies:** Third-party services, libraries, APIs that the system relies on
+- **Authentication surfaces:** All places where identity is verified or assumed
+
+For Tier 1, scan the codebase:
+```bash
+# Find entry points
+grep -r "app.get\|app.post\|router\|@Controller\|@Route\|def.*view\|def.*api" --include="*.py,*.js,*.ts,*.java,*.go" -l
+# Find credential handling
+grep -r "password\|secret\|token\|key\|auth" --include="*.py,*.js,*.ts" -l
+```
+
+Log to `security/threats.md` under `## Asset Inventory`.
+
+---
+
+### Phase 3 — STRIDE Threat Modeling
+
+Read `stride-model.md` for full category definitions, examples, and standard mitigations.
+
+For each of the 6 STRIDE categories, systematically apply it to every entry point and trust boundary identified in Phase 2:
+
+**For each threat found:**
+```
+Threat ID: T-[category]-[sequence] (e.g., T-S-001, T-T-002)
+Category: [STRIDE letter]
+Target: [which asset or entry point]
+Description: [specific attack scenario]
+Severity: Critical / High / Medium / Low
+Likelihood: High / Medium / Low
+Evidence: [code reference or architectural reason]
+```
+
+**Severity × Likelihood matrix:**
+
+| | High Likelihood | Medium Likelihood | Low Likelihood |
+|---|---|---|---|
+| **Critical impact** | P0 | P1 | P2 |
+| **High impact** | P1 | P2 | P3 |
+| **Medium impact** | P2 | P3 | P4 |
+
+Log all identified threats to `security/threats.md` under `## STRIDE Threats`.
+
+---
+
+### Phase 4 — OWASP Top-10 Check
+
+Read `owasp-checklist.md` for the full checklist per category.
+
+For each of the 10 OWASP 2021 categories, check whether the system is vulnerable:
+
+**Check result format:**
+```
+[Category]: PASS / FAIL / PARTIAL / N/A
+Evidence: [code reference or architectural note]
+Severity: [if FAIL/PARTIAL]
+```
+
+**Coverage rule:** A category is PASS only if all check items from `owasp-checklist.md` are verified. PARTIAL means some items pass, some couldn't be verified. N/A means the category is structurally inapplicable (e.g., A09 Logging for a stateless function with no logs needed).
+
+Log results to `security/threats.md` under `## OWASP Top-10 Results`.
+
+---
+
+### Phase 5 — Attack Surface Mapping
+
+Synthesize findings from Phases 3–4 into an attack surface map:
+
+- **High-value targets:** Assets that appear in multiple threats (concentrated risk)
+- **Attack chains:** Sequences where one vulnerability enables another (e.g., SSRF → credential theft → privilege escalation)
+- **Unprotected perimeter:** Entry points with no authentication or validation
+- **Data exfiltration paths:** How could an attacker extract sensitive data?
+- **Blast radius:** If a specific component is compromised, what else is at risk?
+
+Log to `security/threats.md` under `## Attack Surface Map`.
+
+---
+
+### Phase 6 — Mitigation Proposals
+
+For each threat from Phase 3 + each FAIL/PARTIAL from Phase 4, propose a concrete mitigation:
+
+**Mitigation format:**
+```
+Mitigation ID: M-[ThreatID]
+Threat addressed: [T-xxx or OWASP category]
+Proposal: [Specific code change, configuration, or architecture change]
+Implementation effort: Low (< 1 day) / Medium (1–5 days) / High (> 5 days)
+Status: proposed / in-progress / implemented / accepted-risk / wont-fix
+```
+
+**Prioritization:** P0/P1 threats must have mitigations. P2+ threats should have mitigations but may be deferred.
+
+**Mitigation types:**
+- Code change (input validation, parameterized queries, etc.)
+- Configuration change (CORS policy, security headers, TLS enforcement)
+- Architecture change (add authentication layer, separate privilege domains)
+- Monitoring/detection (log anomalies, rate limiting, alerting)
+- Accepted risk (document why the threat is tolerated)
+
+Log to `security/mitigations.md`.
+
+---
+
+### Phase 7 — Coverage Scoring & Re-Audit
+
+**Coverage metric:**
+
+```
+coverage = (threats_addressed / threats_identified) × 100
+
+Where:
+  threats_identified = all STRIDE threats + all OWASP FAIL/PARTIAL findings
+  threats_addressed  = findings with mitigation status NOT 'proposed'
+                       (i.e., implemented, accepted-risk, or wont-fix with justification)
+```
+
+**At the end of each iteration:**
+1. Calculate current coverage score.
+2. Write `security/coverage-report.md` with score + gap analysis.
+3. If `coverage >= target` → audit complete, produce final summary.
+4. If `coverage < target` AND budget not exhausted → begin re-audit pass.
+
+**Re-audit pass:** Focus on the highest-severity unaddressed threats. Propose additional mitigations or refine existing ones. Increment the pass counter.
+
+---
+
+## Re-Audit with --diff Flag
+
+When called with `--diff`, only audit what changed since the last audit:
+
+1. Load `security/threats.md` and `security/mitigations.md` from the previous run.
+2. Identify changed files (via `git diff --name-only` or user-provided diff).
+3. Re-check only STRIDE threats and OWASP items that touch changed files.
+4. Update threat/mitigation records. Do NOT re-check unchanged components.
+5. Recalculate coverage score.
+
+**--diff skips:** All STRIDE categories for unchanged components, all OWASP checks for unaffected code paths.
+
+---
+
+## Coverage Report Format
+
+`security/coverage-report.md`:
+
+```markdown
+# Security Coverage Report
+Date: [ISO date]
+Pass: [N]
+Target: [80]%
+Current Coverage: [X]%
+
+## Score Breakdown
+- Threats identified: [N]
+- Threats addressed: [M]
+- Coverage: [X]%
+
+## Status
+[PASS: Target achieved] / [IN PROGRESS: X% of target]
+
+## Unaddressed Threats (Gaps)
+| Threat ID | Severity | Description | Blocker |
+|-----------|----------|-------------|---------|
+
+## Addressed Threats Summary
+| Threat ID | Severity | Mitigation | Status |
+|-----------|----------|------------|--------|
+
+## Accepted Risks
+[List of threats with accepted-risk status and justification]
+```
+
+---
+
+## Output Structure
+
+| File | Updated | Purpose |
+|------|---------|---------|
+| `security/threats.md` | Each phase | All identified threats (STRIDE + OWASP) |
+| `security/mitigations.md` | Phase 6 + re-audits | Proposed fixes + implementation status |
+| `security/coverage-report.md` | Phase 7 + re-audits | Coverage score, gaps, accepted risks |
+
+---
+
+## Edge Cases
+
+| Situation | Handling |
+|-----------|----------|
+| No codebase access (Tier 2/3) | Base threats on architecture description; note confidence is lower |
+| STRIDE category has zero threats | Log "No threats identified for [category] — [brief reason]" |
+| Coverage target unreachable | After 3 re-audit passes, produce report with "maximum achievable coverage: X%" |
+| New critical threat found in re-audit | Add to threats.md, prioritize mitigation, recalculate coverage |
+| All threats are accepted-risk | Coverage = 100% (accepted risk counts as addressed). Flag this prominently. |
+| --diff but no previous security/ folder | Run full audit instead, warn the user |
+
+---
+
+## Iteration Budget
+
+- **Default:** 3 re-audit passes (initial audit + 2 re-audits)
+- **Override:** Set `max_audit_passes: N` in the request
+- **Termination:** coverage >= target OR passes exhausted
+- **On exhaustion:** Report highest achievable coverage with recommendations for manual review of remaining gaps

package/assets/lithermes-plugin/skills/autoresearch/modes/security/owasp-checklist.md

@@ -0,0 +1,156 @@
+# OWASP Top 10 (2021) Checklist
+
+> **LitHermes child boundary:** This is inert Hermes reference data. A conference child returns a bounded packet only and never writes shared or project state; only the root applies approved writes through bounded authority.
+
+Reference for Phase 4 of the `autoresearch:security` audit. For each category, verify all check items by reading code or reviewing architecture. Mark each category PASS / FAIL / PARTIAL / N/A.
+
+A category is **PASS** only if all applicable check items are verified.
+A category is **PARTIAL** if some checks pass and others cannot be verified.
+A category is **N/A** only if the category is structurally inapplicable (document why).
+
+---
+
+## A01 — Broken Access Control
+
+**What it is:** The application fails to enforce what authenticated users are allowed to do. Users can access data or functions beyond their intended permissions.
+
+**Check items:**
+1. Every API endpoint that returns user-specific data performs an authorization check — not just an authentication check. Verify that ownership/role is validated before returning resources (look for patterns like `if resource.owner_id != current_user.id`).
+2. Admin-only endpoints (user management, configuration, bulk operations) are protected by explicit role checks, not merely by being "hidden" from the UI.
+3. CORS policy is restrictive: `Access-Control-Allow-Origin` is not set to `*` for authenticated endpoints. Allowed origins are an explicit allowlist.
+4. Directory listing is disabled on all web-accessible paths. Static file servers do not expose `.git`, `.env`, or backup files.
+5. JWT tokens and session tokens cannot be reused after logout. Server-side token invalidation exists.
+
+---
+
+## A02 — Cryptographic Failures
+
+**What it is:** Sensitive data is exposed due to weak or absent encryption — in transit, at rest, or in processing.
+
+**Check items:**
+1. All data in transit uses TLS 1.2 or higher. HTTP-only endpoints do not exist for authenticated or sensitive routes. HSTS header is present.
+2. Passwords are hashed with a modern adaptive algorithm: bcrypt, scrypt, Argon2, or PBKDF2. MD5, SHA-1, and plain SHA-256 are not used for password storage.
+3. Sensitive fields at rest (PII, payment data, credentials, tokens) are encrypted. Encryption uses AES-256 or equivalent; keys are not stored in the same location as encrypted data.
+4. Cryptographic keys and secrets are not hardcoded in source code, config files, or version control. Secret management (environment variables, vault) is used.
+5. Random values used for security purposes (tokens, session IDs, nonces) are generated with a cryptographically secure RNG, not `Math.random()` or `random.random()`.
+
+---
+
+## A03 — Injection
+
+**What it is:** Untrusted data is sent to an interpreter (SQL, shell, LDAP, XML, etc.) as part of a command or query, causing unintended execution.
+
+**Check items:**
+1. All database queries use parameterized queries or prepared statements. String concatenation to build SQL queries does not exist (search for `f"SELECT`, `"SELECT " +`, `query.format(`, `% user_input`).
+2. Shell commands constructed from user input use argument arrays, not string interpolation (e.g., `subprocess(["cmd", arg])` not `subprocess(f"cmd {arg}", shell=True)`).
+3. Template engines are used in auto-escaping mode. User input is never passed directly to `eval()`, `exec()`, or equivalent dynamic code execution functions.
+4. XML parsers have external entity processing (XXE) disabled. DTD processing is disabled or the parser is explicitly configured to reject external entities.
+5. ORM-level raw query escape hatches (`raw()`, `execute()`, `query()`) are audited — each use is reviewed to confirm input is parameterized or sanitized.
+
+---
+
+## A04 — Insecure Design
+
+**What it is:** Fundamental design flaws that cannot be fixed by correct implementation alone — the architecture itself lacks security controls.
+
+**Check items:**
+1. Rate limiting exists for authentication endpoints (login, password reset, OTP verification). Brute-force attacks are not feasible at current limits.
+2. Password reset flows use time-limited, single-use tokens sent to verified channels. They do not rely on security questions or predictable tokens.
+3. Business logic enforces server-side invariants that cannot be violated by manipulating client-sent data (e.g., price validation, quantity limits, balance checks happen on the server).
+4. Sensitive workflows (account deletion, large transfers, privilege changes) require re-authentication or a secondary confirmation step.
+5. The system has a documented threat model. Security requirements were considered at design time, not only during implementation.
+
+---
+
+## A05 — Security Misconfiguration
+
+**What it is:** Insecure default settings, incomplete configurations, open cloud storage, unnecessary features, or misconfigured security headers.
+
+**Check items:**
+1. Security headers are present on all HTTP responses: `Content-Security-Policy`, `X-Frame-Options`, `X-Content-Type-Options: nosniff`, `Referrer-Policy`, `Permissions-Policy`.
+2. Default credentials are changed. Frameworks and services are not deployed with factory passwords, default admin accounts, or sample applications.
+3. Error responses do not expose stack traces, internal paths, database names, framework versions, or server software to external clients.
+4. Unnecessary features, services, and ports are disabled. The attack surface is minimized (no debug endpoints in production, no admin UIs on public ports).
+5. Dependencies are up to date. No known-vulnerable versions of frameworks, libraries, or runtimes are in use. Dependency scanning runs in CI.
+
+---
+
+## A06 — Vulnerable and Outdated Components
+
+**What it is:** Using components (libraries, frameworks, runtime) with known vulnerabilities, or failing to track component versions.
+
+**Check items:**
+1. A software bill of materials (SBOM) or dependency manifest exists and is version-pinned (`package-lock.json`, `poetry.lock`, `go.sum`, `Cargo.lock`).
+2. Automated vulnerability scanning runs in CI (e.g., `npm audit`, `pip-audit`, `trivy`, `snyk`, `dependabot`). Known critical/high vulnerabilities in direct dependencies are resolved.
+3. Components are updated on a regular cadence. No dependency is more than 2 major versions behind its current release.
+4. Unused dependencies are removed. The dependency tree does not contain packages that serve no active purpose.
+5. Container base images are scanned for OS-level CVEs. Images are not based on `latest` tags — they pin specific versions.
+
+---
+
+## A07 — Identification and Authentication Failures
+
+**What it is:** Weaknesses in authentication allow attackers to compromise passwords, keys, session tokens, or to assume other users' identities.
+
+**Check items:**
+1. Passwords must meet minimum complexity requirements. Common passwords are rejected (check against a blocklist). Maximum length is not set too low (allow >= 64 characters).
+2. Multi-factor authentication (MFA) is available and enforced for privileged accounts. Admin interfaces require MFA.
+3. Session tokens are sufficiently random (>= 128 bits of entropy), rotated after login, invalidated on logout, and expire after a reasonable idle timeout.
+4. Login failures do not reveal whether the username or the password was incorrect (generic "invalid credentials" message for both cases).
+5. The application is not vulnerable to credential stuffing: account lockout or progressive delay exists after N failed attempts, and/or CAPTCHA is used for automated abuse prevention.
+
+---
+
+## A08 — Software and Data Integrity Failures
+
+**What it is:** Code and infrastructure that does not protect against integrity violations — unsigned updates, insecure deserialization, CI/CD pipeline tampering.
+
+**Check items:**
+1. Dependencies come only from trusted registries with integrity verification (checksums or SRI hashes). When a separately approved restore is necessary, the root must use the repository-owned mode that disables lifecycle scripts; children only propose the action and never install packages.
+2. Serialized objects from untrusted sources (cookies, API inputs) are not deserialized into live objects without type-safe validation. Languages with unsafe deserialization (Java, Python pickle, PHP unserialize) are audited.
+3. CI/CD pipelines are protected: secrets are injected via environment, not baked into images; pipeline configs are version-controlled and protected from unauthorized modification.
+4. Software updates use signed artifacts. If the application auto-updates components, it verifies signatures before applying.
+5. Critical data received from clients is re-validated server-side. The server does not trust the client's representation of computed values (prices, totals, checksums).
+
+---
+
+## A09 — Security Logging and Monitoring Failures
+
+**What it is:** Insufficient logging, monitoring, and alerting allows attackers to operate undetected for extended periods.
+
+**Check items:**
+1. Authentication events are logged: successful logins, failed logins, logouts, password resets. Each event includes: timestamp (UTC), user identifier, source IP, user agent, outcome.
+2. Authorization failures are logged: access denied events, attempts to reach unauthorized resources. These are monitored for anomalies (repeated failures = potential enumeration or escalation attempt).
+3. Sensitive data operations are logged: creation, modification, and deletion of sensitive records. The audit trail is append-only and cannot be modified by application-level users.
+4. Logs are shipped to a centralized system (SIEM, log aggregator) that is separate from the application servers. An attacker who compromises the application cannot delete the logs.
+5. Alerting exists for critical security events: multiple failed logins, impossible travel, bulk data export, new admin account creation. Alerts have defined response procedures.
+
+---
+
+## A10 — Server-Side Request Forgery (SSRF)
+
+**What it is:** The application fetches a remote resource using a URL supplied by an attacker, allowing the attacker to reach internal services, metadata endpoints, or other restricted destinations.
+
+**Check items:**
+1. User-supplied URLs are validated against an allowlist of permitted schemes (`https` only) and hostnames before the server makes any outbound request.
+2. Internal network ranges are blocked from user-controlled URL targets: `169.254.0.0/16` (cloud metadata), `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `127.0.0.0/8`, `::1`.
+3. Cloud provider metadata endpoints are not reachable via user-controlled URLs. AWS `169.254.169.254`, GCP `metadata.google.internal`, Azure `169.254.169.254` are explicitly blocked.
+4. DNS rebinding mitigations exist: the IP address is resolved once and validated before the connection is made; re-resolution is not allowed after validation.
+5. Outbound HTTP clients are configured with explicit allowlists or egress firewall rules. The application cannot make arbitrary outbound requests to unchecked destinations.
+
+---
+
+## OWASP Quick Reference Table
+
+| ID | Category | Core Risk | CWE References |
+|----|----------|-----------|----------------|
+| A01 | Broken Access Control | Authorization bypass | CWE-200, CWE-284, CWE-285 |
+| A02 | Cryptographic Failures | Data exposure | CWE-261, CWE-296, CWE-310 |
+| A03 | Injection | Command execution | CWE-77, CWE-78, CWE-89 |
+| A04 | Insecure Design | Architectural flaws | CWE-657, CWE-840 |
+| A05 | Security Misconfiguration | Default/open settings | CWE-2, CWE-16 |
+| A06 | Vulnerable Components | Known CVEs | CWE-1035, CWE-1104 |
+| A07 | Auth Failures | Account compromise | CWE-287, CWE-306 |
+| A08 | Integrity Failures | Tampered artifacts | CWE-345, CWE-502 |
+| A09 | Logging Failures | Undetected attacks | CWE-117, CWE-223 |
+| A10 | SSRF | Internal access | CWE-918 |