근거로 남기는 예외 — VEX

한 줄 요약

"이 취약점은 우리에게 영향 없음" 이라는 판단을 말이나 스프레드시트가 아니라 기계가 읽을 수 있는 문서(VEX)로 남깁니다. 그래야 다음 스캔이 같은 줄을 다시 띄우지 않고, 그 판단에 근거가 있는지 검증할 수 있습니다.

왜 이게 필요했나

스캔을 돌릴 때마다 같은 "영향 없음" 취약점들이 빨간 줄로 다시 올라옵니다. 사람이 매번 "이건 우리가 안 쓰는 함수라 괜찮아" 를 기억으로 걸러 내면, 그 기억이 사람과 함께 떠나고 새 담당자는 처음부터 다시 판단합니다. 더 나쁜 것은 근거 없는 예외입니다 — "급하니까 일단 무시" 가 쌓이면 관문은 장식이 됩니다.

어떻게 동작하나

VEX(Vulnerability Exploitability eXchange)는 "이 제품이 이 취약점에 영향을 받는가" 를 적는 문서입니다. OpenVEX 가 그 공개 형식 중 하나입니다(https://github.com/openvex/spec). 각 statement 는 이렇게 생겼습니다.

{
  "vulnerability": {"name": "CVE-2026-2002"},
  "products": ["pkg:oci/payweb@1.4"],
  "status": "not_affected",
  "justification": "vulnerable_code_not_in_execute_path",
  "impact_statement": "서비스는 safe_load 만 쓴다. full_load 경로가 없다."
}

핵심은 status 와 justification 입니다. status 가 not_affected 이면 justification 이 반드시 있어야 합니다 — 왜 영향받지 않는지를 정해진 사유 코드(vulnerable_code_not_in_execute_path 등)로 적습니다. 근거 없는 not_affected 는 그냥 "무시" 이고, 좋은 관문은 그것을 인정하지 않습니다.

Trivy 는 --vex 로 이 문서를 받아, not_affected 로 표시된 취약점을 결과에서 걸러 줍니다. 그래서 VEX 는 "한 번 판단하고 기록하면, 도구가 그 판단을 매 스캔에 적용" 하는 구조를 만듭니다. 상태는 not_affected 말고도 affected(영향받음·고쳐야 함), fixed(이미 고침), under_investigation(조사 중)이 있습니다.

현장에서 만나는 모습

가장 중요한 규칙은 도달 가능한 취약점을 not_affected 로 덮지 않는 것입니다. VEX 는 조사 결과를 기록하는 도구이지 빨간 줄을 지우는 도구가 아닙니다. 도달 가능한데 VEX 로 덮으면 실제 위험을 숨기는 것이 됩니다. 그래서 관문은 두 가지를 봅니다 — not_affected 에 justification 이 있는가, 그리고 그 주장이 도달성 분석과 일치하는가.

English corner

VEX (vulnerability exploitability exchange): 취약점이 제품에 실제로 영향을 주는지 적는 문서입니다.
not_affected / affected: 영향 없음 / 영향 있음. VEX 의 상태 값입니다.
justification: 왜 영향받지 않는지의 근거 코드. not_affected 에 필수입니다.
suppress a finding: 발견을 억제한다. 근거 있는 VEX 는 올바른 억제, 근거 없는 무시는 위험한 억제입니다.

다음 퀴즈에서 할 것

VEX 의 상태와 근거가 관문에서 어떻게 쓰이는지, 근거 없는 예외가 왜 위험한지 확인합니다.

한 걸음 더 — 누가 VEX 를 쓰는가

VEX 는 두 방향으로 흐릅니다. 소프트웨어를 파는 쪽(공급자)이 '우리 제품은 이 CVE 에 영향받지 않는다' 를 고객에게 VEX 로 전하면, 고객은 그 제품의 그 CVE 를 조사하느라 시간을 쓰지 않아도 됩니다. 소프트웨어를 쓰는 쪽(운영자)은 자기 환경에서의 조사 결과를 VEX 로 남겨 다음 스캔과 다음 담당자에게 넘깁니다. 같은 형식이 공급망의 위아래를 잇습니다.

주의할 것은 VEX 가 '한 번 쓰면 끝' 이 아니라는 점입니다. 코드가 바뀌어 안 쓰던 함수를 쓰게 되면, 전에 not_affected 로 적은 판단이 더 이상 참이 아닙니다. 그래서 VEX statement 에는 어떤 제품 버전에 대한 판단인지(products 의 버전)를 적고, 버전이 올라가면 그 판단을 다시 확인합니다. 근거를 남기는 일은 한 번의 작성이 아니라 유지보수 대상입니다.

점검 순서

not_affected 에 justification 이 있는가(근거 없는 무시가 아닌가).
도달 가능한 취약점을 not_affected 로 덮지 않았는가.
어떤 제품 버전에 대한 판단인지 적혔는가.
관문이 근거 있는 VEX 만 인정하는가.