5.0 KiB
5.0 KiB
title, source_type, status, related_branches, related_projects, tags, created, status_label
| title | source_type | status | related_branches | related_projects | tags | created | status_label | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| interview-prep / trivy-suppression-dual-control-governance | interview-prep | raw |
|
|
|
2026-06-20 | collecting |
interview-prep: trivy-suppression-dual-control-governance
Layer:
raw/interviews/— 면접 질문 원본 수집·연구 노트.status_label:collecting
Parent / 부모
- raw/branch-notes/feature-dependency-vulnerability-management-contract — 이 branch 의 D5(Suppression governance) 를 구현하며 "취약점 suppression 을 어떻게 통제했나" 라는 질문이 자연스럽게 도출됨.
질문 / Question
- 질문 원문: "취약점 스캐너의 false-positive 나 accepted-risk 를 suppress 해야 할 때, 그 suppression 이 영구적인 silent bypass 가 되지 않도록 어떻게 통제했나요?"
- 출처: 예상 질문 (branch 작업에서 유추 — 2026-05-25 ca-tmpl audit 가 실제로 발견한 구멍)
- 받은 날짜·맥락: (예상)
질문 의도 추론 / Why this question
- 핵심 평가 대상: 운영 trade-off 인식 + 보안 게이트를 우회 가능하게 만들지 않는 설계 감각 + "정책과 강제(enforcement)의 분리".
- 함정 / 흔히 빠지는 답변 패턴: "
.trivyignore에 추가하면 된다" 로 끝내는 것 — 누가/언제까지/왜 suppress 했는지 통제하지 않으면 그 자체가 백도어가 된다. - 따라올 만한 후속 질문: "CODEOWNERS 만으로 충분하지 않은 이유는?", "만료일 상한은 왜 90일인가?", "이미 만료된 suppression 은 어떻게 처리되나?"
답변 재료 / Raw answer material
- 사실 1 (근거: raw/branch-notes/feature-dependency-vulnerability-management-contract D5): suppression 은 단일 구조화 파일
.trivyignore.yaml하나로만 허용. 인라인# trivy:ignore주석·CLI ad-hoc 무시는 금지. - 사실 2 (근거: 동 branch D5 §3): 이중 통제 — (a)
verifyTrivyignoreGradle gate 가 각 항목의statement(사유)·expired_at(만료일) 필드 존재/유효를 CI 에서 검증, (b).github/CODEOWNERS+ branch protection 이 파일 변경 자체에 보안 owner 승인을 merge-time 에 강제. 둘은 대체재가 아니라 보완재 — CODEOWNERS 는 "누가 바꾸나"만, gate 는 "필드가 갖춰졌나"만 잡는다. - 사실 3 (근거: raw/official-docs/trivy-filtering-suppression-policy C4): Trivy 는
expired_at이 없으면 영구 유효로 취급 → 만료일 누락 자체를 빌드 실패로 막아야 영구 ignore 를 차단할 수 있다. - 내가 직접 한 경험 (근거: 동 branch §진행 중 메모 2026-06-20):
verifyTrivyignore를 line-based parser 로 구현하고 6-케이스(누락/만료/창초과/유효/nested/빈seed)로 pass·fail 을 직접 검증../gradlew checkgreen. - 트레이드오프: 만료 창 길이 — 짧으면(예: 30일) 재검토 부담↑, 길면(예: 1년) 사실상 영구 ignore. 다수파/표준 없음 → team-policy 90일 default(
UNSUPPORTED_IMPL_DECISION로 명시). Trivy 공식 문서는expired_at필드 존재만 보장하고 상한은 권고하지 않는다. - 한계 / "이건 안 해봤다": 실제 CI 러너에서
.trivyignore.yaml변경 PR 이 CODEOWNERS 승인 없이 merge 차단되는지는 GitHub branch protection 설정에 의존 —needs-confirmation(로컬에선 Gradle gate 만 검증).
Sources / 근거 (답변의 사실 근거)
- raw/branch-notes/feature-dependency-vulnerability-management-contract — D5, §구현가이드 §3, §진행 중 메모.
- raw/official-docs/trivy-filtering-suppression-policy —
expired_at/statement필드 의미(C3·C4·C5).
미해결 / Unknown
- 모르는 것 1: CODEOWNERS protected-path 가 force-push/admin override 로 우회되는 경로의 잔여 리스크.
- 모르는 것 2: 만료된 suppression 이 release 직전에 갑자기 빌드를 깨뜨릴 때의 운영 핸드오프(누가 renew 책임).
- 확인 방법: GitHub branch protection 문서 재확인 + 테스트 repo 에서 만료일·사유 없는 row PR 로 CI fail + merge block 실증.
답변 경계 / Answer boundary
- 자신 있게 말할 수 있는 범위: Gradle gate 의 필드 검증 로직과 6-케이스 검증 결과(로컬), 이중 통제 설계의 이유.
- "공식 문서를 다시 보고 답변드리겠습니다" 라고 해야 하는 부분: GitHub CODEOWNERS+branch-protection 의 정확한 merge 차단 시맨틱, force-push 예외.
- 절대 과장하지 말 것: 이건
locally-verified(Gradle gate)다. CI 러너에서 워크플로/CODEOWNERS 가 실제로 차단하는 것은 아직 실증 안 함(needs-confirmation) — "운영에서 막아봤다"고 말하지 말 것.
Related / 관련
- 관련 블로그 글감: raw/blog-topics/trivy-suppression-governance-static-gate-2026-06-20
- 답변 derive 후 위치:
[[wiki/interview/...]](생성되면)