취약점 목록을 읽는 방식이 바뀌는 순간

핵심 포인트가 모였습니다. 이제 비교 중심으로, 조회형 CVE 소비와 Git·JSON 기반 CVE 소비가 어디서 갈라지는지 본문을 엮겠습니다.

취약점 데이터를 다루는 방식은 오래도록 검색과 조회의 언어에 머물러 있었다. CVE는 웹 페이지에서 찾아보는 식별자였고, CSV나 XML은 다운로드용 부속물에 가까웠다. 필요한 것은 “무슨 취약점이 나왔는가”였고, 도구가 기대한 것도 “한 건씩 읽을 수 있는 정리된 항목”이었다. 그런데 공식 CVE 목록이 cvelistV5처럼 Git과 JSON 중심의 배포 모델로 이동하기 시작하면, 이 익숙한 감각은 꽤 빠르게 낡아진다. 이제 CVE는 단순히 읽는 문서가 아니라, 주기적으로 동기화하고 버전 차이를 해석하고 여러 출처의 컨테이너를 병합해야 하는 데이터 제품에 더 가까워진다.

이 변화가 과장처럼 들리지 않는 이유는, 바뀐 것이 파일 형식 하나가 아니기 때문이다. 예전 모델에서 핵심은 보기 좋은 결과였다. 지금 모델에서 핵심은 구조화된 원본과 배포 체계다. cvelistV5는 공식 CVE 목록을 CVE JSON 5 형식으로 담고, GitHub를 통해 내려받고, 정기적으로 갱신되는 캐시로서 소비된다. 이 말은 곧 보안 팀, 플랫폼 팀, 취약점 관리 도구, SBOM 파이프라인이 더 이상 “목록을 조회”하는 데서 끝나지 않는다는 뜻이다. 이제는 “무엇을 기준선으로 삼고”, “무엇을 델타로 적용하며”, “어느 스키마 버전으로 검증하고”, “서로 다른 컨테이너의 정보를 어떻게 합칠지”를 직접 결정해야 한다.

페이지를 읽는 사람과 저장소를 동기화하는 사람

가장 큰 차이는 시선의 방향이다. 조회 중심 모델에서는 사람이 중심이다. 검색창에 CVE ID를 넣고 설명을 읽고, 점수와 참고 링크를 확인하고, 내부 티켓에 옮겨 적으면 된다. 데이터가 조금 늦어도 대체로 참을 수 있다. 몇 개 필드가 비어 있어도 다른 출처에서 메울 수 있다. 중요한 것은 항목 단위의 이해다.

반면 Git과 JSON 중심 모델에서는 시스템이 중심이 된다. git pull이 곧 갱신 전략이 되고, baseline zip과 hourly delta zip이 곧 배포 리듬이 되며, dataVersion 필드는 파서와 검증기의 분기 조건이 된다. 사람은 결과를 보는 마지막 단계로 밀려나고, 그 앞단에서는 동기화, 검증, 병합, 색인, 중복 제거 같은 일이 먼저 벌어진다. 여기서 운영 난도가 갑자기 높아지는 이유는, 취약점 데이터가 더 구조화될수록 해석 책임도 소비자 쪽으로 내려오기 때문이다.

예전 방식이 문서를 배포했다면, 지금 방식은 상태를 배포한다. 오늘 새로 생긴 CVE만 중요한 것이 아니다. 기존 레코드가 수정되었는지, 날짜가 정규화되었는지, 참조 링크가 다른 컨테이너로 옮겨졌는지, 특정 스키마 minor version에서만 유효한 필드가 들어왔는지도 중요하다. 즉, 취약점 인텔리전스 소비가 단순 조회에서 변경 추적 문제로 바뀌는 순간이 온다.

JSON 5가 주는 선명함과 동시에 늘어나는 책임

CVE JSON 5 계열의 장점은 분명하다. 제품, 버전, 설명, 참조, 메트릭, 상태, 출처를 기계적으로 다루기 쉬워졌다. 특히 affected 구조는 단순 문자열 목록보다 훨씬 운영 친화적이다. 버전 범위, defaultStatus, lessThan, lessThanOrEqual, versionType 같은 표현은 “영향받는 버전이 어디까지인가”를 정형화한다. 사람이 읽기에는 다소 장황해 보일 수 있지만, 자동화 입장에서는 이게 바로 생명선이다. SBOM과 매칭할 때도, 특정 패키지 관리자 생태계와 엮을 때도, 결국 필요한 것은 구조다.

