취약점이 수백 개인데 무엇부터 고쳐야 할까

문제와 판단 기준

보안 점검 결과를 열었는데 ‘높음’과 ‘치명적’이 화면을 채웁니다. 개발자는 이번 배포도 준비해야 하고 운영 담당자는 패치 때문에 서비스가 멈출까 걱정합니다. 점수순으로 정렬해도 무엇을 오늘 처리해야 하는지는 분명하지 않습니다.

이때 권하는 순서는 실제 사용하는 자산에 해당하는지 확인한 뒤, 악용 증거·공격 경로·업무 영향을 연결해 조치하는 것입니다. 긴급한 위험은 노출을 줄이는 작업과 수정 준비를 함께 시작하고 근거가 부족한 항목에는 확인 담당자와 시한을 붙입니다. 모른다는 이유로 낮은 위험으로 분류하지 않습니다.

목록의 정렬 기준도 ‘취약점 번호’에서 ‘어느 배포본의 어떤 위험을 누가 없앨 것인가’로 바꿔야 합니다. SSVC의 운영자 모델 역시 배포된 제품 버전과 수정·완화책을 연결한 개별 인스턴스를 판단 단위로 삼습니다.^[1]

CVSS·EPSS·KEV는 서로 다른 질문에 답한다

먼저 보안 도구에 함께 표시되는 정보를 구분합시다.

CVSS는 ‘기본 점수만으로 위험을 평가하지 말라’는 한계를 명시합니다. 그렇다고 CVSS 전체에 환경 정보가 없는 것은 아닙니다. v4.0에는 위협과 환경을 반영하는 지표가 있으며, CVSS-B·BT·BE·BTE를 구분합니다. 점수를 기록할 때는 버전, 사용한 지표 그룹, 평가 벡터도 함께 보존해야 합니다.^[2]

EPSS는 관측 가능한 취약점 집단을 대상으로 한 예측입니다. 특정 회사의 네트워크 구성이나 보완 통제를 반영한 침해 확률이 아닙니다. 새 취약점은 공개 정보가 충분하지 않을 수 있고, 관측되지 않은 악용도 존재할 수 있습니다. 낮은 값은 안전 판정이 아니며, 점수가 없는 항목을 0으로 채워서도 안 됩니다.^[3][4]

KEV와 EPSS가 다르게 보이는 것도 모순은 아닙니다. KEV는 실제 악용의 기록이고 EPSS는 앞을 내다보는 추정치입니다. 최근 악용이 확인된 취약점을 낮은 EPSS만으로 뒤로 보내서는 안 됩니다. 반대로 KEV 등재만으로 우리 서버가 이미 침해됐다고 단정할 수도 없습니다. 공개된 공격 재현 코드와 실제 악용 관측 역시 구분해야 합니다.^[1][3][5]

SSVC는 이런 신호를 행동으로 연결하는 판단 체계입니다. 운영자용 모델은 악용 상태, 시스템 노출, 공격 자동화 가능성, 사람의 안전과 조직의 임무에 미치는 영향을 살핍니다. CISA의 조정자용 접근과 개별 서비스를 운영하는 조직의 모델은 적용 역할이 다릅니다. 아래에서 제안하는 기록표는 이를 참고한 실무 설계이지, 공식 SSVC 결정표를 그대로 구현한 것은 아닙니다.^[1][6]

CISA의 미국 연방기관 대상 지침에 나오는 조치 기한을 모든 한국 기업의 공통 의무로 옮겨 쓰지 않는 것도 중요합니다. 조직에 적용되는 법령·계약·내부 기준은 별도로 확인하고 이 글의 조치 분류는 운영상의 제안으로 사용합니다.^[7]

정렬하기 전에, 실제로 고쳐야 할 대상을 확인한다

아래 순서는 코드·의존성 점검에서 이미 발견한 이슈를 수정 작업으로 바꾸기 위한 제안입니다. 영향 확인이 끝날 때까지 명백한 긴급 위험의 완화를 미루라는 뜻은 아닙니다.

