Files

T

2026-07-25 12:53:13 +09:00

title, source_type, status, related_branches, related_projects, tags, created, status_label, target_audience, inspiration_url, archive_url

title

source_type

status

related_branches

related_projects

blog-topic: trivy-suppression-governance-static-gate

Layer: raw/blog-topics/ — 작업·트러블슈팅에서 나온 블로그 글감 원석. status_label: captured

Parent / 부모

raw/branch-notes/feature-dependency-vulnerability-management-contract — D5 를 구현하며 "suppression 거버넌스를 빌드 게이트로 강제"한 경험에서 도출.

트리거 유형: branch-work
트리거 날짜: 2026-06-20
트리거 연결 노트: raw/branch-notes/feature-dependency-vulnerability-management-contract

한 문장 요지: 취약점 스캐너의 suppression 파일(.trivyignore.yaml)은 그대로 두면 만료일·사유 없는 영구 silent bypass 가 되기 쉬운데, 이걸 100줄짜리 Gradle 정적 게이트 하나로 빌드 차원에서 강제할 수 있다.
예상 제목 후보:
- ".trivyignore 가 백도어가 되지 않게: Gradle 정적 게이트로 suppression 거버넌스 강제하기"
- "보안 게이트의 게이트: suppression 에 만료일과 사유를 코드로 강제한 이야기"

사실 후보:
- Trivy 는 expired_at 이 없으면 suppression 을 영구 유효로 취급한다 — 근거 후보: raw/official-docs/trivy-filtering-suppression-policy C4.
- "정책(policy)"과 "강제(enforcement)"는 분리된다: 정책 문서(dependency-vulnerability-policy.md)는 사람이 읽고, 강제는 verifyTrivyignore gate + CODEOWNERS 가 한다 — 근거 후보: raw/branch-notes/feature-dependency-vulnerability-management-contract D5 §3.
경험 후보:
- line-based parser(YAML 라이브러리 없이, repo 의 verifyEnvKeys 스타일 답습)로 게이트를 만들고 6-케이스로 pass·fail 검증 — 근거 후보: 동 branch §진행 중 메모 2026-06-20.
- subprojects { check { dependsOn } } 배선으로 ./gradlew check 에 자동 편입 — 기존 4번째 verify 게이트로 합류.
의견/해석 후보:
- 보안 게이트를 도입할 때 우회 경로(suppression/ignore)를 같이 설계하지 않으면, 게이트는 도입 첫날부터 무력화될 수 있다. suppression governance 는 스캐너 도입의 후순위가 아니라 동시 작업이어야 한다.

문제: suppression 파일은 보안 게이트의 합법적 우회구 — 그러나 만료일·사유 없이 추가되면 영구 백도어 → 핵심 메시지: 우회구에도 통제가 필요하다.
Trivy .trivyignore.yaml 포맷과 expired_at 의 함정(누락=영구) → 핵심 메시지: 기본값이 "안전"의 반대.
이중 통제 설계: CI field-gate(verifyTrivyignore) + merge-gate(CODEOWNERS)가 왜 둘 다 필요한가 → 핵심 메시지: "누가 바꾸나"와 "무엇이 갖춰졌나"는 다른 축.
100줄 Gradle 게이트 구현 — line-based parser, 90일 창, 만료/창초과 검사, 6-케이스 검증 → 핵심 메시지: 가벼운 정적 게이트로 충분하다.
한계와 정직한 등급: locally-verified vs CI 실증(needs-confirmation) → 핵심 메시지: 게이트가 도는 것과 운영에서 막는 것은 다르다.

wiki/projects/ca-tmpl/dependency-vulnerability-suppression-gate.md 후보:
- verifyTrivyignore 게이트 설계 + 이중 통제 + UNSUPPORTED_IMPL_DECISION(90일) 의 ca-tmpl 적용 사실.
wiki/concepts/security-gate-suppression-governance.md 후보:
- "보안 게이트의 우회 경로도 거버넌스 대상" 이라는 일반 개념(스캐너 무관).
필요한 추가 검증:
- CI 러너에서 워크플로 + CODEOWNERS 실제 차단 실증, lockfile 커밋 후 Trivy fs 가 Gradle deps 를 실제로 스캔하는지.

아직 확인해야 할 사실: 만료된 suppression 이 release 직전 빌드를 깨뜨릴 때의 운영 흐름.
과장하면 안 되는 부분: 게이트는 locally-verified 다. "운영에서 취약점 우회를 막았다"는 아직 needs-confirmation.
블로그로 쓰기 전에 필요한 canonical 정제: ca-tmpl 적용 사실 → wiki/projects/, 일반 개념 → wiki/concepts/ 분리.

액션: promote-to-canonical
이유: wiki/projects/ca-tmpl/devops-ci-supply-chain-dx.md 에 Trivy suppression governance static gate 글감으로 반영했다.
다음 단계: target canonical이 아직 draft 이므로 blogify 전 review/verify가 필요하다. 운영에서 취약점 우회를 막았다고 쓰지 않는다.