분야별 주요 소식과 생활 정보를 전합니다
NCB뉴스
AI·IT

깃허브 Dependabot, 보안 패치와 정기 버전 업데이트는 무엇이 다를까

Dependabot 경고가 보안 패치 PR로 이어지는 조건, 정기 버전 업데이트 설정, 병합 전 파일과 테스트를 확인하는 순서를 GitHub 데모로 정리했다.

GitHub 데모의 lodash 명령 주입 경고에서 영향 범위 4.17.21 미만과 수정 버전 4.17.21이 표시된 화면
GitHub Docs 데모의 lodash 취약점 상세 화면. GitHub Docs · CC BY 4.0 · 여백 추가 및 형식 변환 · 출처 · 이용 조건

깃허브 Dependabot이 올린 풀 리퀘스트(PR)는 겉보기에는 모두 의존성 버전을 바꾸는 제안이다. 보안 업데이트는 프로젝트가 쓰는 패키지에 알려진 취약점이 발견됐을 때, 정기 버전 업데이트는 정해둔 일정에 새 버전을 확인했을 때 시작된다. 같은 패키지를 바꾸더라도 첫 번째는 수정이 포함된 최소 버전, 두 번째는 설정에 따라 사용 가능한 최신 버전을 목표로 할 수 있다.

이 차이는 처리 순서에도 영향을 준다. 보안 PR에서는 어떤 취약점이 현재 코드에 영향을 주는지부터 보고, 정기 버전 PR에서는 새 버전이 기존 코드와 함께 작동하는지부터 본다. Dependabot은 변경을 제안하므로 병합하기 전에 무엇이 바뀌는지 확인할 수 있다.

1. 경고와 보안 패치 PR은 무엇이 다른가

Dependabot 경고는 저장소의 의존성 그래프에 알려진 취약점과 맞는 항목이 있다는 알림이다. 저장소에서 경고와 보안 업데이트를 켜고, Dependabot이 의존 관계를 해치지 않는 수정 버전을 찾으면 변경을 제안하는 PR이 열린다. 보안 PR은 기본 브랜치를 대상으로 하며, 보안 권고에 반응해 만들어진다. 정기 업데이트 파일에 적은 주간 일정까지 기다리는 방식과는 출발 조건이 다르다. GitHub 보안 업데이트 문서

GitHub의 데모에서 lodash 명령 주입 경고를 열면 영향 범위와 패치 버전이 나란히 표시된다. 예제의 4.17.20은 이 취약점의 영향 범위에 들어가고, PR은 4.17.21로 바꾸자고 제안한다. 그 버전 번호는 해당 취약점을 고친 최소 버전이다. 현재 새 프로젝트에 설치할 버전을 정할 때는 최신 권고도 함께 확인해야 한다. GitHub Advisory Database의 lodash 권고

Dependabot이 lodash를 4.17.20에서 4.17.21로 올리도록 제안한 열린 PR 화면
GitHub Docs 데모의 보안 업데이트 PR. GitHub Docs · CC BY 4.0 · 형식 변환 · 출처 · 이용 조건

경고가 있는데 PR이 없다면 먼저 경고 상세에서 자동 업데이트 오류를 찾는다. 기능이 꺼져 있거나, 간접 의존성이 잠금 파일에 명시되지 않았거나, 다른 패키지가 이전 버전만 허용하는 경우가 있다. 예를 들어 직접 설치한 라이브러리가 취약한 패키지의 구버전만 요구한다면, 그 패키지 하나를 억지로 올리기 전에 상위 라이브러리에 호환되는 새 버전이 있는지 살핀다. Dependabot 오류별 확인 방법

2. 정기 버전 업데이트는 무엇을 얼마나 자주 확인할지 정한다

정기 업데이트는 기본 브랜치의 .github/dependabot.yml에서 설정한다. 저장소 최상위에 package.json이 있는 npm 프로젝트에서 일주일에 한 번씩 새 버전을 확인하도록 하려면 다음처럼 쓸 수 있다. version: 2는 npm 버전이 아니라 설정 파일 형식이다. directory는 의존성 파일이 있는 디렉터리이며, schedule은 버전 점검 주기를 정한다.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

예를 들어 앱의 의존성 파일이 /web에 있다면 해당 경로를 지정한다. 앱 패키지와 GitHub Actions를 모두 관리하려면 대상별 항목을 따로 둔다. 저장소의 Insights에서 Dependency graph를 열고 Dependabot 탭으로 이동하면 어떤 항목을 점검했는지 확인할 수 있다. 점검 경로가 다르면 원하는 의존성의 PR을 기다려도 나타나지 않을 수 있다. 설정 파일 위치와 필수 항목 · 버전 업데이트 설정 절차

GitHub 저장소의 Insights에서 Dependency graph의 Dependabot 탭을 강조한 화면
GitHub Docs의 Go·Rust 프로젝트 예시. Dependabot 점검 탭의 위치를 보여준다. GitHub Docs · CC BY 4.0 · 일부 자름 및 형식 변환 · 출처 · 이용 조건

3. 병합 전에는 변경 파일과 실제 테스트를 함께 본다

보안 PR이라면 경고의 영향 버전과 수정 버전을 확인한 뒤 Files changed에서 바뀐 의존성 선언과 잠금 파일을 함께 본다. 직접 바꾸려던 한 항목 외에 같이 움직인 의존성이 있는지도 살핀다. 정기 버전 PR이라면 릴리스 노트에서 호환성 변경을 확인한다. 새 버전이 지원하는 런타임이나 기본 설정이 달라지면 작은 코드 변경처럼 보여도 빌드와 배포에 영향을 줄 수 있다.

다음으로 Checks에서 빌드·테스트가 실제로 실행됐는지 확인한다. Dependabot PR에서만 CI가 실패한다면 코드 호환성과 별도로 인증 경로를 살핀다. GitHub Actions에서 Dependabot이 여는 일반 PR은 GITHUB_TOKEN이 기본적으로 읽기 전용이고, 일반 Actions 시크릿 대신 Dependabot 시크릿이 제공된다. 평소 쓰던 비공개 패키지를 가져오지 못해 실패했다면 로그에 인증 오류가 있는지 먼저 확인할 수 있다. Dependabot PR의 GitHub Actions 권한

보안 PR을 병합한 뒤에는 연결된 경고가 해결 상태로 바뀌었는지 살핀다. 정기 버전 PR을 병합한 뒤에는 변경된 파일과 테스트 결과를 기록한다. 같은 봇이 만든 PR이라도 판단의 근거는 각각 취약점의 영향 범위와 새 릴리스의 변경 사항에 있다.