취약점 경고는 점수보다 실행 경로와 노출을 먼저 본다

Larry

보안 스캔 결과가 수백 건씩 쌓이면 일단 심각도 점수부터 보게 된다. 하지만 가장 높은 점수가 반드시 가장 급한 위험을 뜻하지는 않는다. 취약한 패키지가 설치돼 있어도 서비스가 문제의 코드를 실행하지 않을 수 있다. 반대로 점수는 상대적으로 낮더라도 공개된 진입점과 연결돼 있고 실제 악용 징후까지 나타난 항목이라면 즉시 대응해야 한다.

그래서 취약점 경고에는 서로 다른 두 가지 결론이 필요하다. 위험 긴급도는 지금 조사와 보고 수준을 높이거나 노출을 제한해야 하는지를 나타낸다. 배포 준비 상태는 수정본에 담당자, 시험 결과, 검증 방법, 변경 범위와 롤백 계획이 갖춰졌는지를 보여 준다. 위험한 항목에 담당자가 없다고 해서 위험도가 내려가는 것은 아니다. 다만 책임 공백을 서둘러 메워야 하고, 준비되지 않은 수정본은 운영 환경에 올릴 수 없다는 뜻이다.

Tenable은 2026년 7월 15일 발표에서 애플리케이션 보안 데이터를 조직의 노출 맥락과 결합하고, 코드에서 실행 환경까지 이어지는 경로를 살펴 현실적인 위험을 구분하는 접근을 설명했다. 이런 정보는 조사에 유용하지만 개별 서비스의 최종 판단을 대신하지는 않는다. 현장에서는 실제 악용 신호와 기술적 영향, 자산 중요도, 보완 통제, 배포 조건까지 함께 확인해야 한다.

점수 대신 판단을 바꾸는 증거를 모은다

첫 번째로 볼 것은 실행 가능성이다. 의존성 목록에 취약한 패키지가 있다는 사실과 서비스가 문제의 함수·모듈·실행 파일을 실제로 호출한다는 사실은 다르다. 호출 관계와 실행 추적을 확인하고, 필요하면 재현 테스트를 통해 문제의 동작까지 도달하는지 살핀다.

실행 경로가 확인됐다면 그 경로에 어떤 데이터가 들어오는지 추적한다. 공개 진입점뿐 아니라 낮은 권한의 내부 계정, 다른 시스템에서 전달된 데이터처럼 신뢰하기 어려운 입력도 대상이다. 네트워크가 내부에 있다는 이유만으로 안전하다고 단정해서는 안 된다. 진입점, 입력 출처, 접근 권한과 네트워크 위치를 함께 봐야 실제 노출을 판단할 수 있다.

다만 실행 가능성과 노출만으로 모든 결론이 자동 결정되지는 않는다. 알려진 악용이나 진행 중인 공격이 있다면 실행 경로 조사가 끝날 때까지 기다리지 말고 사람이 대응 수준을 높여야 한다. 그런 신호가 없을 때는 예상되는 기술적 영향, 자산 중요도와 보완 통제를 함께 놓고 다음 행동을 고른다.

증거 상태	다음 행동
알려진 악용이나 진행 중인 공격이 있다. 또는 취약한 동작까지 도달할 수 있고 신뢰하기 어려운 입력에 노출되며, 영향이 중대하거나 핵심 자산과 연결된다. 악용 신호나 핵심 자산이 있는 상황에서 중대한 증거 공백이 남은 경우도 포함한다.	즉시 대응: 곧바로 사람에게 상향 보고하고 필요하면 되돌릴 수 있는 임시 차단을 검토한다. 수정·검증·배포 책임자를 지정하되, 시험과 롤백 준비가 확인되기 전에는 운영 배포를 승인하지 않는다.
즉시 대응 조건은 아직 없지만 실행 가능성, 노출, 영향, 자산 중요도 또는 보완 통제 중 하나 이상이 불명확하다.	기한 내 검증: 무엇을 어떻게 확인할지 정하고 담당자와 완료 기한을 기록한다. 새 신호가 발견되면 사람이 대응 수준을 다시 판단한다. AI가 경고를 종료하거나 변경 사항을 자동 배포해서는 안 된다.
재현 가능한 증거가 실행 불가, 신뢰하기 어려운 입력 경로의 부재 또는 효과적인 보완 통제를 뒷받침한다. 알려진 악용, 진행 중인 공격과 중대한 노출도 없다.	보류 후 추적: 판단 근거와 유효기간, 재검토 조건을 남긴다. 구조, 진입점, 권한, 패키지 버전이나 공격 정보가 바뀌면 카드를 다시 연다.

