dependabot

4 개의 포스트

github

멀웨어 보안 권고를 npm을 넘어 확장한 방법 (새 탭에서 열림)

Ankit은 GitHub에서 Dependabot 팀을 이끄는 시니어 엔지니어링 매니저입니다. Dependabot은 34개 이상의 패키지 생태계에 걸쳐 3천만 개가 넘는 저장소를 감시하며, 소프트웨어 공급망 공격에 대응하는 역할을 합니다. 이러한 광범위한 책임 때문에 Ankit은 공급망 보안 위협에 대해 높은 경계심을 유지하고 있습니다. ### Ankit의 역할 - GitHub의 Supply Chain Security 조직에서 Dependabot 팀을 이끕니다. - 엔지니어링 관리자로서 소프트웨어 의존성 및 공급망 보안과 관련된 업무를 담당합니다. ### Dependabot의 감시 범위 - 3천만 개 이상의 저장소를 모니터링합니다. - 34개 이상의 패키지 생태계를 지원합니다. - 다양한 패키지 관리자와 의존성을 다뤄야 하므로 매우 광범위한 보안 대응이 필요합니다. ### 소프트웨어 공급망 보안 - 패키지와 의존성은 애플리케이션 보안에 직접적인 영향을 줍니다. - 의존성의 취약점이나 악성 패키지는 다수의 저장소에 빠르게 확산될 수 있습니다. - Dependabot의 대규모 감시 범위는 공급망 공격을 조기에 탐지하고 대응하는 데 중요한 역할을 합니다. 이 글의 제공된 내용은 Ankit과 Dependabot의 역할 및 규모를 소개하는 부분에 해당하며, 구체적인 기술적 주장이나 구현 세부사항은 포함되어 있지 않습니다.

github

Dependabot 길들이기: 업데이트를 그룹화하고, 주기를 늦추되, 보안 업데이트는 신속하게 (새 탭에서 열림)

활성 저장소에서는 Dependabot이 의존성마다 개별 PR을 생성해 알림, 리뷰, CI 실행을 과도하게 늘릴 수 있다. 글은 Microsoft GCToolkit 사례를 통해 의존성 업데이트를 생태계별로 그룹화하고 주기를 월간으로 늦추면 유지보수 소음을 크게 줄일 수 있다고 설명한다. 다만 일반 버전 업데이트와 달리 보안 업데이트는 신속하게 처리되므로, 업데이트 빈도를 낮춰도 보안 대응 속도는 유지할 수 있다. ## Dependabot이 만드는 유지보수 소음 - GCToolkit의 578개 커밋 중 92개가 Dependabot 버전 업데이트였으며, 최근 12개월에만 61개가 발생했다. - 기존 설정은 다음과 같았다. - GitHub Actions만 감시 - 매일 업데이트 확인 - 최대 10개의 PR 허용 - 의존성 10개가 업데이트되면 PR 10개, CI 실행 10회, 리뷰 알림 10건이 발생한다. - `open-pull-requests-limit: 10`은 PR 수를 제한할 뿐, 업데이트가 쏟아지는 원인을 해결하지 못한다. ## 여러 업데이트를 하나의 PR로 그룹화 - `groups`와 `patterns: ["*"]`를 사용하면 모든 의존성 업데이트를 하나의 PR로 묶을 수 있다. - 예를 들어 10개의 업데이트가 발생해도 다음처럼 처리된다. - 브랜치 1개 - PR 1개 - CI 실행 1회 - 리뷰 및 병합 1회 - 그룹 이름은 자유롭게 정할 수 있으며 PR 제목과 브랜치 이름에 표시된다. - 규모가 큰 프로젝트에서는 테스트 라이브러리, 운영 의존성 등 목적별로 여러 그룹을 만들 수 있다. - 모노레포에서는 `directories`와 `group-by: dependency-name`을 사용해 여러 디렉터리에 같은 의존성이 있을 때 하나의 PR로 통합할 수 있다. ```yaml - package-ecosystem: "npm" directories: - "/apps/*" schedule: interval: "monthly" groups: monthly-batch: group-by: dependency-name patterns: - "*" ``` ## 업데이트 주기를 일간에서 월간으로 변경 - `interval: daily`는 평일마다 업데이트를 확인하므로 지속적인 PR 생성으로 이어질 수 있다. - `interval: monthly`로 바꾸면 계획 가능한 월간 배치 방식으로 전환된다. - 그룹화와 결합하면 생태계별로 한 달에 하나의 일괄 PR을 받게 된다. - 프로젝트 특성에 따라 `weekly`를 선택할 수도 있고, `schedule.day`와 `schedule.time`으로 실행 시점을 지정할 수 있다. - 의존성이 안정적인 성숙한 라이브러리에는 월간 주기가 적합하다. ## 실제 사용하는 생태계를 모두 설정 - 기존 설정은 GitHub Actions만 대상으로 했지만, GCToolkit은 Maven 기반 Java 프로젝트이므로 Maven 의존성도 별도로 등록해야 했다. - 생태계마다 `updates` 항목을 추가해야 한다. ```yaml - package-ecosystem: "github-actions" directory: "/" schedule: interval: "monthly" groups: monthly-batch: patterns: - "*" - package-ecosystem: "maven" directory: "/" schedule: interval: "monthly" groups: monthly-batch: patterns: - "*" ``` - GitHub Actions와 Maven 업데이트는 각각 독립된 그룹과 일정으로 관리된다. - 소음을 줄이는 것뿐 아니라, 실제 애플리케이션 의존성까지 Dependabot이 감시하도록 만드는 것이 중요하다. ## 보안 업데이트는 빠르게 유지 - 월간 일정과 그룹 설정은 일반적인 버전 업데이트의 처리 방식을 조정하는 설정이다. - Dependabot 보안 업데이트는 별도의 메커니즘으로 동작하므로, 일반 업데이트 주기를 늦춰도 보안 취약점 대응까지 월간으로 미뤄지지 않는다. - 따라서 평상시에는 일괄 업데이트로 리뷰 부담을 줄이고, 보안 수정은 기존처럼 신속하게 처리하는 균형을 유지할 수 있다. ## 실용적인 적용 방법 - 안정적인 저장소라면 생태계별로 `monthly` 일정과 전체 의존성 그룹화를 적용한다. - 업데이트가 자주 필요하거나 변경 영향이 큰 프로젝트는 `weekly` 또는 목적별 다중 그룹을 사용한다. - GitHub Actions뿐 아니라 Maven, npm 등 실제 사용하는 모든 패키지 생태계를 `dependabot.yml`에 등록한다. - 보안 업데이트 설정은 별도로 확인해 취약점 수정이 지연되지 않는지 점검한다.

