gitleaks 룰 메타데이터를 Finding severity/confidence에 매핑

[pureliture]

요약

GitleaksScanner.parse_report는 어떤 룰이 매칭됐든 모든 finding에 severity=HIGH, confidence=MEDIUM을 일괄 부여합니다. 소스에 이미 TODO로 남아 있습니다.

현재 동작

src/security_scanner/scanners/gitleaks/scanner.py:60-62:

_DEFAULT_SEVERITY = Severity.HIGH.value
_DEFAULT_CONFIDENCE = ConfidenceLevel.MEDIUM.value
# TODO(phase2): implement per-rule severity mapping based on gitleaks tags/rule metadata.

parse_report (대략 line 288-289)에서 모든 finding에 이 기본값이 적용됩니다. gitleaks JSON 출력에는 이미 RuleID와 Tags가 들어 있고 GitleaksFindingPayload.tags에도 채워지지만, 정작 finding 메타에는 반영되지 않습니다.

왜 중요한가

• gate / report가 aws-access-key-id(critical)와 generic-api-key(low signal)를 구분할 수 없습니다.
• Severity enum은 CRITICAL/HIGH/MEDIUM/LOW/INFO를 정의하지만 실제로는 HIGH만 생성됩니다.
• 후속 소비자(report renderer, evaluation)가 gitleaks 룰의 위험 신호를 그대로 잃습니다.

작업 제안

1. rule-id → (Severity, Confidence) 매핑 테이블 정의. 정의 위치 후보:
   • src/security_scanner/scanners/gitleaks/ 아래 룰팩과 함께 배포되는 YAML
   • 또는 gitleaks Tags에서 파생 (예: critical/high 태그 존재 여부)
2. parse_report에서 Finding.create 직전에 매핑 적용.
3. 매핑되지 않은 룰은 현재 default로 fallback하고 debug 로그 출력.
4. 매핑이 바뀌면 RULE_PACK_VERSION 갱신.
5. 테스트: tests/test_gitleaks_scanner.py에 서로 다른 severity 룰 3개 이상을 포함한 synthetic report 케이스 추가.

완료 기준

• eval/synthetic-corpus/gitleaks.synthetic.toml에 등장하는 룰들은 모두 명시적 severity/confidence를 가진다.
• evaluate 출력의 severity 분포가 100% HIGH가 아니다.
• TODO 주석 제거.