/**
 * Pass: jwt-verify-disabled (CWE-347, category: security)
 *
 * Pattern pass — flags places where JWT signature verification is explicitly
 * disabled or set to the `none` algorithm. This is a configuration
 * vulnerability (the bad value is a hard-coded constant), not a taint flow.
 *
 * Detection per language:
 *   Python (PyJWT):
 *     - `jwt.decode(token, ..., options={"verify_signature": False})`
 *     - `jwt.decode(token, ..., verify=False)`         — pre-2.0 PyJWT
 *     - `jwt.decode(token, ..., algorithms=["none"])`  — accepts unsigned tokens
 *   JavaScript / TypeScript (jsonwebtoken):
 *     - `jwt.verify(token, secret, { algorithms: ['none'] })`
 *     - `jwt.verify(token, null, ...)` / `jwt.verify(token, '', ...)` — empty key
 *     - `jwt.verify(token, secret, { verify: false })` (rare)
 *   Java (auth0 java-jwt):
 *     - `JWT.require(Algorithm.none())`               — accepts `alg:none` tokens
 *   Java (jjwt 0.x):
 *     - `Jwts.parser().setSigningKey(...).parse(...)` — `parse` returns Jwt<?,?>
 *       without enforcing the signature; `parseClaimsJws()` is the safe form
 *
 * Aligned with: CWE-347, OWASP API Security Top 10 (API2:2023 broken auth),
 * Bandit B701 (jinja2_autoescape is unrelated — JWT has no direct Bandit rule
 * but PyJWT documents this as misuse).
 *
 * Issue: #86, Sprint 5.
 */
import type { AnalysisPass, PassContext } from '../../graph/analysis-pass.js';
export interface JwtVerifyDisabledResult {
    findings: Array<{
        line: number;
        language: string;
        pattern: string;
        api: string;
    }>;
}
export declare class JwtVerifyDisabledPass implements AnalysisPass<JwtVerifyDisabledResult> {
    readonly name = "jwt-verify-disabled";
    readonly category: "security";
    run(ctx: PassContext): JwtVerifyDisabledResult;
    private detect;
    private fixFor;
}
//# sourceMappingURL=jwt-verify-disabled-pass.d.ts.map