Dependabot reachability 미리보기: Unreachable이면 패치를 미뤄도 될까요?

Dependabot의 새 reachability 분석은 취약한 함수까지 이어지는 호출 경로가 있는지 살펴보는 정보입니다. ‘Unreachable’ 표시만으로 안전하다고 결론 내리거나 경보를 닫는 기준으로 쓰면 안 됩니다. 심각도와 서비스 환경, 분석 결과의 시점, 아직 모르는 조건을 함께 읽어 보세요.

GitHub가 2026년 10월 28일 공개한 JavaScript·TypeScript용 공개 미리보기를 공식 문서와 함께 살펴봤습니다. 실제 저장소에서 분석을 켜거나 코드를 실행한 시험은 하지 않았습니다. 아래의 검토 메모와 가상 경보 사례는 팀이 확인할 질문을 정리하도록 직접 구성했습니다.

이번 미리보기는 어떤 정보를 더하나요?

GitHub의 발표에 따르면 이 기능은 CodeQL 정적 분석과 취약 함수 정보를 이용해 코드에서 의존성의 취약 함수로 이어지는 호출 경로를 찾습니다. 기존 Dependabot 경보에 판정과 근거를 더하며, 판정이 경보를 자동으로 종료하거나 해제하지는 않습니다.

미리보기 대상은 데이터 레지던시를 포함한 GitHub Enterprise Cloud입니다. JavaScript·TypeScript와 npm·Yarn·pnpm 잠금 파일, GitHub 호스팅 러너라는 실행 환경이 조건이며 자체 호스팅 러너는 지원하지 않습니다. 기능은 기본적으로 꺼져 있고 Dependabot alerts가 켜져 있어야 합니다.

발표는 미리보기 동안 분석이 무료이고 분석에 사용한 GitHub Actions 시간도 청구하지 않는다고 설명합니다. Enterprise Cloud 자체가 무료라는 뜻으로 읽으면 안 돼요. 현재 조건은 Dependabot reachability 공개 미리보기 공지에서 확인했습니다.

네 가지 판정은 어떻게 구분하나요?

공식 문서는 네 판정을 아래처럼 구분합니다.

판정	공식 설명의 핵심
Reachable	취약한 함수까지 적어도 하나의 호출 경로를 찾음.
Potentially reachable	호출 가능성을 배제하지 못함. 도달 가능한 경보와 함께 우선 대응 대상으로 다룸.
Unreachable	분석을 완료했지만 호출 경로를 찾지 못함. 이 표시만으로 경보를 닫지 않음.
Reachability unavailable	지원 범위나 검사 실패·시간 초과 등의 이유로 판정을 제공하지 못함. 다른 기준으로 검토함.

호출 경로가 있다고 공격이 실제로 성공한다는 뜻은 아니며, 경로가 없다는 판정도 의존성의 안전을 보장하지 않습니다. 이 구분은 GitHub Docs의 reachability 분석 설명에 명시돼 있습니다. 판정은 어느 시점의 분석 정보로 읽어야 해요.

‘분석 정보’와 ‘대응 결정’을 왜 나눌까요?

아래부터는 문서의 조건을 바탕으로 직접 구성한 검토 제안입니다. 경보 화면에서 읽은 내용을 기록하는 칸과 팀이 결정한 다음 작업을 적는 칸을 나눠 보세요. 제품이 알려 준 것과 내가 판단한 것을 같은 문장에 섞지 않으려는 메모 방법입니다.

예를 들어 ‘호출 경로가 표시됨’은 읽은 분석 내용입니다. 그 경로가 현재 운영에서 어떤 역할을 하는지, 어떤 변경을 검토할지, 누가 확인할지는 별도로 적을 질문이에요. 경로를 확인하지 않은 상태라면 ‘운영에서 확인함’이라고 쓰지 않고 화면에서 본 범위만 남깁니다.

반대로 표시된 경로가 없을 때도 곧바로 ‘우리는 쓰지 않는다’로 바꾸지 않는 방식을 제안합니다. 분석이 완료됐는지, 확인한 코드와 현재 검토 대상이 같은지, 다른 조건이 남아 있는지 적어 보세요. 답하지 못한 질문을 없애기보다 누가 무엇을 확인할지 연결하는 데 초점을 두면 됩니다.

자체 메모 구분	남길 수 있는 내용
화면에서 읽은 사실	경보 식별 정보, 판정, 확인한 시각, 제공된 경로 근거.
팀이 확인한 환경	검토한 저장소·코드 버전·운영 대상과 아직 확인하지 못한 조건.
다음 대응	검토 담당자, 확인할 자료, 준비할 변경과 다시 볼 계기.
남은 불확실성	분석되지 않은 범위와 추가 확인이 필요한 부분.