github

쿨다운이 필요한 이유: Dependabot이 이제 버전 업데이트를 내놓기 전에 기다리는 이유 (새 탭에서 열림)

Carlin은 GitHub Advanced Security에서 Dependabot을 담당하는 제품 관리자입니다. 소프트웨어 엔지니어링과 데이터 과학 경험을 바탕으로 데이터 중심의 제품 관리 방식을 활용합니다. 워싱턴에서 파트너와 반려견 Cookie와 함께 살며, 여가 시간에는 사이클링과 경쟁적인 보드게임을 즐깁니다. ### GitHub에서의 역할 - GitHub Advanced Security 조직에서 제품 관리 업무를 담당합니다. - 주요 담당 분야는 Dependabot입니다. - 보안과 의존성 관리 기능을 발전시키는 데 집중하고 있습니다. ### 기술적 배경과 업무 방식 - 소프트웨어 엔지니어링 경험을 보유하고 있습니다. - 데이터 과학 배경을 바탕으로 의사결정과 제품 전략을 수립합니다. - 데이터에 근거한 제품 관리 접근 방식을 중요하게 여깁니다. ### 개인 생활과 관심사 - 워싱턴에서 파트너 및 반려견 Cookie와 함께 생활합니다. - 여가 시간에는 사이클링을 즐깁니다. - 경쟁적인 보드게임에도 참여합니다. 전반적으로 Carlin은 개발 및 데이터 전문성을 활용해 GitHub의 보안 제품을 이끄는 제품 관리자입니다.

github

GitHub 전반의 오픈 소스 공급망 보안 강화 (새 탭에서 열림)

