@harness-engineering/cli 1.13.0 → 1.13.1

package/dist/agents/skills/gemini-cli/harness-secrets/SKILL.md

@@ -0,0 +1,293 @@
+# Harness Secrets
+
+> Secret detection, credential hygiene, and vault integration. Find exposed secrets, classify risk, and enforce externalization before they reach production.
+
+## When to Use
+
+- When scanning source code for hardcoded secrets, API keys, or credentials
+- When auditing environment variable hygiene and `.env` file management
+- On PRs that modify configuration files or add new service integrations
+- NOT for general application security review (use harness-security-review)
+- NOT for infrastructure credential management (use harness-infrastructure-as-code)
+- NOT for CI/CD secret injection (use harness-deployment)
+
+## Process
+
+### Phase 1: SCAN -- Detect Secrets in Source Code
+
+1. **Scan source files for secret patterns.** Search for common secret formats:
+   - **API keys:** Patterns matching `sk-`, `pk_`, `AKIA`, `AIza`, `ghp_`, `glpat-`, `xoxb-`
+   - **Connection strings:** Database URIs with embedded credentials (`postgres://user:pass@`)
+   - **Private keys:** `-----BEGIN RSA PRIVATE KEY-----`, `-----BEGIN EC PRIVATE KEY-----`
+   - **JWT tokens:** Base64-encoded strings matching `eyJ` header pattern
+   - **Generic secrets:** Variables named `password`, `secret`, `token`, `api_key` with literal string values
+
+2. **Scan configuration files.** Check files that commonly contain secrets:
+   - `.env`, `.env.local`, `.env.production` (should be gitignored)
+   - `config/*.json`, `config/*.yaml` with credential fields
+   - `docker-compose.yml` with inline environment values
+   - `application.properties`, `appsettings.json` with connection strings
+   - CI/CD pipeline files with hardcoded values
+
+3. **Check `.gitignore` coverage.** Verify that sensitive files are excluded from version control:
+   - `.env*` files (except `.env.example`)
+   - `*.pem`, `*.key` private key files
+   - `credentials/`, `secrets/` directories
+   - Service account JSON files (`*-credentials.json`)
+   - IDE-specific files that may cache environment variables
+
+4. **Scan git history for leaked secrets.** Check recent commits:
+   - Run `git log --diff-filter=A --name-only` for recently added files
+   - Check if any `.env` or credential files were committed and later removed
+   - Flag files that appear in git history but are now gitignored (the secret is still in history)
+
+5. **Present scan results:**
+
+   ```
+   Secret Scan: 7 findings in 5 files
+
+   CRITICAL (2):
+     src/config/database.ts:8 -- Hardcoded PostgreSQL connection string with password
+     src/services/stripe.ts:3 -- Stripe secret key (sk_live_...)
+
+   HIGH (3):
+     docker-compose.yml:15 -- MySQL root password in plaintext
+     src/config/aws.ts:12 -- AWS access key pattern (AKIA...)
+     .env.production:1 -- File committed to git (should be gitignored)
+
+   MEDIUM (2):
+     src/utils/auth.ts:45 -- JWT secret as string literal
+     config/app.json:22 -- Generic "apiKey" field with literal value
+   ```
+
+---
+
+### Phase 2: CLASSIFY -- Categorize by Risk and Type
+
+1. **Assign severity levels.** Classify each finding:
+   - **CRITICAL:** Live production credentials, private keys, cloud provider access keys. Immediate rotation required.
+   - **HIGH:** Secrets in committed files, database passwords, service API keys. Rotation strongly recommended.
+   - **MEDIUM:** Development-only secrets in source, JWT signing keys, generic tokens. Should be externalized.
+   - **LOW:** Example values that look like secrets but are placeholders (`YOUR_API_KEY_HERE`), test-only credentials in test fixtures.
+
+2. **Identify secret type.** Categorize each finding:
+   - Cloud provider credentials (AWS, GCP, Azure)
+   - Database credentials (connection strings, passwords)
+   - Third-party API keys (Stripe, SendGrid, Twilio)
+   - Authentication secrets (JWT keys, OAuth client secrets)
+   - Encryption keys (symmetric keys, private keys)
+   - Internal service tokens (inter-service auth)
+
+3. **Assess blast radius.** For each CRITICAL and HIGH finding:
+   - What systems does this credential access?
+   - Is the credential scoped (read-only, limited permissions) or broad (admin)?
+   - Is the credential shared across environments?
+   - When was the credential last rotated?
+
+4. **Check for false positives.** Verify findings are actual secrets:
+   - Example/placeholder values in documentation
+   - Test fixtures with fake credentials
+   - Base64-encoded non-secret data matching JWT patterns
+   - Hash values that match key patterns but are not keys
+
+5. **Generate classification report:**
+
+   ```
+   Classification:
+     CRITICAL: 2 (require immediate rotation)
+     HIGH: 3 (require rotation within 24 hours)
+     MEDIUM: 2 (require externalization)
+     LOW: 0
+     False positives: 1 (removed from findings)
+
+   Affected systems:
+     - PostgreSQL database (production)
+     - Stripe payment processing
+     - AWS S3 storage
+   ```
+
+---
+
+### Phase 3: REMEDIATE -- Extract and Secure Secrets
+
+1. **Recommend secret externalization.** For each finding, provide the remediation:
+   - Replace hardcoded value with environment variable reference
+   - Add the variable to `.env.example` with a placeholder value
+   - Add the actual value to the deployment secret store
+   - Verify `.gitignore` includes the actual `.env` file
+
+2. **Recommend secret management integration.** Based on the project's infrastructure:
+   - **HashiCorp Vault:** Dynamic secrets, lease-based rotation, transit encryption
+   - **AWS Secrets Manager:** Native AWS integration, automatic rotation for RDS
+   - **Google Secret Manager:** GCP-native, IAM-based access control
+   - **Azure Key Vault:** Azure-native, HSM-backed key storage
+   - **dotenv + CI secrets:** Minimum viable approach for smaller projects
+
+3. **Recommend rotation procedure.** For each CRITICAL and HIGH finding:
+   - Generate a new credential in the source system
+   - Update the secret store with the new value
+   - Deploy the updated configuration
+   - Verify the service works with the new credential
+   - Revoke the old credential
+   - Confirm no systems depend on the old credential
+
+4. **Provide code transformation examples.** Show before/after for each finding:
+
+   ```typescript
+   // BEFORE (hardcoded)
+   const stripe = new Stripe('sk_live_abc123...');
+
+   // AFTER (externalized)
+   const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
+   ```
+
+5. **If `--fix` flag is set,** apply automatic transformations:
+   - Extract hardcoded values to environment variables
+   - Add `.env.example` entries with placeholder values
+   - Update `.gitignore` if `.env` files are not excluded
+   - Present the diff for review before committing
+
+---
+
+### Phase 4: VALIDATE -- Verify Remediation Completeness
+
+1. **Re-scan after remediation.** Run the same scan from Phase 1 to verify:
+   - All CRITICAL and HIGH findings are resolved
+   - No new secrets were introduced during remediation
+   - Environment variable references resolve correctly
+
+2. **Verify `.gitignore` coverage.** Confirm:
+   - All `.env` files (except `.env.example`) are gitignored
+   - Private key files are gitignored
+   - The gitignore patterns are specific enough (not overly broad)
+
+3. **Verify `.env.example` completeness.** Check that:
+   - Every environment variable referenced in code has an entry
+   - Values are placeholders, not actual secrets
+   - Each entry has a comment describing the variable's purpose
+   - Required vs. optional variables are clearly marked
+
+4. **Check git history for residual exposure.** If secrets were previously committed:
+   - Warn that the secret exists in git history even after removal
+   - Recommend `git filter-repo` or BFG Repo-Cleaner for history rewriting
+   - Emphasize that rotation is required regardless of history cleanup
+   - Note that force-push to remote may be required after history rewrite
+
+5. **Generate validation report:**
+
+   ```
+   Secret Validation: [PASS/WARN/FAIL]
+
+   Rescan: PASS (0 CRITICAL, 0 HIGH findings)
+   .gitignore: PASS (all sensitive patterns covered)
+   .env.example: WARN (missing STRIPE_WEBHOOK_SECRET entry)
+   Git history: WARN (2 secrets exist in history -- rotation required)
+
+   Actions remaining:
+     1. Add STRIPE_WEBHOOK_SECRET to .env.example
+     2. Rotate PostgreSQL password (exposed in commit abc1234)
+     3. Rotate Stripe key (exposed in commit def5678)
+     4. Consider git history rewrite after rotation
+   ```
+
+---
+
+## Harness Integration
+
+- **`harness skill run harness-secrets`** -- Primary invocation for secret scanning and remediation.
+- **`harness validate`** -- Run after remediation to verify project health.
+- **`harness check-security`** -- Complementary mechanical security scan that includes basic secret detection.
+- **`emit_interaction`** -- Present findings and gather decisions on remediation approach.
+
+## Success Criteria
+
+- All source files are scanned for secret patterns
+- Findings are classified by severity with accurate false-positive filtering
+- CRITICAL and HIGH findings have specific rotation recommendations
+- Environment variable externalization is verified
+- `.gitignore` covers all sensitive file patterns
+- `.env.example` is complete with placeholder values
+- Git history exposure is flagged with rotation guidance
+
+## Examples
+
+### Example: Express.js API with Hardcoded Stripe Keys
+
+```
+Phase 1: SCAN
+  Scanned: 86 files
+  Findings: 4
+
+  CRITICAL: src/payments/stripe.ts:5 -- sk_live_EXAMPLE_KEY_REDACTED_0000
+  HIGH: docker-compose.yml:22 -- POSTGRES_PASSWORD=supersecret
+  MEDIUM: src/config/jwt.ts:3 -- JWT_SECRET = "my-jwt-secret-key"
+  LOW: tests/fixtures/auth.ts:8 -- fake-api-key-for-testing (false positive)
+
+Phase 2: CLASSIFY
+  CRITICAL: 1 (Stripe production secret key -- full payment access)
+  HIGH: 1 (PostgreSQL password -- database access)
+  MEDIUM: 1 (JWT secret -- token forgery risk)
+  False positives: 1 (test fixture removed from findings)
+
+Phase 3: REMEDIATE
+  1. Stripe key -> process.env.STRIPE_SECRET_KEY
+  2. Postgres password -> ${POSTGRES_PASSWORD} in compose, actual value in .env
+  3. JWT secret -> process.env.JWT_SECRET
+  Added 3 entries to .env.example
+  Updated .gitignore with .env* pattern
+
+Phase 4: VALIDATE
+  Rescan: PASS (0 findings)
+  .gitignore: PASS
+  .env.example: PASS (all 3 variables documented)
+  Git history: WARN (Stripe key in commit history)
+  Result: WARN -- secrets externalized, rotation required for Stripe and Postgres
+```
+
+### Example: Django Application with AWS Credentials
+
+```
+Phase 1: SCAN
+  Scanned: 124 files
+  Findings: 5
+
+  CRITICAL: settings/production.py:45 -- AWS_ACCESS_KEY_ID = "AKIA..."
+  CRITICAL: settings/production.py:46 -- AWS_SECRET_ACCESS_KEY = "wJal..."
+  HIGH: .env.production committed to git (12 secrets inside)
+  MEDIUM: settings/base.py:88 -- SECRET_KEY = "django-insecure-..."
+  MEDIUM: settings/base.py:92 -- DATABASE_URL with embedded password
+
+Phase 2: CLASSIFY
+  CRITICAL: 2 (AWS IAM credentials -- full account access)
+  HIGH: 1 (.env.production in git -- 12 leaked values)
+  MEDIUM: 2 (Django secret key and database URL)
+
+Phase 3: REMEDIATE
+  1. AWS credentials -> boto3 credential chain (env vars or IAM role)
+  2. Remove .env.production from git, add to .gitignore
+  3. Django SECRET_KEY -> os.environ["DJANGO_SECRET_KEY"]
+  4. DATABASE_URL -> os.environ["DATABASE_URL"]
+  Recommend: Switch to django-environ for all settings
+  Recommend: Use IAM roles instead of access keys for production
+
+Phase 4: VALIDATE
+  Rescan: PASS
+  .gitignore: PASS
+  .env.example: PASS
+  Git history: CRITICAL (AWS keys and .env.production in history)
+  Result: FAIL -- rotation required before deployment, history rewrite recommended
+```
+
+## Gates
+
+- **No CRITICAL findings may remain unaddressed.** Production credentials exposed in source code are blocking. Execution halts until the credential is rotated and the code is remediated.
+- **No `.env` files with actual secrets committed to git.** A committed `.env` file containing real credentials is a blocking finding, even if the file is later gitignored.
+- **No secrets in git history without rotation.** If a secret was previously committed, it must be rotated regardless of whether it was removed from the current tree.
+- **No remediation without verification.** The `--fix` flag must be followed by a rescan to confirm all findings are resolved.
+
+## Escalation
+
+- **When a production credential is exposed in a public repository:** This is an emergency. Immediately recommend rotating the credential, then address code remediation. Do not wait for a PR review cycle -- rotation must happen within minutes.
+- **When git history contains secrets and the repo is public:** Recommend making the repo private temporarily, rotating all exposed credentials, running BFG Repo-Cleaner, and force-pushing. Note that GitHub caches may retain the data -- contact GitHub support if needed.
+- **When the team has no secret management infrastructure:** Recommend starting with CI/CD platform secrets (GitHub Secrets, GitLab CI variables) as a minimum viable approach. Design a migration path to a dedicated secret manager for later.
+- **When false positive rate is high:** Adjust scan patterns for the project's domain. Add a `.harness/secret-scan-ignore` file with documented exceptions for known false positives (test fixtures, example values, hash constants).