이 표는 GitHub의 공식 승인 양식이 아닙니다. 개인 메모나 팀의 기존 검토 절차에 맞게 항목을 고쳐 쓸 수 있어요. 실제로 확인하지 않은 칸은 ‘해당 없음’으로 닫기 전에 왜 확인하지 않았는지 남기는 방식을 제안합니다.

분석 뒤에 코드를 바꾸면 결과도 바로 달라지나요?

공식 문서에 따르면 최초 분석 뒤에는 열린 경보가 있는 동안 24시간마다 다시 분석합니다. 코드 변경을 올리는 것만으로 분석이 시작되지는 않으며, 변경 뒤 판정은 다음 분석이 완료될 때까지 그 변경을 반영하지 않습니다. 미리보기에서는 원하는 시점에 분석을 직접 요청하거나 일정을 정할 수 없습니다.

따라서 변경 요청을 검토할 때 ‘코드를 바꾼 시점’과 ‘현재 판정이 만들어진 시점’을 나란히 적어 보는 방식을 제안합니다. 새 표시가 없다고 수정이 실패했다고 단정하거나, 이전 표시를 새 코드의 검증 결과로 붙이지 않기 위한 메모예요.

가상의 사례로 담당자가 의존성을 갱신한 변경 요청을 올렸다고 합시다. 검토 기록에는 변경한 파일과 확인한 동작을 적고, 화면에 남은 분석 결과가 그 변경 이전인지도 따로 확인할 수 있습니다. 이 예시는 실제 저장소나 취약점에 패치를 적용했다는 시험 결과가 아닙니다.

새 분석을 기다리는 동안에도 팀이 정한 취약점 대응과 코드 검토를 이어가세요. 이번 기능에서 어떤 증거를 얻었고 어떤 확인을 별도로 진행했는지 구분해 두세요. 판정이 바뀌었다는 사실과 변경 내용을 검토했다는 사실은 각각의 근거로 남기는 편이 좋겠습니다.

미분석 상태라면 무엇부터 확인하면 좋을까요?

현재 문서는 일부 큰 저장소·모노레포에서 시간이나 자원 한계로 결과를 제공하지 못할 수 있다고 설명합니다. 미리보기 분석에는 세 시간 제한이 있습니다. ‘Unavailable’을 경로가 없다는 뜻으로 바꾸어 해석하면 안 되는 이유예요.

검토를 맡았다면 먼저 현재 저장소가 공지된 언어·잠금 파일·구독 조건에 해당하는지 읽어 보세요. 이 글은 설치나 설정 변경 명령을 안내하지 않습니다. 계정별 적용 가능성이나 실제 화면 상태를 확인하지 않았으므로 담당자의 현재 설정과 공식 안내를 대조해야 합니다.

그다음 미분석 사유가 안내돼 있는지, 어떤 확인을 했는지 메모해 보세요. 원인을 아직 알지 못한다면 추측으로 실패 이름을 붙이지 않아도 됩니다. ‘원인 미확인, 담당자 확인 필요’라고 쓰고 기존 경보 검토에서 쓰던 정보를 계속 확인하는 방식입니다.

저장소가 크다는 이유만으로 코드를 임의로 제외하거나 분석을 통과시키기 위한 예외를 만드는 방법은 제안하지 않습니다. 실제로 어떤 범위가 분석되지 않았는지 파악하고, 서비스 담당자와 보안 담당자가 남은 질문을 공유하는 데 이 메모를 활용해 보세요.

판정이 서로 다른 경보는 어떻게 비교해 볼까요?

다음은 실제 경보가 아닌 가상의 검토 상황입니다. A에는 호출 경로가 표시되고, B에는 분석 결과가 없다고 합시다. 두 글자를 순위로 바꾸기 전에 각 경보에서 확보한 정보가 무엇인지 별도 줄에 적어 보세요. 정보가 적다는 사실을 문제가 작다는 평가로 옮기지 않는 연습입니다.

A에서는 어떤 경로 근거를 읽었고 현재 서비스와 어떻게 연결되는지 질문할 수 있습니다. B에서는 왜 결과가 없는지와 기존 경보 설명에서 확인할 내용을 남길 수 있어요. 담당자가 아직 확인하지 않은 운영 조건을 임의로 채우거나 두 경보의 실제 대응 순서를 이 가상 사례로 정하지는 않습니다.