심각도 점수는 잠재적인 기술 영향을 설명하지만 우리 환경에서 공격 경로가 열려 있는지까지 알려 주지는 않는다. CISA의 SSVC는 단일 점수 대신 상황별 의사결정 신호를 활용하는 참고 틀을 제공한다. 관련 정보 가운데 KEV는 실제 악용이 확인된 취약점 목록이며, CSAF는 보안 권고를 시스템이 읽을 수 있도록 표현하는 표준 형식이다. VEX는 특정 제품이나 버전이 해당 취약점의 영향을 받는지 전달하는 상태 정보다. 모두 조사 순서를 정하는 데 도움을 주지만, 서비스에서 수집한 증거나 운영 배포 조건을 대체하지는 않는다.

한 취약점에는 한 장의 증거 카드를 쓴다

카드에는 먼저 대상 서비스와 구성 요소, 확인된 버전, 스캔 시각과 도구의 주장을 적는다. 이후 알려진 악용 및 공격 징후, 호출 관계와 실행 추적, 재현 결과, 진입점과 입력 출처, 권한과 네트워크 위치를 기록한다. 예상 영향과 자산 중요도, 현재 작동 중인 보완 통제도 빠뜨리지 않는다. 자료가 없으면 추정값으로 메우지 말고 ‘확인 필요’라고 표시한 뒤 확인 방법, 담당자와 기한을 붙인다.

카드의 결론은 위험과 배포를 분리해서 기록한다. 위험 판정에는 표에 나온 ‘즉시 대응’, ‘기한 내 검증’, ‘보류 후 추적’ 가운데 하나만 쓴다. 배포 준비 상태에는 다음 세 값만 허용한다.

사람 검토 준비(READY_FOR_HUMAN_REVIEW): 담당자, 시험 결과, 검증 방법, 변경 범위와 롤백 계획이 모두 갖춰졌다. 사람이 검토할 수 있다는 의미이지 배포 승인은 아니다.
준비 안 됨(NOT_READY): 필요한 배포 조건 가운데 하나 이상이 빠졌다는 사실이 확인됐다.
확인 필요(TO_CONFIRM): 정보가 부족해 준비 여부를 아직 판단할 수 없다.

따라서 같은 카드에 ‘즉시 대응’과 ‘준비 안 됨’이 함께 적힐 수 있다. 위험 보고와 되돌릴 수 있는 임시 차단은 서두르되, 검증되지 않은 수정본의 운영 배포는 막아야 하는 상황이다. 반대로 ‘사람 검토 준비’가 표시됐더라도 담당자가 변경 내용과 검증 결과를 살펴 승인하기 전에는 배포할 수 없다.

GitHub Docs의 보안·품질 AI 기능 responsible-use 문서는 사용자가 기능의 한계를 이해하고 결과를 직접 검토해야 한다고 안내한다. 이 문서는 2026년 7월 17일에 접속해 확인했다. AI는 카드 초안을 만들고 로그를 정리하거나 빠진 증거와 조사할 코드 경로를 제시할 수 있다. 그러나 위험 판정 확정, 경고 종료, 임시 차단 승인, 수정 승인과 운영 배포는 결과에 책임지는 사람이 결정해야 한다.