첫째, 발견 위치와 실제 배포본을 연결합니다. 저장소 이름만 적지 말고 환경, 서비스, 배포 커밋 또는 이미지 식별자, 실제 설치 버전을 남깁니다. 의존성 선언 파일의 버전과 실행 중인 패키지가 일치하는지 확인하고 직접 의존성인지 다른 패키지를 통해 들어온 전이 의존성인지 구분합니다. 수정된 코드가 병합됐다는 기록만으로 운영 반영까지 끝났다고 처리하지 않습니다.

둘째, 운영용과 개발용을 나누되 개발용을 일괄 제외하지 않습니다. Dependabot은 지원되는 생태계에서 개발 의존성을 구분하고 scope:development로 필터링할 수 있습니다. 이 표시는 분류에 유용하지만 배포 자산의 안전을 증명하는 자료는 아닙니다. 실제 실행 위치와 입력·권한을 함께 확인해야 합니다.^[8] 예를 들어 개발 전용 도구가 신뢰하지 않는 변경을 처리하는 CI에서 실행되고 그 작업에 배포 권한까지 주어져 있다면, ‘개발용’이라는 이유만으로 후순위로 보낼 수 없습니다. 이는 도구의 등급이 아닌 해당 구성에 대한 위험 판단입니다.

셋째, 중복된 보고와 서로 다른 영향 자산을 구분합니다. 같은 취약점을 여러 스캐너가 보고했다면 하나의 수정 작업으로 묶을 수 있습니다. 다만 운영 API, 배치 작업, 다른 리전에 남은 배포본까지 하나의 완료 표시로 지우지 않도록 영향 자산 목록은 유지합니다. 반대로 같은 패키지 이름이어도 취약점과 수정 버전이 다르면 별도 판단이 필요합니다.

넷째, 공급자의 권고와 실제 조치 가능성을 대조합니다. 영향 버전, 필요한 설정, 수정 버전, 지원 상태, 우회 완화책을 원문에서 확인합니다. 전이 의존성은 상위 패키지 업데이트가 필요한지도 살핍니다. 패치가 없거나 지원이 끝났다면 버전 변경 외에 기능 비활성화, 의존성 교체, 격리 같은 선택지를 검토합니다. ‘수정 버전 없음’을 ‘할 일 없음’으로 처리하지 않습니다.

현재 배포본에 해당하지 않는다는 사실이 확인되면 적용 대상에서 제외한 이유를 기록합니다. 이것은 개발 환경에 남은 위험까지 없다는 뜻도, 스캐너의 탐지가 전부 오탐이라는 뜻도 아닙니다. OWASP 취약점 관리 가이드도 오탐 판단의 근거와 재평가, 담당자 지정, 예외의 주기적 검토를 별도 업무로 다룹니다.^[9]

‘도달하지 않는다’와 ‘아직 확인하지 못했다’를 분리한다

공격 경로를 볼 때는 두 질문을 나누는 편이 좋습니다. 신뢰하지 않는 입력이나 사용자가 해당 서비스에 접근할 수 있는가? 그 입력이 취약한 기능의 악용 조건까지 도달하는가?

첫 번째는 네트워크·인증·업무 흐름의 문제이고 두 번째는 코드·설정·실행 조건의 문제입니다. 내부망이라는 위치 정보만으로 두 질문 모두에 ‘아니오’를 답하지 않습니다. 예를 들어 외부에서 받은 파일을 내부 배치가 처리한다면, 내부 서비스의 직접 접속 여부와 별개로 그 파일의 처리 경로를 확인해야 합니다.

분석 도구가 쓰는 상태 이름도 읽어야 합니다. Semgrep Supply Chain은 reachable, conditionally reachable, unreachable, no reachability analysis를 구분합니다. 분석 결과 도달하지 않는다고 판단한 것과, 도달 가능성 분석 자체가 없는 것은 다릅니다.^[10]

