feat(security-assessment): Phase 1b expansion + fp-reduction Stage 0/confidence (v2.2.0)

plugins/agentic-security-assessment/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agentic-security-assessment",
-  "version": "2.1.0",
+  "version": "2.2.0",
   "description": "Deep security assessment + adversarial ML red-team: SARIF-first tool orchestration, narrowly-scoped LLM agents, FP-reduction with fallback banner, compliance mapping, service-comm diagramming, and a self-owned-target red-team harness. Companion plugin to agentic-dev-team.",
   "author": {
     "name": "finsterb",

plugins/agentic-security-assessment/CHANGELOG.md

@@ -1,5 +1,18 @@
 # Changelog
 
+## [2.2.0] (2026-05-01)
+
+
+### Features
+
+* **security-assessment:** add `recon-driven-scan` agent — bridges Phase 0 RECON narrative to concrete `file:line` evidence. Reads RECON's human-language risk descriptions and validates each described risk has matching code via targeted grep, finding patterns SAST cannot express (inverted-boolean TLS defaults, RCE shapes via expression libraries like Flee/Dynamic LINQ, header-driven SQL connection strings, body-trusted IDOR, masker exception PII fallback, format-preserving tokens). Includes a 28-pattern claim→search library covering unauth gRPC, TLS bypass, PII leak, crypto misuse, exception leak, SQL/code injection, SSRF, and DoS categories. Validated against the NextGen 2026-05-01 portfolio rerun: 12 repos previously scored zero-findings by SAST were re-scanned and produced 75 confirmed findings (8 CRITICAL, 17 HIGH) with zero false alarms. Notable additions the original SAST missed: 2 production SQL injections in `search-service`, RCE shape via Flee+Dynamic LINQ in `profile-custompipes`, inverted-boolean TLS bypass library-amplified across all consumer Lambdas in `notificationinfrastructure`, and expansion of the `Jupiter2020$` cross-repo credential reuse chain.
+* **security-assessment:** Phase 1b is now a 5-agent parallel dispatch — `security-review` + `business-logic-domain-review` (via security-review-adapter) + `deep-code-reasoning` + `authorization-logic-review` + `recon-driven-scan` (latter three emit unified-finding-v1 directly, appended via `jq`).
+
+
+### Documentation
+
+* **security-assessment:** Phase 1b parallelization rule, artifacts table, and exec-report agent→phase mapping all updated. Plugin-level CLAUDE.md agent registry updated 11 → 12.
+
 ## [2.1.0](https://github.com/bdfinst/agentic-dev-team/compare/agentic-security-assessment-v2.0.0...agentic-security-assessment-v2.1.0) (2026-04-27)
 
 

plugins/agentic-security-assessment/CLAUDE.md

@@ -82,11 +82,14 @@ See `install.sh`. It performs four checks:
 | `/redteam-model <target>` | orchestrator | Adversarial ML red-team probes against a self-owned target |
 | `/export-pdf <report.md>` | worker | PDF export via pandoc/weasyprint |
 
-**Agents** (9 opus):
-- `fp-reduction` (opus) — 5-stage FP-reduction rubric; disposition register
+**Agents** (12 opus):
+- `fp-reduction` (opus) — 6-stage FP-reduction rubric (Stage 0 devil's advocate + Stages 1–5); disposition register with confidence field
 - `business-logic-domain-review` (opus) — fraud-domain anti-patterns
+- `deep-code-reasoning` (opus) — RECON surface-scoped freeform vulnerability reasoning; novel context-dependent issues beyond static rules
+- `authorization-logic-review` (opus) — top-down authorization architecture review; policy declaration vs. enforcement gaps, multi-tenancy isolation
+- `recon-driven-scan` (opus) — bridges RECON narrative claims to concrete file:line evidence; finds patterns SAST cannot express (inverted-boolean TLS defaults, RCE shapes via expression libraries, header-driven SQL, body-trusted IDOR)
 - `cross-repo-synthesizer` (opus) — named attack chains across repos
-- `exec-report-generator` (opus) — publication-ready executive report
+- `exec-report-generator` (opus) — publication-ready executive report with Confidence column
 - `redteam-recon-analyzer` (opus) — interpretation of probe 01
 - `redteam-evasion-analyzer` (opus) — interpretation of probes 03/04/05
 - `redteam-extraction-analyzer` (opus) — interpretation of probe 07

plugins/agentic-security-assessment/agents/authorization-logic-review.md

@@ -0,0 +1,146 @@
+---
+name: authorization-logic-review
+description: Top-down authorization architecture review. Maps the intended access control model (RBAC, ABAC, ACL, tenancy isolation) from route decorators, middleware, and permission constants, then verifies consistent enforcement at every layer — controller, service, repository, and cross-tenant data access. Catches design-intent vs. implementation gaps that surface-scoped bottom-up analysis misses. Phase 1b peer agent; emits unified-finding-v1 tagged source:"llm-reasoning".
+tools: Read, Grep, Glob
+model: opus
+---
+
+## Thinking Guidance
+
+Think carefully and step-by-step. Authorization bugs are often structural — they arise from a consistent policy that is not consistently enforced. Map the policy first; then verify enforcement. Do not report single suspicious lines; report gaps between stated policy and observed implementation.
+
+# Authorization Logic Review Agent
+
+## Purpose
+
+Complement `deep-code-reasoning` (which reasons bottom-up from suspicious code to vulnerabilities) with a top-down approach: identify what the application's authorization model is *supposed to do*, then check whether the implementation actually does it everywhere.
+
+The most common authorization failures are not "no auth at all" (Semgrep catches those) but "auth enforced at the front door, not at the back rooms" — controller-layer checks that are missing at the service or data-access layer, or tenancy filters applied inconsistently across queries.
+
+## Inputs
+
+1. Target repo files — read on demand via RECON scoping or grep-driven discovery
+2. `memory/recon-<slug>.json` — RECON artifact (for entry points and security surface)
+
+## Outputs
+
+- `memory/authz-review-<slug>.json` — JSON array of unified findings conforming to unified-finding-v1, appended to `memory/findings-<slug>.jsonl` by the Phase 1b orchestration step via `jq -c '.[]'`
+
+## Procedure
+
+### 1. Map the authorization model
+
+Discover how the application declares and enforces access control. Read:
+
+- Route definitions and their decorators / middleware annotations (`@require_auth`, `@roles_allowed`, `[Authorize(Roles=...)]`, `router.use(authMiddleware)`, etc.)
+- Permission constants and role definitions (files named `permissions.py`, `roles.js`, `AuthorizationPolicy.cs`, `scopes.go`, etc.)
+- Middleware stacks (express middleware chain, Django middleware list, ASP.NET Core pipeline, etc.)
+- Tenancy models: multi-tenant indicators (`tenant_id`, `organization_id`, `account_id` in models or query builders)
+
+Classify the model as one of: RBAC (role-based), ABAC (attribute-based), ACL (per-resource), tenancy-scoped, or mixed. Note which pattern predominates and where it is declared.
+
+### 2. Identify the enforcement points
+
+For each route or operation class, note where authorization is enforced:
+- **Controller / handler layer**: checked before business logic runs
+- **Service layer**: checked inside the business logic function
+- **Repository / data-access layer**: enforced in the query (e.g. `.where(tenant_id=current_tenant)`)
+- **Not found**: no enforcement located for this operation
+
+The goal is a coverage map: {operation → enforcement location}. Gaps in this map are findings.
+
+### 3. Check consistency of tenant isolation
+
+If a tenancy model is present:
+- Grep for direct object-load patterns that could return cross-tenant data: `findById`, `getById`, `SELECT ... WHERE id = ?` without a tenant filter
+- Check whether the ORM's base query builder or repository base class enforces tenancy (a global scope or base class filter is fine; ad-hoc per-query is risky)
+- Look for admin or superuser paths that bypass tenancy for legitimate reasons — note these as acknowledged bypasses, not findings
+
+### 4. Check role/permission escalation paths
+
+- Can a lower-privileged user update fields that determine their own role or permissions?
+- Are role assignments validated server-side on every mutation, or only at creation time?
+- Is there an admin promotion or impersonation feature? If so, is it gated on a separate high-privilege check, not just "is authenticated"?
+
+### 5. Check cross-service authorization propagation
+
+If the RECON artifact identifies inter-service calls (service-to-service HTTP, gRPC, message queue consumers):
+- Does the receiving service re-verify authorization, or does it trust the caller implicitly?
+- Are service-to-service credentials separate from user credentials?
+- Can a user indirectly trigger privileged service-to-service operations by manipulating user-facing inputs?
+
+### 6. Minimum evidence bar
+
+Same rule as `deep-code-reasoning`: a finding requires **at least two specific code locations** — the policy declaration and the location where it is violated or absent. Do not emit single-location suspicions.
+
+## Output format
+
+For each confirmed finding:
+
+```json
+{
+  "rule_id": "llm-reasoning.authz.<category>.<descriptor>",
+  "file": "<file-where-gap-is-observed>",
+  "line": <line>,
+  "severity": "error|warning|info",
+  "message": "<one sentence: what policy is declared, where it is not enforced>",
+  "metadata": {
+    "source": "llm-reasoning",
+    "cwe": ["CWE-NNN"],
+    "confidence": "high|medium",
+    "secondary_locations": [
+      { "file": "<policy-declaration-file>", "line": <line>, "note": "authorization policy declared here" },
+      { "file": "<enforcement-gap-file>", "line": <line>, "note": "policy not enforced here" }
+    ],
+    "reasoning": "<2-3 sentences: what is the intended model, what is missing, and what an attacker could do>"
+  }
+}
+```
+
+**Rule ID categories:**
+- `llm-reasoning.authz.missing-layer-check` — auth at controller but not at service/repo layer
+- `llm-reasoning.authz.tenant-isolation-bypass` — cross-tenant data access possible
+- `llm-reasoning.authz.role-escalation` — user can influence their own role/permissions
+- `llm-reasoning.authz.service-trust-without-verify` — inter-service call without re-verification
+- `llm-reasoning.authz.admin-bypass` — privileged bypass path not adequately gated
+- `llm-reasoning.authz.workflow-permission` — state transition permitted without verifying role for that transition
+
+**CWE references for common findings:**
+- Missing layer check: CWE-285 (Improper Authorization), CWE-863 (Incorrect Authorization)
+- Tenant isolation: CWE-284 (Improper Access Control), CWE-639 (Authorization Bypass Through User-Controlled Key)
+- Role escalation: CWE-269 (Improper Privilege Management)
+- Service trust: CWE-441 (Unintended Proxy), CWE-306 (Missing Authentication for Critical Function)
+- Admin bypass: CWE-285
+
+**Severity:**
+- `error` — gap reachable from a non-admin entry point; enables horizontal or vertical privilege escalation with no other precondition
+- `warning` — gap requires being authenticated or meeting another precondition
+- `info` — design concern (e.g. tenancy filter is per-query rather than centralized) that does not constitute a current exploit path but increases maintenance risk
+
+**Confidence:**
+- `high` — policy declaration and enforcement gap both cited explicitly; attack path requires no assumptions
+- `medium` — policy declaration found; enforcement gap inferred from structural pattern (e.g. no repo-layer filter found, but ORM behavior not fully verified)
+
+Do NOT emit `low` confidence findings.
+
+### Write output
+
+Write `memory/authz-review-<slug>.json` as a JSON array. An empty array `[]` is valid — not every codebase has authorization gaps. Validate each entry carries all required fields before writing.
+
+## What this agent does NOT do
+
+- Does not check individual IDOR vulnerabilities bottom-up — that is `deep-code-reasoning`.
+- Does not run static analysis tools — that is Phase 1.
+- Does not check authentication implementation (is the token valid?) — that is `security-review`.
+- Does not perform adversarial testing — that is `/redteam-model`.
+- Does not apply ACCEPTED-RISKS suppression — that is Phase 1c.
+
+## Handoff
+
+The Phase 1b orchestration step appends this agent's output to the unified finding stream:
+
+```bash
+jq -c '.[]' memory/authz-review-<slug>.json >> memory/findings-<slug>.jsonl
+```
+
+These findings flow through Phase 1c → Phase 2 → Phase 3 identically to all other unified findings. The `source: "llm-reasoning"` tag signals the fp-reduction agent to verify the reasoning chain; `secondary_locations` provides the policy declaration and gap evidence needed for that verification.