문제는 구조가 곧 정답은 아니라는 점이다. 구조가 늘어나면 오류의 표면도 넓어진다. CVE Record Format 5.1에서는 CVSS v4.0 지원, versionType의 확장, 필드 오타와 예상치 못한 속성을 더 엄격하게 잡아내는 방향이 강조됐다. 5.2에서는 PURL 지원이 추가되고 affected 항목의 허용 속성이 더 엄격해졌다. 이 변화는 겉으로 보기엔 “비파괴적 업데이트”에 가깝지만, 실제 운영에서는 자주 다른 의미를 갖는다. 데이터를 그냥 저장하는 소비자에게는 큰 일이 아닐 수 있어도, 스키마 검증을 수행하는 소비자에게는 곧바로 파이프라인 실패로 이어질 수 있다.

여기서 자주 터지는 함정이 하나 있다. 많은 시스템이 “공식 목록이니까 하나의 최신 스키마로 다 검증하면 되겠지”라고 생각한다는 점이다. 하지만 실제로는 레코드마다 dataVersion이 다를 수 있고, 일정 시점에는 5.0과 5.1 형식이 혼재할 수 있다. 운영 관점에서 중요한 것은 릴리스 날짜가 아니라 레코드가 스스로 선언하는 버전이다. 이 차이를 놓치면, 데이터 품질을 높이겠다고 붙인 validator가 오히려 ingestion 장애의 시작점이 된다.

하나의 CVE 안에 여러 목소리가 들어오는 시대

cvelistV5를 이해할 때 빼놓기 어려운 변화는 컨테이너 모델이다. CVE 레코드는 더 이상 단일 본문처럼 보지 않는 편이 낫다. 기본적으로 CNA 컨테이너가 있고, 여기에 CVE Program Container가 붙을 수 있으며, 추가로 ADP 컨테이너들이 들어올 수 있다. 특히 2024년 이후의 변화에서 중요한 것은, 프로그램 차원의 참조와 보강 정보가 별도 컨테이너를 통해 제공될 수 있다는 점이다.

이 구조는 왜 중요할까. 비교 대상이 단순해서 더 선명해진다. 과거의 익숙한 모델은 “한 CVE에는 한 세트의 사실”이라는 감각을 준다. 지금 모델은 “한 CVE에는 여러 참여자가 제공한 사실 묶음이 공존한다”는 쪽에 가깝다. 이건 훨씬 현실적이다. 최초 할당 기관이 제공한 설명, 프로그램 차원의 추가 참조, 별도 데이터 퍼블리셔가 더한 KEV나 SSVC, 누락된 CVSS·CWE·CPE 보강 정보는 같은 취약점을 보지만 출처와 목적이 다르다.

대신 소비자는 선택을 강요받는다. 예를 들어 참조 링크를 단일 목록으로 뽑아 보여줄 것인가, 아니면 출처별로 보존할 것인가. 중복 링크가 나타났을 때 단순 dedup을 할 것인가, 아니면 “누가 같은 링크를 지지했는가”라는 맥락까지 남길 것인가. KEV와 같은 강화 정보가 ADP 컨테이너에 들어올 때, 이것을 원본 CNA 진술과 동일한 가중치로 보여줄 것인가. 조회형 UI에서는 이 차이가 잘 보이지 않지만, 실제 우선순위 결정 엔진이나 위험 점수 계산에서는 바로 영향을 준다.

한마디로 말하면, CVE 레코드는 점점 문서가 아니라 합성물에 가까워지고 있다. 이 사실을 무시한 설계는 처음에는 단순하고 예뻐 보이지만, 나중에는 정보를 잃는다.

다운로드가 아니라 동기화라는 발상

공식 목록이 Git 저장소와 릴리스 자산으로 배포되기 시작하면, 보안 데이터 소비의 핵심 단어도 바뀐다. download보다 sync가 더 중요해진다. 이 차이는 작지 않다.

