Discovery, verification, disclosure.

Declaration extraction

Source files are parsed into a structured map of the codebase — declarations, types, and module-level relationships. Tree-sitter parses identical source into identical maps; subsequent reconnaissance over the parsed map enriches it with semantic context. The map is the substrate that downstream stages query without re-reading raw source.

Per-module review

Each module is evaluated against a vulnerability taxonomy generated for the target project's threat model, with categories tagged against the CWE and OWASP standards^[1] for cross-reference. Stage 1's structural map provides full context. Output: a ranked list of candidates, each tied to its originating declaration with a confidence score.

Cross-module data flow

Candidates from § 1.2 are traced across module boundaries. The engine follows data from external sources through intermediate transformations to security-relevant sinks. Where an untrusted source crosses an authorization boundary unsanitized into a sink that can be coerced into an attacker-useful action, the path is surfaced as a verified candidate finding.

This is the class of vulnerability that spans multiple files — the class per-file static analysis tools routinely fail to detect, because the attack surface lives in the relationships between modules rather than within any single function.

Worked example: a bug-class shape

To illustrate the class of bug Stage 3 surfaces, consider an abstract example with three modules:

• Module A — a configuration loader that reads a key path from a user-supplied source.
• Module B — a payload verifier that validates incoming objects against a signing key fetched from the path supplied by Module A.
• Module C — an ingestion function that calls Module B's verifier on an artifact downloaded over the network.

Each module, examined alone, looks legitimate. Module A reads configuration; Module B verifies signatures; Module C processes incoming payloads. A per-file static analysis tool sees three reasonable functions. The vulnerability lives in the chain: the key path that drives signature verification is user-controllable, so an attacker who can influence Module A's input can replace the trust anchor and bypass Module B's defence.

Stage 3 surfaces this as a candidate by tracing the untrusted source (Module A's input) through the intermediate transformation (path resolution) into the security-relevant sink (Module B's signature check). The shape — source → unsanitized transformation → trusted sink — is the analysis primitive; the specific projects and CVE identifiers are published only after coordinated disclosure with the affected maintainer.

# Module A — config loader
def load_config(path: str) -> Config:
    return parse(read(path))  # path is user-supplied

# Module B — payload verifier
def verify(payload: bytes, key_path: str) -> bool:
    key = load_key(key_path)            # key_path comes from caller
    return cryptographic_check(payload, key)

# Module C — ingestion
def ingest(artifact_url: str, config: Config):
    payload = http_get(artifact_url)
    # ─ chained trust ───────────────────────────────────────
    # config.signing_key_path is reachable from user input via
    # Module A. The attacker controls the trust anchor.
    if verify(payload, config.signing_key_path):
        process(payload)