올해 보안 커뮤니티를 뒤흔든 현상 가운데 하나는 LLM이 보조한 취약점 신고의 폭증이다. 인기 오픈소스 프로젝트의 메인테이너들은 쏟아지는 신고를 처리하느라 기능 개발 속도를 늦추고 분류(triage) 작업에 매달려야 했다. 그런데 이 홍수의 반대편에 선 사람들에 대한 이야기는 상대적으로 덜 들린다. 시스템 관리자, SRE, 애플리케이션 보안(AppSec) 팀 역시 매일 새로 등장하는 CVE를 마주하고 있다. 각 CVE는 평가되어야 하고, 영향을 받는 소프트웨어는 업데이트되거나 수동으로 패치되어야 한다. 문제는 이 평가 작업 자체가 사람의 시간을 빨아들인다는 점이다.
이 지점에서 등장하는 것이 VEX(Vulnerability Exploitability eXchange)다. VEX는 특정 소프트웨어 제품이 알려진 취약점에 실제로 노출되어 있는지를 알려주는, 기계가 읽을 수 있는 보안 권고문이다. 단순히 '이 라이브러리에 CVE가 있다'가 아니라 '이 CVE가 당신의 제품에 실제로 영향을 주는가'를 다루기 때문에, 분류 과정을 자동화할 수 있다면 확장 가능한 취약점 관리의 열쇠가 될 수 있다. 다만 그 자동 생성이 현실적으로 가능한지는 늘 그렇듯 '상황에 따라 다르다'.
프로그래밍 언어 생태계에서는 이미 작동한다
원문은 먼저 Go 라이브러리를 예로 든다. golang.org/x/text v0.38.0을 사용하는 프로그램을 스캔하면, 2026년 10월 11일 기준으로 두 개의 취약점이 보고된다. GO-2026-5970과 GO-2026-6629다. 그러나 조금만 들여다보면 둘 다 해당 프로그램에는 영향을 주지 않는다. 전자는 golang.org/x/text/unicode/norm 패키지에만, 후자는 golang.org/x/text/secure/precis 패키지에만 존재하는데, 예제 프로그램은 둘 중 어느 것도 사용하지 않기 때문이다.
이런 판단을 사람이 직접 VEX 문서로 작성할 수도 있지만, 더 나은 길이 있다. 프로그래밍 언어는 고도로 구조화되어 있어 기계가 추론하기 쉽다. 게다가 Go 팀은 새 취약점을 기록할 때 ecosystem_specific 필드에 영향을 받는 임포트 경로와 심볼을 성실하게 남긴다. 이 정보가 govulncheck의 토대다. govulncheck은 소스 코드의 정적 분석과 Go 취약점 데이터베이스를 결합해, 실제로 애플리케이션에 영향을 줄 수 있는 보고만 걸러낸다. 이 정도 정밀도를 확보하면 Dependabot을 꺼두고 실제로 영향을 받을 때만 패치하는 운영도 상상해볼 수 있다.
운영체제 전체로 넘어가면 벽에 부딪힌다
문제는 언어 생태계를 벗어나 운영체제 수준으로 올라갈 때 발생한다. 원문은 하나의 Dockerfile 기반 OS를 스캔해 284개의 취약점을 얻고, 그중 CVE-2007-2768 한 건만 집중적으로 분류한다. 이 취약점은 sshd가 PAM을 통해 OPIE 일회용 비밀번호를 사용할 경우, 공격자가 로그인 프롬프트를 보고 특정 사용자명의 존재 여부를 알아낼 수 있다는 내용이다. 2007년부터 업스트림에서 수정되지 않은 채 남아 있다.
이 한 건을 수동으로 평가하려면 설정을 직접 확인해야 한다. 해당 시스템은 PAM이 활성화되어 있지만 keyboard-interactive 인증이 비활성화되어 있고, sshd가 PAM에 로그인 프롬프트를 넘기는 경로는 그것이 유일하다. 게다가 opie라는 이름의 모듈도 설정되어 있지 않다. 결론적으로 영향을 받지 않는다. 그러나 이런 수작업을 나머지 283개 취약점에 대해, 그것도 설정이 바뀔 때마다 반복하는 것은 현실적으로 불가능하다. 바로 이 반복 비용이 OS 수준 분류를 질식시키는 요인이다.
NixOS가 바꾸는 지점
NixOS가 특별한 이유는 바로 여기에 있다. 앞의 Docker 기반 예제와 거의 동일한 시스템을 NixOS로 구성하고, syft 대신 sbomnix로 SBOM을 생성해 같은 과정을 돌릴 수 있다. 핵심은 CVE-2007-2768이 특정 조건이 충족될 때만 영향을 준다는 사실을, NixOS에서는 선언적으로 코드화할 수 있다는 점이다. 더 나아가 그 조건이 여전히 성립할 때만 VEX 문구를 유지하도록 VEX 피드를 조건부로 생성할 수 있다. 조건이 깨지면 면제 판단도 자동으로 사라지므로, 설정 변경이 분류 결과와 어긋나는 위험이 줄어든다. 이렇게 해서 한 번 분류한 CVE는 깔끔하게 무시 처리된다.
이 접근의 비용 구조는 분명하다. 조건을 처음 구축하는 일은 상당한 노동이지만, 한 번 분류하고 코드화하고 나면 재검증 비용은 약간의 CI 오버헤드에 가까운, 거의 0에 수렴한다. 설정이 바뀔 때마다 사람이 다시 들여다볼 필요가 없다는 뜻이다. 저자는 자신의 NixOS 머신에서 이런 분류 작업을 해왔고, 그 결과를 nixos-vex라는 이름으로 오픈소스로 공개했다. 데스크톱과 서버 프로파일 데모도 함께 제공되며, 여기에는 nixos-vex에 내장된 다른 기능도 담겨 있다.
한국의 실무자에게 이 글이 주는 함의는 두 가지다. 첫째, 취약점 스캐너의 원시 출력만으로 패치 우선순위를 정하는 관행은 '영향받지 않는' 다수의 CVE에 자원을 낭비하게 만든다는 점이다. 선언적으로 구성 상태를 관리하는 시스템이라면 그 상태 자체를 면제 판단의 근거로 삼아 노이즈를 걷어낼 여지가 있다. 둘째, 그럼에도 저자 스스로 아직 이 결과물을 '높은 신뢰도의 데이터 소스'로 쓰지 말라고 분명히 선을 긋고 있다는 한계다. 저자의 목표는 완성된 도구의 배포가 아니라 과정의 공유와 피드백 수렴, 그리고 장차 Nix 생태계로의 기여다. 즉 이것은 즉시 도입할 솔루션이라기보다, 선언적 인프라가 취약점 분류를 어떻게 확장 가능하게 만들 수 있는지를 보여주는 하나의 실증에 가깝다.