AppSec Review / System map

From code to a defensible finding.

How accepted analysis and tag-cloud context feed bounded OWASP assessment before hunting, adversarial review, independent verification and deterministic policy.

OWASP assessment · enabled by defaultUpdated · 28 October 2026Interactive · offline · exportable
Implemented path*Planned extensionDiscussion proposal
01 — The review, end to endSelect a process to inspect its contract
Application security review process Accepted analysis feeds prioritization, code graph and security tagging. Their bounded tag-cloud and classification context routes default-enabled OWASP assessment before indexing, packages, hunting and red/blue/independent verification. Tags are not control proof. OWASP worker and fresh blinded reviewer assessments stay scoped and provisional; all PRECOMPUTED interpretations are indirect for every final predicate. Original evidence must be retrieved. Family-specific policy decides claims, followed by scoring and final publication. Optional proof-of-concept functions are compiled but never executed.
*Implemented means the code path exists, not full coverage. OWASP assessment is enabled by default across shipped profiles, with an explicit job-level opt-out; complete pinned catalogs do not imply more than the four supported narrow Python static procedures. Qualification is synthetic and never production-eligible. Live-model OWASP efficacy, runtime adapters, exploit confirmation and safety certification are not established. Direct CLI and Dagster share the enabled tagging/OWASP chain, not full graph parity: CI/post-build branches and standalone metadata sync retain their existing scope. PoC generation is shipped disabled; HTML/PDF report rendering is manual. Arrows summarize information dependencies, not exact scheduling.

02 — Remaining planned extensions

Not part of the current executable review path
Planned attack-chain analysis, feedback and remediation Adjudicated claims can feed planned attack-chain composition and independent refutation. New evidence feeds bounded variant hunts and re-adjudication. Planned remediation consumes only confirmed findings; missing remediation does not block the current report and is recorded as a limitation.
The implemented PoC contract is compile-only: no pipeline executor, no observed trigger, no runtime result. Planned evidence feedback still requires re-resolution and deterministic adjudication. Missing remediation and chain stages are named report limitations, not clean results.
Discussion proposal · not implemented

A separate gate for critical-impact claims

Keep vulnerability confirmation separate from validation of the claimed critical impact. Before asserting that impact, require one coherent attack scenario, a source-linked entry-to-impact path, and an independent attempt to falsify it. If proof is incomplete, retain a visible verification backlog item rather than treating uncertainty as safety.

Real entry pointSame build + configurationImpact actually supportedStrongest defense challengedExplicit remaining gaps