/**
 * Security dimension — declarative scoring spec.
 *
 * Methodology: severity-dominant rating per ISO/IEC 5055 (automated
 * source code quality measures, CISQ-driven) layered with CVSS v4
 * (FIRST.org) for vulnerability severity bands. The spec encodes:
 *
 *   - Penalty deductions for secrets, private keys, `.env` in git,
 *     code-pattern findings (semgrep et al), and dependency
 *     vulnerabilities. Each penalty surfaces as a discrete Deduction
 *     with a human-readable reason.
 *   - Cap rules that bound the rating when specific blocker classes
 *     are present (see `src/scoring/STANDARDS.md` for the cap
 *     taxonomy):
 *       trust-broken (40)        — committed credentials
 *       uncertainty (65)         — dep-vuln scanner did not run
 *       fixable-finding (79)     — open HIGH/CRITICAL code finding
 *
 * The evaluator (`evaluateSpec`) consumes this spec + a
 * `SecurityScoreInput` and produces the canonical `ScoreResult`. Both
 * the health audit's Security dimension and the standalone
 * vulnerability scan call the same path — same input ⇒ same number
 * by construction.
 *
 * Adapters that build `SecurityScoreInput` from their domain data:
 *
 *   - Health side: `src/analyzers/security/shallow.ts:toSecurityScoreInput`
 *     reads from `ScoreInput { metrics, capabilities }`. Falls back
 *     to grep-based HealthMetrics counts when `capabilities.codePatterns`
 *     is absent (semgrep unavailable).
 *   - Standalone side: `src/analyzers/security/actions.ts:countsFromReport`
 *     reads from `SecurityReport.findings` by partitioning on rule +
 *     category.
 *
 * Both adapters land on this same `SecurityScoreInput` shape; both
 * dispatch through the same spec; both observe identical scores.
 */
import type { DimensionScoringSpec } from '../spec';
/** Severity counts shape, kept inline for clarity at call sites. */
interface SeverityCounts {
    critical: number;
    high: number;
    medium: number;
    low: number;
}
/**
 * Clean partition of the security signal universe. Each finding the
 * gather code emits maps to exactly one field — no double-counting,
 * no missed contributions. Both health-side and standalone-side
 * adapters produce this shape.
 */
export interface SecurityScoreInput {
    /** Gitleaks-detected secrets (hardcoded credentials, API keys). */
    secretFindings: number;
    /** Private key / cert files on disk (*.key, *.pem). */
    privateKeyFiles: number;
    /** .env files tracked in git. */
    envFilesInGit: number;
    /**
     * Semgrep code-pattern findings by severity. Includes eval/exec,
     * TLS verification disabled, SQL injection, XSS, CORS, SSRF, and
     * every other static-analysis pattern the active language packs'
     * rulesets cover.
     */
    codeFindings: SeverityCounts;
    /** Dependency-vulnerability counts unioned across active packs. */
    depVulns: SeverityCounts;
    /**
     * True if at least one active pack's depVulns gather reached
     * success OR cleanly reported `no-manifest`; false if any pack
     * returned `unavailable` (tool absent / no output / parse fail).
     *
     * When false, the `dep-vulns-unavailable` cap fires and bounds
     * the score at the uncertainty tier ceiling regardless of other
     * signals — dxkit can't honestly claim a top-tier score when it
     * couldn't actually scan the deps.
     *
     * Adapters MUST populate this from `DepVulnSummary.available`.
     */
    depVulnsAvailable: boolean;
}
export declare const SECURITY_SCORING_SPEC: DimensionScoringSpec<SecurityScoreInput>;
export {};
//# sourceMappingURL=security.d.ts.map