package/dist/agents/skills/gemini-cli/harness-secrets/skill.yaml

@@ -0,0 +1,76 @@
+name: harness-secrets
+version: "1.0.0"
+description: Vault integration, credential rotation, and environment variable hygiene
+cognitive_mode: meticulous-verifier
+tier: 3
+internal: false
+keywords:
+  - secrets
+  - vault
+  - credentials
+  - env
+  - environment variables
+  - rotation
+  - HashiCorp
+  - AWS Secrets Manager
+  - dotenv
+  - encryption
+  - API keys
+stack_signals:
+  - ".env*"
+  - "vault.hcl"
+  - "src/**/secrets/**"
+  - "src/**/config/**"
+  - ".sops.yaml"
+  - "secrets/"
+  - "credentials/"
+triggers:
+  - manual
+  - on_pr
+  - on_commit
+platforms:
+  - claude-code
+  - gemini-cli
+tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+  - emit_interaction
+cli:
+  command: harness skill run harness-secrets
+  args:
+    - name: path
+      description: Project root path
+      required: false
+    - name: changed-only
+      description: Only scan git-changed files
+      type: boolean
+      required: false
+    - name: fix
+      description: Auto-remediate by extracting secrets to env vars
+      type: boolean
+      required: false
+mcp:
+  tool: run_skill
+  input:
+    skill: harness-secrets
+    path: string
+type: rigid
+phases:
+  - name: scan
+    description: Detect secrets, credentials, and sensitive values in source code
+    required: true
+  - name: classify
+    description: Categorize findings by severity and secret type
+    required: true
+  - name: remediate
+    description: Recommend or apply secret extraction and rotation strategies
+    required: true
+  - name: validate
+    description: Verify secrets are properly externalized and gitignored
+    required: true
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/gemini-cli/harness-security-review/SKILL.md