다운로드 중심 사고에서는 파일을 받아서 파싱하면 끝난다. 정기 배치 작업이 하루 한 번 돌아도 큰 문제가 없다. 그러나 동기화 중심 사고에서는 기준선과 델타를 어떻게 구성하느냐가 곧 비용과 신뢰도를 좌우한다. cvelistV5가 baseline zip과 hourly delta zip을 함께 제공하는 이유도 여기에 있다. 하루 한 번 전체 기준선을 잡고 시간 단위 갱신을 얹는 방식은, 매번 전체를 다시 받는 것보다 훨씬 현실적이다. Git을 사용할 수 있다면 더욱 그렇다. 변경점만 가져오는 모델은 취약점 데이터처럼 누적량이 크고 수정이 잦은 정보에 특히 잘 맞는다.

하지만 이 방식은 새로운 실수를 부른다. 첫째, 동기화를 단지 “새 CVE 추가”로 이해하는 실수다. 실제로는 기존 레코드 수정이 훨씬 더 까다롭다. 설명이 바뀔 수 있고, 날짜가 정정될 수 있고, 참조가 이동할 수 있고, 보강 데이터가 뒤늦게 붙을 수 있다. 둘째, hourly delta를 이벤트 스트림처럼 오해하는 실수다. hourly delta는 편리한 운영 자산이지만 메시지 큐가 아니다. 중간 구간을 놓쳤을 때 복구 전략이 필요하고, baseline과의 관계를 분명히 해야 한다. 셋째, Git을 쓴다고 해서 곧바로 실시간 시스템이 되는 것은 아니다. 커밋 단위 변경과 운영상 요구하는 near-real-time 대응 사이에는 여전히 지연과 정책의 간극이 존재한다.

그래서 좋은 설계는 보통 세 가지 레이어를 가진다. 원본 mirror 레이어, 정규화 레이어, 서비스 레이어다. 원본 mirror는 가급적 CVE 측 구조를 손상 없이 보존한다. 정규화는 컨테이너 병합, dedup, 버전 해석, 내부 식별자 매핑을 담당한다. 서비스 레이어는 검색, 대시보드, 정책 엔진, 티켓 자동화를 담당한다. 이 셋을 섞어버리면, 스키마 변경이 UI 장애로 직결되고, 작은 날짜 보정이 전체 자산 재색인으로 번진다.

운영에서 먼저 보이는 신호는 내용 오류가 아니다

취약점 데이터 파이프라인은 종종 “설명 문자열이 이상하다”는 식으로 깨지지 않는다. 훨씬 먼저 보이는 것은 운영 신호다. 평소보다 수정 레코드 수가 급증한다든가, 날짜 필드 기반 통계가 갑자기 튄다든가, 특정 minor version 이후 validator 에러가 늘어난다든가, 참조 dedup 비율이 급변한다든가 하는 식이다.

이 지점에서 cvelistV5의 공지성 정보는 의외로 중요한 힌트가 된다. 날짜 정규화로 인해 대량의 레코드 수정이 발생할 수 있고, 수정 이력 보조 파일의 보존 기간이 일시적으로 줄어들 수 있다는 식의 신호는 “공식 데이터도 운영상의 이유로 표현 방식이 달라질 수 있다”는 사실을 보여준다. 보안 데이터 소비자는 흔히 원본을 절대 기준선으로 상상하지만, 실제 배포 시스템은 늘 용량, 처리 시간, 호환성, 마이그레이션 부담과 타협한다.

이때 현장에서 꼭 필요한 태도는 의심이 아니라 관찰이다. 예를 들어 대시보드에서 “이번 주 신규 CVE 수가 급감했다”는 경보가 울렸다고 하자. 이게 세상에 취약점이 줄어서가 아니라, 날짜 보정이나 파서의 스키마 분기 실패 때문일 가능성이 더 크다. 반대로 특정 벤더의 위험 지표가 갑자기 치솟을 때도 실제 취약점 폭증이 아니라 컨테이너 병합 정책 변경이 원인일 수 있다. 운영은 종종 내용보다 형식에 먼저 흔들린다.

비교의 기준이 달라지면 도구의 가치도 달라진다

이 변화를 이해하면 왜 어떤 팀은 여전히 단순 피드 소비에 머무르고, 어떤 팀은 Git mirror와 자체 인덱서를 갖추려 하는지 설명이 쉬워진다. 전자는 속도가 느려도 사람이 해석할 여지가 많은 환경에 적합하다. 후자는 SBOM, 자산 인벤토리, 노출 분석, 예외 관리, 패치 SLA를 자동화해야 하는 환경에 적합하다.