팀의 이슈 기록에는 ‘확인됨·조건부·미확정’ 같은 증거 상태와 그 근거를 남기자. 이 상태는 이 글이 제안하는 기록 방식이며 공식 SSVC 입력값을 대신하지 않습니다. 미확정 항목에는 부족한 증거, 확인 담당자, 확인 시한이 필요합니다. 업무 영향이 클 가능성이 있다면 확인과 동시에 노출을 줄일 방법도 검토합니다.

도달 불가로 판단한 항목에는 판단 당시의 배포본과 설정을 묶어 둡니다. 코드·라우팅·인증·의존성 또는 배포 구성이 바뀌면 다시 판단합니다. 영구적인 제외 목록을 만들기보다, 어떤 조건이 유지되는 동안만 판단이 유효한지 적는 것입니다.

긴급도와 조치 방법을 따로 결정한다

아래 표는 편집자가 제안하는 운영 분류입니다. 특정 국제 표준의 필수 기한이나 점수 공식이 아닙니다. ‘얼마나 서둘러야 하는가’와 ‘어떤 방법으로 위험을 줄일 것인가’를 별도로 결정하는 데 사용합니다.

패치가 서비스에 미칠 영향은 조치 방법과 배포 순서를 바꾸는 근거입니다. 취약점의 위험이 낮아졌다는 근거는 아닙니다. 변경 위험이 크면 사전 검증, 제한 배포, 복구 절차를 준비합니다. 그동안 노출을 충분히 줄일 수 없고 잔여 위험도 받아들일 수 없다면, 영향을 받는 기능의 중단까지 의사결정 대상에 넣습니다.

임시 통제에는 적용 범위와 검증 결과가 필요합니다. 단순히 ‘WAF 사용 중’ 또는 ‘내부망’이라고 적는 대신, 문제의 경로를 무엇이 막고 있는지 확인합니다. OWASP 가이드는 예외 승인과 보완 통제, 정기 검토를 관리 과정에 포함합니다.^[9] 여기에 만료 시점과 조기 재검토 조건을 붙이는 방식을 권합니다. 통제가 해제되거나 새로운 공격 경로가 확인됐다면 정기 회의를 기다리지 않고 다시 판단합니다.

같은 긴급도 안에서는 하나의 검증된 수정으로 여러 고위험 자산을 함께 보호할 수 있는지 살펴볼 수 있습니다. 다만 고치기 쉬운 낮은 위험만 처리해 건수를 줄이는 방향으로 작업량 지표를 사용하지 않습니다. 가중치를 임의로 더한 점수보다 선택 이유를 한 문장으로 설명하는 편이 검토에 유리합니다.

자산 맥락을 포함한 조치 기록표

다음은 이 글에서 제안하는 기록 항목입니다. 새로운 관리 제품을 도입하기 전에 기존 이슈 관리 도구의 필드와 설명란부터 사용해도 됩니다. 민감한 로그·고객 데이터·인증정보는 붙여 넣지 말고 접근이 통제된 증거 위치를 참조합니다.

예를 들어 ‘EPSS가 낮아 보류’로 끝내지 않습니다. ‘운영 배포본에는 해당 패키지가 없음을 확인했고, 분리된 문서 빌드 환경의 잔여 이슈는 담당자가 정기 업데이트에서 처리합니다. 배포 방식이 바뀌면 재검토한다’처럼 대상과 근거가 드러나야 합니다.

같은 목록에서도 결론이 달라지는 여섯 가지 설계 예시

아래 사례는 전부 가상입니다. 실제 고객의 취약점, 실제 CVE 평가, IXC의 수행 결과가 아닙니다. 심각도 표현도 사례를 위한 스캐너 등급 가정이며 CVSS 점수를 새로 계산한 값이 아닙니다.