공격자들은 GitHub Actions 워크플로를 침해해 API 키 같은 비밀을 탈취한 뒤, 악성 패키지를 배포하고 더 많은 프로젝트로 공격을 확산시키고 있다. 이에 대응하려면 Actions 워크플로를 CodeQL로 점검하고, 서드파티 액션을 커밋 SHA로 고정하며, 장기 비밀 대신 OIDC 기반 인증과 trusted publishing을 사용해야 한다. GitHub는 npm 악성코드 탐지와 Actions·npm 보안 로드맵을 강화하고 있지만, 오픈소스 생태계 전반의 지속적인 협력이 필요하다고 강조한다. ## GitHub Actions 워크플로가 공격의 출발점 - 최근 오픈소스 공급망 공격은 GitHub Actions 워크플로의 취약점을 찾는 방식으로 시작되는 경우가 많다. - 공격자는 워크플로에서 API 키, 토큰, 배포 자격 증명 등의 비밀을 탈취한다. - 탈취한 자격 증명으로: - 공격자가 통제하는 환경에서 악성 패키지를 배포하고 - 해당 패키지를 이용해 다른 프로젝트와 계정으로 공격을 확산한다. ## 지금 적용할 수 있는 Actions 보안 조치 - 공개 저장소에서 무료로 사용할 수 있는 **CodeQL의 GitHub Actions 분석 기능**을 활성화한다. - 워크플로 구현상의 보안 취약점과 보안 모범 사례 위반을 점검할 수 있다. - `pull_request_target`을 사용하지 않는다. - 외부 기여자의 코드가 높은 권한의 워크플로 컨텍스트에서 실행될 위험이 있다. - 서드파티 GitHub Actions를 전체 길이의 커밋 SHA로 고정한다. - 태그나 브랜치는 이후 다른 코드로 변경될 수 있지만, SHA 고정은 특정 코드 버전을 보장한다. - 이 변경은 저장소 관리자나 Dependabot이 수행해야 하며, 외부 Pull Request가 액션 버전 고정을 바꾸려 하면 주의해야 한다. - 사용자 입력을 셸 명령이나 스크립트에 직접 삽입하지 않는다. - 이 방식은 스크립트 인젝션으로 이어질 수 있다. - 침해된 의존성은 GitHub Advisory Database에서 확인한다. - Dependabot을 사용해 악성 또는 취약한 의존성에 대한 알림을 받는다. ## 비밀 대신 OIDC와 trusted publishing 사용 - 워크플로에 장기 보관되는 비밀을 넣는 대신, **OpenID Connect(OIDC) 토큰**을 사용할 수 있다. - OIDC 토큰에는 실행 중인 워크로드의 신원이 포함되므로, 클라우드 제공업체·패키지 저장소·호스팅 서비스가 해당 워크플로를 검증하고 권한을 부여할 수 있다. - GitHub와 OpenSSF는 이를 패키지 저장소의 **trusted publishing**으로 확산하고 있다. - 현재 npm, PyPI, NuGet, RubyGems, Crates 등 여러 저장소에서 지원된다. - trusted publishing의 장점: - 빌드 파이프라인에서 장기 비밀을 제거한다. - 패키지가 어떤 신뢰된 워크플로에서 배포됐는지 확인할 수 있다. - 패키지가 갑자기 trusted publishing을 중단하면, 탈취된 자격 증명을 이용한 공격 가능성을 조사하는 신호가 된다. ## npm의 악성 패키지 탐지 - npm에서는 매일 3만 개가 넘는 패키지가 배포된다. - GitHub는 모든 npm 패키지 버전을 악성코드 관점에서 검사한다. - 탐지 규칙은 공격 방식의 변화에 맞춰 지속적으로 개선된다. - 매일 수백 개의 신규 배포 패키지에서 악성 코드가 발견될 수 있으며, 실제 조치 전에는 사람이 양성 여부를 검토한다. - 오탐률이 1%만 되어도 매일 수백 개의 정상 패키지 배포가 중단될 수 있으므로, 자동 탐지와 사람의 검증 사이 균형이 중요하다. ## Shai-Hulud 이후의 보안 로드맵 - 2025년 말 발생한 Shai-Hulud 공격은 npm 보안 로드맵을 재정비하는 계기가 됐다. - GitHub는 다음 작업을 가속했다. - npm trusted publishing 확대 - 악성코드 탐지 및 제거 기능 강화 - 오픈소스 유지관리자와의 보안 요구사항 논의 - 보안 변경은 기존 워크플로를 수정하게 만들거나 하위 호환성을 깨뜨릴 수 있으므로, GitHub는 생태계가 원활하게 전환할 수 있도록 지원할 계획이다. - 최근 공격을 계기로 GitHub Actions 보안 로드맵도 재검토하고, 이미 진행 중인 보안 기능의 출시를 앞당기고 있다. ## 오픈소스 생태계의 공동 대응 - 오픈소스는 전 세계가 공유하는 공공재인 만큼 공격이 앞으로도 계속될 가능성이 높다. - GitHub는 npm과 GitHub Actions를 비롯해 향후 등장할 새로운 공격 경로까지 방어 범위를 확대하겠다고 밝혔다. - 효과적인 보안 기능을 만들기 위해 유지관리자와 커뮤니티의 피드백이 중요하다. 실무적으로는 먼저 CodeQL로 Actions를 검사하고, `pull_request_target` 제거·커밋 SHA 고정·스크립트 인젝션 점검을 진행하는 것이 좋다. 이후 가능하면 OIDC와 trusted publishing으로 배포 인증을 전환해, 탈취 가능한 장기 비밀 자체를 줄여야 한다.