흥미로운 점은, 더 구조화된 데이터가 언제나 더 쉬운 운영을 의미하지는 않는다는 것이다. 오히려 구조화가 잘될수록 설계 판단이 노출된다. 예를 들어 PURL 지원은 분명 반가운 변화다. 패키지 생태계와 더 자연스럽게 연결되고, SBOM 매칭의 정확도를 높일 여지가 생긴다. 하지만 동시에 “사람이 이해하는 제품명과 기계가 추적하는 패키지 식별자를 어떻게 정렬할 것인가”라는 새 과제를 연다. PURL 안에 버전을 중복 표기하지 말라는 제약도 같은 맥락이다. 구조가 많아질수록 각 필드의 책임 경계도 더 엄격해진다.

CVSS v4.0 지원 역시 마찬가지다. 더 많은 맥락은 더 나은 판단을 도와줄 수 있다. 하지만 모든 소비자가 즉시 그 이점을 누리는 것은 아니다. 어떤 조직은 여전히 v3.x 중심 정책을 쓰고, 어떤 조직은 점수보다 KEV 여부를 더 중시하며, 어떤 조직은 아예 vendor advisory와 내부 자산 노출도를 우선한다. 즉, cvelistV5가 더 풍부해질수록 모든 팀이 같은 풍부함을 같은 방식으로 쓰는 것은 아니라는 점을 받아들여야 한다.

결국 바뀌는 것은 취약점 목록이 아니라 소비자의 역할이다

공식 CVE 목록이 Git과 JSON 중심으로 이동한다는 사실은, 표면적으로는 배포 방식의 현대화처럼 보인다. 하지만 더 깊게 보면 이는 역할 재배치다. 예전에는 중앙에서 보기 좋게 정리된 목록을 내려주고, 소비자는 그걸 읽고 참조하면 됐다. 지금은 중앙이 구조화된 원본과 업데이트 리듬을 제공하고, 소비자는 그 위에 자기만의 해석 계층을 세워야 한다.

그래서 이 변화는 보안팀만의 이야기가 아니다. DevSecOps, Threat Intelligence, 자산 관리, SBOM 운영, 심지어 데이터 플랫폼 설계와도 연결된다. CVE를 제대로 소비한다는 말은 더 이상 “취약점 정보를 가져온다”는 뜻이 아니다. 어떤 레코드를 어느 시점의 기준선으로 볼지, 어떤 컨테이너를 병합할지, 어떤 스키마 버전을 수용할지, 어떤 필드를 정책 엔진에 투입할지 결정하는 일까지 포함한다.

작은 예시 하나만 들어보자. 같은 CVE라도 내부 시스템이 이렇게 읽기 시작하는 순간, 운영의 질이 달라진다.

{
  "dataVersion": "5.1",
  "cveMetadata": {
    "cveId": "CVE-2024-XXXX",
    "dateUpdated": "2024-08-01T10:00:00Z"
  },
  "containers": {
    "cna": { "...": "원 할당 기관 정보" },
    "adp": [
      { "title": "CVE Program Container", "...": "프로그램 추가 참조" },
      { "title": "CISA-ADP", "...": "KEV 또는 Vulnrichment" }
    ]
  }
}

이 구조가 말해주는 것은 단순하다. 한 행짜리 CSV처럼 다루지 말라는 것이다. 이 CVE는 최소한 버전 분기와 컨테이너 병합을 전제로 읽어야 한다. 그 전제를 이해하는 팀은 데이터를 자산으로 만들고, 그렇지 못한 팀은 더 많은 JSON을 받아놓고도 예전보다 덜 확신하게 된다.

취약점 목록을 읽는 방식이 바뀌는 순간은 대개 조용하다. 검색 화면은 여전히 있고, CVE ID는 여전히 익숙하며, JSON도 낯설지 않다. 그러나 운영은 이미 다른 게임을 시작했다. 공식 목록이 저장소로 배포되고, 스키마가 진화하고, 컨테이너가 늘어나고, 동기화 전략이 설계 문제가 되는 순간부터 CVE는 더 이상 “조회용 페이지의 뒷면”이 아니다. 그것은 버전과 출처와 시간축을 가진 보안 데이터 공급망이다. 이 사실을 이해하는 것만으로도 취약점 관리의 해상도는 한 단계 올라간다.

댓글

댓글을 읽어오는 중입니다.