역할 구분이 더 필요하다면 AI는 취약점 분석을 맡고, 배포 승인은 사람이 맡는다에서 사람에게 남겨야 할 권한을 확인할 수 있다. 컨테이너 경고를 처리할 때는 Docker 스캐너 경고가 많을 때는, 이 이미지에 실제 영향이 있는지 먼저 판단한 뒤 AI 역할을 나누기의 실행 경로 점검 절차도 함께 적용할 수 있다.

다섯 건으로 업무 흐름을 시험한다

처음부터 모든 경고를 카드로 옮길 필요는 없다. 한 서비스에서 성격이 다른 다섯 건을 고른다. 실제 악용 정보가 있는 항목, 실행 경로와 외부 입력이 연결된 핵심 기능, 점수는 높지만 실행되지 않을 가능성이 있는 항목, 보완 통제가 효과적으로 보이는 항목, 증거가 부족한 항목을 섞으면 판단 기준의 빈틈을 찾기 쉽다.

서비스 담당자와 보안 담당자가 각 카드의 위험 판정과 배포 준비 상태를 정한 뒤 기존 점수순 목록과 비교한다. 결론을 내리기 어렵다면 AI에게 더 긴 설명을 요구할 것이 아니라, 어떤 증거가 들어오면 판단이 바뀌는지 찾아야 한다. 확인 방법과 책임자, 기한을 정하고 다섯 장에서 반복해 비어 있던 필드를 서비스 인수인계나 구조 변경 절차에 연결한다.

이 실습의 목적은 오늘 모든 경고를 닫는 데 있지 않다. 담당자가 없거나 조사가 덜 됐다는 이유로 긴급한 위험을 놓치지 않으면서, 시험과 검증을 거치지 않은 수정본도 자동으로 운영 환경에 들어가지 못하게 만드는 것이 목표다.

AI 정리 카드

지금 접근할 수 있는 저장소, 프로젝트 디렉터리, 취약점 스캔 결과, CI 기록과 작업 환경에서 조사를 시작한다. 파일이나 설정, 이슈, 경보, 작업 상태를 바꾸지 말고 읽기 전용 방식으로 코드, 의존성 manifest와 lockfile, 보안 보고서, 로그, 버전 정보를 살핀다. 그 증거를 바탕으로 취약점 처리 과정에서 개선할 가치가 가장 큰 구체적 문제 하나만 고른다. 사용자가 자료를 미리 정리하거나 붙여 넣어야 한다고 전제하지 않는다.

결과는 다음 의사결정에 바로 쓸 수 있는 증거 카드로 작성한다. 먼저 선택한 문제와 영향을 받는 구성 요소, 버전, 환경, 노출 조건을 밝힌다. 확인된 내용에는 파일 경로와 줄 번호, 보고서 항목, CI job이나 log 위치, 또는 실제로 실행한 읽기 전용 명령과 핵심 출력을 근거로 붙인다. 관찰한 사실과 해석은 별도 구역으로 나누며, 추정은 사실처럼 단정하지 않는다. 증거로 확정할 수 없는 값은 모두 “확인 필요”라고 적고 만들어 내지 않는다.

위험 판단은 “즉시 대응”, “기한 내 검증”, “보류 후 추적” 가운데 하나만 선택하고 그 이유를 직접 증거와 연결한다. 배포 준비 상태는 위험 판단과 분리해 READY_FOR_HUMAN_REVIEW, NOT_READY, TO_CONFIRM 중 하나로 표시한다.

사람이 판단해야 할 지점도 따로 적는다. 에스컬레이션, 경보 종료, 수정 승인, merge, deploy, release는 모두 사람의 결정으로 남겨 두며 직접 수행하지 않는다. 프로젝트나 관련 증거에 전혀 접근할 수 없다면 조사에 꼭 필요한 접근 권한 또는 맥락을 묻는 질문을 하나만 하고 중단한다.

카드의 마지막 문장은 권한 경계를 넘지 않으면서 즉시 실행할 수 있는 다음 행동 하나로 끝낸다.