B가 A보다 스캐너 등급은 높아도 조치 순서가 뒤일 수 있습니다. 반대로 C는 ‘위험이 낮다’가 아니라 ‘판단에 필요한 증거가 부족하다’에 해당합니다. D처럼 외부 취약점 번호가 없는 자체 코드 결함도 실제 영향이 확인되면 우선순위 목록에 올라와야 합니다.

기록표에 C를 옮긴다면 결론은 ‘추가 확인 중’이고 남은 질문은 ‘외부 파일이 취약 조건을 충족하는 경로로 들어오는가’다. 확인 시한까지 결론을 못 내렸을 때 적용할 입력 제한과 승인 책임까지 정해 두면, 미확정 항목이 대기 목록에 묻히는 일을 막는 데 도움이 됩니다.

수정 완료는 배포와 재검증까지 포함한다

수정 PR이 병합됐을 때와 실제 영향 자산에서 위험이 제거됐을 때를 구분하는 종료 기준을 권합니다. 먼저 수정된 코드·의존성·설정이 대상 배포본에 반영됐는지 확인합니다. 여러 인스턴스 중 일부가 이전 버전으로 남아 있는지도 확인 범위에 넣습니다.

다음으로 소유하거나 명시적으로 허가받은 테스트 환경에서 원래의 취약 조건이 해소됐는지 검증하고 정상 사용자 기능과 데이터 처리도 회귀 테스트합니다. 스캐너 재실행은 그중 한 단계입니다. 어떤 보안 요구를 확인했는지 정리할 때는 OWASP ASVS를 참고합니다. 검토한 안정판은 5.0.0이며 요구사항을 인용할 때 버전과 식별자를 함께 남깁니다. ASVS를 참조했다는 사실만으로 보안 인증이나 전체 요구 충족을 주장하지 않습니다.^[11]

변경된 기능의 회귀 범위를 정리할 때는 변경별 회귀 테스트 범위 결정 워크북을 함께 활용하십시오. 이 글의 기록표는 취약점 조치의 근거를, 워크북은 변경 후 확인할 테스트 범위를 정리하는 용도입니다.

복구 절차도 점검합니다. 문제가 생겨 이전 이미지로 되돌렸을 때 취약점이 다시 들어오지 않는지, 재배포에 사용할 기본 이미지와 잠금 파일에도 수정이 반영됐는지 확인합니다. SSVC 문서 역시 롤백이나 오래된 소프트웨어의 재배포로 취약점이 재유입될 수 있음을 지적합니다.^[1]

마지막으로 종료 상태를 ‘수정·재검증 완료’, ‘해당 자산 비대상 확인’, ‘기한 있는 위험 수용’, ‘추가 확인 중’처럼 구분합시다. 위험 수용으로 숨긴 항목이나 아직 확인하지 않은 항목이 수정 실적으로 합쳐지지 않도록 하기 위해서입니다.

운영 지표도 이 구분을 따라가면 좋습니다. 중요 자산에 남은 미완화 위험, 영향 확인에 걸린 시간, 기한을 넘긴 예외, 재검증되지 않은 수정, 현재 배포 자산 중 점검 범위에 들어온 비율을 함께 봅시다. 발견 건수가 줄었더라도 스캔 대상이 빠지거나 예외가 늘어난 결과라면 위험 감소로 해석할 수 없습니다.

배포 자산과 담당자가 명확하고 변경량이 많지 않은 팀은 기존 이슈 관리 도구와 이 기록표만으로 시작해도 됩니다. 연결 대상이 늘어날수록 자동 수집·중복 정리의 필요성을 검토하고 중대한 영향의 경로를 팀이 판단하기 어렵거나 변경 검증 책임이 비어 있을 때는 외부 전문 검토를 고려합니다. 어느 경우든 다음 회의에서는 무엇을 수정했는지, 어떤 공격 경로가 닫혔는지, 어떤 위험이 누구의 책임으로 남아 있는지를 설명할 수 있어야 합니다.