@@ -0,0 +1,240 @@
+# Harness Security Review
+
+> Deep security audit combining mechanical scanning with AI-powered vulnerability analysis. OWASP baseline + stack-adaptive rules + optional threat modeling.
+
+## When to Use
+
+- Before a release or security-sensitive merge
+- After updating dependencies (supply chain risk)
+- When auditing a new or unfamiliar codebase
+- When `on_pr` triggers fire on security-sensitive paths
+- NOT for quick pre-commit checks (use harness-pre-commit-review for that)
+- NOT for general code review (use harness-code-review for that)
+
+## Scope Adaptation
+
+This skill adapts its behavior based on invocation context — standalone or as part of the code review pipeline.
+
+### Detection
+
+Check for `pipelineContext` in `.harness/handoff.json`. If present, run in **changed-files mode**. Otherwise, run in **full mode**.
+
+```bash
+# Check for pipeline context
+cat .harness/handoff.json 2>/dev/null | grep -q '"pipelineContext"'
+```
+
+### Changed-Files Mode (Code Review Pipeline)
+
+When invoked from the code review pipeline (Phase 4 fan-out, security slot):
+
+- **Phase 1 (SCAN): SKIPPED.** The mechanical security scan already ran in code review Phase 2. Read the mechanical findings from `PipelineContext.findings` where `domain === 'security'` instead of re-running `run_security_scan`.
+- **Phase 2 (REVIEW):** Run OWASP baseline + stack-adaptive analysis on **changed files only** plus their direct imports (for data flow tracing). The changed file list is provided in the context bundle from the pipeline.
+- **Phase 3 (THREAT-MODEL): SKIPPED** unless `--deep` flag was passed through from code review.
+- **Phase 4 (REPORT): SKIPPED.** Return findings as `ReviewFinding[]` to the pipeline. The pipeline handles output formatting (Phase 7).
+
+Findings returned in this mode **must** use the `ReviewFinding` schema with populated security fields (`cweId`, `owaspCategory`, `confidence`, `remediation`, `references`).
+
+### Full Mode (Standalone)
+
+When invoked directly (no PipelineContext):
+
+- All phases run as documented below (Phase 1 through Phase 4).
+- Output is the standalone security report format.
+- This is the existing behavior — no changes.
+
+## Principle: Layered Security
+
+This skill follows the Deterministic-vs-LLM Responsibility Split principle. The mechanical scanner runs first and catches what patterns can catch. The AI review then looks for semantic issues that patterns miss — user input flowing through multiple functions to a dangerous sink, missing authorization checks, logic flaws in authentication flows.
+
+## Process
+
+### Phase 1: SCAN — Mechanical Security Scanner (full mode only)
+
+> **Note:** This phase is skipped in changed-files mode. See [Scope Adaptation](#scope-adaptation) above.
+
+Run the built-in security scanner against the project.
+
+1. **Run the scanner.** Use the `run_security_scan` MCP tool or invoke `SecurityScanner` directly:
+
+   ```bash
+   # Via MCP
+   harness scan --security
+
+   # Via CLI
+   npx vitest run packages/core/tests/security/
+   ```
+
+2. **Review findings.** Categorize by severity:
+   - **Error (blocking):** Must fix before merge — secrets, injection, eval, weak crypto
+   - **Warning (review):** Should fix — CORS wildcards, disabled TLS, path traversal patterns
+   - **Info (note):** Consider — HTTP URLs, missing security headers
+
+3. **Report mechanical findings.** Present each finding with:
+   - Rule ID and name
+   - File, line number, matched code
+   - Remediation guidance
+   - CWE/OWASP reference
+
+### Phase 2: REVIEW — AI-Powered Security Analysis
+
+After mechanical scanning, perform deeper AI analysis.
+
+#### OWASP Baseline (always runs)
+
+Review the codebase against OWASP Top 10 and CWE Top 25:
+
+1. **Injection (CWE-89, CWE-78, CWE-79):** Look for user input flowing to SQL queries, shell commands, or HTML output without sanitization. Trace data flow across function boundaries — patterns only catch single-line issues.
+
+2. **Broken Authentication (CWE-287):** Check for weak session management, missing MFA enforcement, hardcoded credentials, predictable tokens.
+
+3. **Sensitive Data Exposure (CWE-200):** Look for PII logged to console/files, sensitive data in error messages, missing encryption for data at rest or in transit.
+
+4. **Broken Access Control (CWE-862):** Check for missing authorization on API endpoints, IDOR vulnerabilities, privilege escalation paths.
+
+5. **Security Misconfiguration (CWE-16):** Check for debug mode in production configs, default credentials, overly permissive CORS, missing security headers.
+
+#### Stack-Adaptive Review (based on detected tech)
+
+After the OWASP baseline, add stack-specific checks:
+
+- **Node.js:** Prototype pollution via `Object.assign` or spread on user input, `__proto__` injection, unhandled promise rejections exposing stack traces
+- **Express:** Missing helmet, rate limiting, CSRF protection, body parser limits
+- **React:** XSS via `dangerouslySetInnerHTML`, sensitive data in client state, insecure `postMessage` listeners
+- **Go:** Race conditions in concurrent handlers, `unsafe.Pointer` usage, format string injection
+
+### Phase 3: THREAT-MODEL (optional, `--deep` flag; full mode or explicit `--deep` in pipeline)
+
+When invoked with `--deep`, build a lightweight threat model:
+
+1. **Identify entry points.** Find all HTTP routes, API endpoints, message handlers, CLI commands, and file upload handlers.
+
+2. **Map trust boundaries.** Where does data cross from untrusted (user input, external APIs) to trusted (database queries, file system, internal services)?
+
+3. **Trace data flows.** For each entry point, trace how user-controlled data flows through the system. Use the knowledge graph if available (`query_graph`, `get_relationships`).
+
+4. **Identify threat scenarios.** For each trust boundary crossing, ask:
+   - What if this input is malicious?
+   - What is the worst-case impact?
+   - What controls are in place?
+
+5. **Report threat model.** Present as a table:
+   | Entry Point | Data Flow | Trust Boundary | Threats | Controls | Risk |
+   |-------------|-----------|----------------|---------|----------|------|
+
+### Phase 4: REPORT — Consolidated Findings
+
+Produce a unified security report:
+
+```
+Security Review: [PASS/WARN/FAIL]
+
+Mechanical Scanner:
+- Scanned: N files, M rules applied
+- Coverage: baseline/enhanced
+- Errors: N | Warnings: N | Info: N
+
+[List each finding with rule ID, file:line, severity, and remediation]
+
+AI Review:
+- OWASP Baseline: [findings or "No issues found"]
+- Stack-Adaptive ([detected stacks]): [findings or "No issues found"]
+
+[If --deep]
+Threat Model:
+- Entry points: N
+- Trust boundaries: N
+- High-risk flows: [list]
+```
+
+## Harness Integration
+
+- **`run_security_scan` MCP tool** — Run the mechanical scanner programmatically
+- **`harness validate`** — Standard project health check
+- **`query_graph` / `get_relationships`** — Used in threat modeling phase for data flow tracing
+- **`get_impact`** — Understand blast radius of security-sensitive changes
+
+## Gates
+
+- **Mechanical scanner must run before AI review.** The scanner catches what patterns can catch; AI reviews what remains.
+- **Error-severity findings are blocking.** The report must be FAIL if any error-severity finding exists.
+- **AI review must reference specific code.** No vague warnings like "consider improving security." Every finding must point to a file, line, and specific issue.
+- **Threat model is optional.** Only runs with `--deep`. Do not run it unless explicitly requested.
+
+## Success Criteria
+
+- Mechanical scanner ran and produced findings (or confirmed clean)
+- AI review covered OWASP Top 10 baseline
+- Stack-adaptive checks matched the detected technology
+- Every finding includes file, line, CWE reference, and remediation
+- Report follows the structured format
+- Error-severity findings result in FAIL status
+
+## Escalation
+
+- **Scanner finds secrets in committed code:** Flag immediately. Recommend rotating the compromised credentials. This is urgent regardless of other findings.
+- **AI review finds a critical vulnerability (RCE, SQLi, auth bypass):** Mark as blocking. Do not approve the PR. Provide exact remediation code.
+- **Conflict between scanner and AI review:** If the scanner flags something the AI thinks is a false positive, include both perspectives in the report. Let the human decide.
+- **Scope too large for meaningful review:** If the project has >1000 source files, recommend scoping the review to changed files or a specific subsystem.
+
+## Examples
+
+### Example: Clean Scan
+
+```
+Security Review: PASS
+
+Mechanical Scanner:
+- Scanned: 42 files, 22 rules applied
+- Coverage: baseline
+- Errors: 0 | Warnings: 0 | Info: 0
+
+AI Review:
+- OWASP Baseline: No issues found
+- Stack-Adaptive (node, express): No issues found
+```
+
+### Example: Findings Detected
+
+```
+Security Review: FAIL
+
+Mechanical Scanner:
+- Scanned: 42 files, 22 rules applied
+- Coverage: baseline
+- Errors: 2 | Warnings: 1 | Info: 0
+
+Findings:
+1. [SEC-SEC-002] ERROR src/config.ts:12 — Hardcoded API key or secret detected
+   Remediation: Use environment variables: process.env.API_KEY
+2. [SEC-INJ-002] ERROR src/db.ts:45 — SQL query built with string concatenation
+   Remediation: Use parameterized queries: query("SELECT * FROM users WHERE id = $1", [id])
+3. [SEC-NET-001] WARNING src/cors.ts:8 — CORS wildcard origin allows any website to make requests
+   Remediation: Restrict CORS to specific trusted origins
+
+AI Review:
+- OWASP Baseline: 1 finding — user input from req.params.id flows through formatQuery() to db.execute() without sanitization (confirms SEC-INJ-002 with data flow trace)
+- Stack-Adaptive (node, express): Missing helmet middleware, missing rate limiting on /api/* routes
+```
+
+### Example: Deep Audit with Threat Model
+
+```
+Security Review: WARN
+
+Mechanical Scanner:
+- Scanned: 120 files, 30 rules applied
+- Coverage: baseline
+- Errors: 0 | Warnings: 2 | Info: 3
+
+AI Review:
+- OWASP Baseline: No critical issues
+- Stack-Adaptive (node, react): localStorage used for session token (SEC-REACT-001)
+
+Threat Model:
+- Entry points: 12 (8 REST endpoints, 2 WebSocket handlers, 2 CLI commands)
+- Trust boundaries: 4 (client→API, API→database, API→external service, CLI→filesystem)
+- High-risk flows:
+  1. POST /api/upload → file stored to disk without size limit or type validation
+  2. WebSocket message handler passes user data to eval-like template engine
+```

package/dist/agents/skills/gemini-cli/harness-security-review/skill.yaml

@@ -33,6 +33,7 @@ mcp:
     skill: harness-security-review
     path: string
 type: rigid
+tier: 3
 phases:
   - name: scan
     description: Run mechanical security scanner (skipped in changed-files mode)

package/dist/agents/skills/gemini-cli/harness-security-scan/skill.yaml

@@ -31,6 +31,7 @@ mcp:
     skill: harness-security-scan
     path: string
 type: rigid
+tier: 2
 phases:
   - name: scan
     description: Run SecurityScanner and filter by severity threshold

package/dist/agents/skills/gemini-cli/harness-skill-authoring/skill.yaml

@@ -26,6 +26,7 @@ mcp:
     skill: harness-skill-authoring
     path: string
 type: flexible
+tier: 1
 state:
   persistent: false
   files: []

package/dist/agents/skills/gemini-cli/harness-soundness-review/skill.yaml

@@ -29,6 +29,7 @@ mcp:
     skill: harness-soundness-review
     path: string
 type: rigid
+tier: 2
 phases:
   - name: check
     description: Run all checks for the current mode and classify findings