팀이 이미 사용하는 심각도와 운영 맥락도 같은 메모에서 함께 볼 수 있게 놓아 보세요. 이번 표의 목적은 새로운 단일 점수를 만드는 것이 아니라, 다른 질문에 답하는 정보가 서로 대체되지 않도록 하는 데 있습니다. 어떤 근거로 결정했는지 검토자가 설명할 수 있어야 한다는 제안이에요.

가상 검토의 질문	구분해서 남길 기록
제품이 보여 준 근거는 무엇인가요?	판정과 읽은 경로, 분석 시점. 없는 정보는 미확인으로 표시.
우리 환경에서 확인한 것은 무엇인가요?	검토한 코드·서비스 범위와 확인 담당자. 가정은 별도 표시.
어떤 조치가 준비됐나요?	변경 요청, 검토 결과, 실제 수행한 확인과 아직 하지 않은 일.
다시 볼 계기는 무엇인가요?	새 분석 결과, 코드 변경, 새로 확인한 조건과 담당자의 다음 검토.

팀에 적용을 제안할 때 무엇을 준비할까요?

새 기능을 켜 달라고 요청하기 전에 어떤 질문을 해결하려는지 적어 보세요. ‘경보를 줄이기’보다 ‘현재 경보에서 어떤 호출 경로 근거를 얻을 수 있는지 확인하기’처럼 쓰는 겁니다. 경보 수가 달라졌다는 사실만으로 대응 품질이 나아졌다고 평가하지 않는 방식이에요.

검토 범위도 구체화해 보세요. 저장소 이름과 담당자, 필요한 접근 권한을 확인할 사람, 분석 정보를 읽을 사람, 실제 대응을 결정할 사람을 구분할 수 있습니다. 하나의 역할을 여러 명이 맡더라도 누가 어떤 질문에 답할지 기록하는 데 의미가 있습니다.

인계 메모는 ‘판정과 분석 시점까지 확인했으며, 이 코드가 어느 서비스에 배포되는지는 담당자에게 확인 중’처럼 써 볼 수 있어요. 다음 담당자가 처음부터 모든 내용을 다시 확인해야 하는지, 남아 있는 질문에 답하면 되는지를 구분하도록 돕는 자체 예시입니다. 실제로 회신받지 않았다면 확인 완료로 표시하지 마세요.

도입 전에는 현재 쓰는 경보 검토 방식도 짧게 남겨 보세요. 이후 기능에서 받은 정보가 어떤 질문을 추가로 답했는지 비교할 수 있게 하는 자체 기록입니다. 이 글에서 효과를 검증한 평가 설계는 아니며, 도입만으로 대응 시간이나 사고 위험이 줄어든다는 수치를 약속하지 않습니다.

자주 묻는 질문은 어떻게 정리할까요?

Unreachable이면 패치를 미뤄도 되나요? 그 표시 하나로 결정하지 마세요. 앞에서 확인한 판정의 범위와 함께 팀의 대응 기준, 현재 서비스 조건, 남은 확인을 살펴볼 일입니다. 이 글은 보안 예외나 경보 해제를 승인하는 근거가 아닙니다.

Potentially reachable과 Unavailable을 묶어도 되나요? 앞의 네 판정 설명에서 확인했듯 서로 다른 상태로 적어 두세요. 메모에서도 ‘판단의 불확실성’과 ‘분석 결과를 제공하지 못함’을 구분하면 다음 담당자가 확인할 질문을 다르게 남길 수 있습니다.

분석 화면을 봤으면 검증 완료인가요? 화면에서 정보를 읽은 범위와 코드·서비스를 확인한 범위를 나눠 기록하세요. 실제 변경이나 실행을 하지 않았다면 완료한 것처럼 쓰지 않아야 합니다. 본문에 제시한 표도 그 차이를 기록하는 자체 양식입니다.

이번 글의 확인 범위는 어디까지인가요?

사실 기준일은 2026년 11월 2일입니다. GitHub의 공식 발표와 연결된 개념 문서를 읽었고, 미리보기 조건은 이후 바뀔 수 있습니다. 실제 계정에서 기능 활성화·분석·패치·코드 실행·보안 검증은 하지 않았습니다.

검토를 시작한다면 한 경보에서 읽은 판정과 근거, 그 정보의 시점, 현재 환경에서 확인한 사실, 다음 담당자가 확인할 질문을 나눠 적어 보세요. 분석 정보를 실제 대응 결정과 구분해 남기는 것이 이번 글에서 제안하는 사용 방식입니다.

직접 생성한 개념 이미지입니다. 실제 서비스 화면이나 구축·성능 시험 결과가 아닙니다.