False-positive 노이즈 필터(placeholder, low-entropy 값)의 소유 레이어 결정

[pureliture]

요약

흔한 노이즈 클래스 — 템플릿 placeholder(${VAR}, your_api_key, xxxxxx), example/dummy 값, 매우 낮은 엔트로피·짧은 문자열 — 이 현재는 그대로 Finding store까지 흘러가고, 오직 Ollama verifier(실행했을 때만)에 의존해 FALSE_POSITIVE로 마킹됩니다. verifier 이전 단계의 필터가 없습니다. 이 이슈는 필터의 소유 위치를 결정하고, 결정대로 구현하는 것이 목적입니다.

합리적인 배치 후보

(a) gitleaks 룰 안에서 처리. 각 룰 TOML에 allowlist.regexes와 entropy 임계값을 추가. Pros: 신규 코드 없음, gitleaks-native, 룰별 튜닝 가능. Cons: 기본 룰팩을 포크하거나 wrapping해 유지해야 하고, placeholder 목록이 룰마다 중복됨.

(b) GitleaksScanner.parse_report의 후처리 레이어. Finding.create 이전에 단일 cross-rule 필터(placeholder 정규식 셋 + 엔트로피/길이 하한) 적용. Pros: placeholder 목록 갱신 지점이 한 곳, gitleaks 원본 출력과 A/B 비교 쉬움. Cons: gitleaks가 내보낸 finding을 가리는 거라 명시적 로깅과 비활성화 스위치가 필요.

(c) Verifier-only (현 상태). 노이즈 컷을 전적으로 Ollama verifier에 위임. Pros: 룰 변경 없음. Cons: false positive 1건마다 verifier 비용·레이턴시, verifier는 선택적이고 비결정적, verify 안 한 보고서는 노이즈가 많음.

왜 중요한가

• (a) 또는 (b) 없이는 실제 코드베이스에 대한 report 출력이 ${...} placeholder와 example 값으로 도배되어 실제 신호가 묻힙니다.
• 코퍼스에 흔한 placeholder 형태가 포함되면 evaluate precision이 떨어집니다.

이 이슈의 산출물

1. 위 trade-off를 다룬 결정 기록을 docs/views/06-research-and-technical-decisions.md에 추가.
2. 결정에 따른 구현 follow-up 이슈 생성.
3. (b)로 결정될 경우: config 플래그로 동작 제어, 필터된 매치마다 debug 로그 출력.

완료 기준

• 결정이 문서화되고 본 이슈에 링크됨.
• 구현 follow-up 이슈가 열림.