개발 뉴스 · 2026-10-17 작성 · 2026-10-14 발표 기준
GitHub Actions lockfile 공개: actions.lock 설정법과 Dependabot 연동
GitHub 공식 발표와 문서 기반 기술 안내 · 실제 CLI 실행 검증 결과가 아님
핵심: 잠금 파일은 변경 가능한 액션 참조를 커밋에 묶어 예기치 않은 코드 변경을 줄이지만, 종속성 자체가 안전하다는 뜻은 아니다.
2026년 10월 14일 GitHub는 GitHub Actions 워크플로 의존성 잠금 기능을 공개 미리보기로 발표했다. 핵심은 태그나 브랜치가 움직여도 온보딩한 워크플로에서 사전에 기록한 커밋을 실행하는 것이다. 어떤 저장소에 왜 필요한지, 생성·검토·운영 방법과 보안상 남는 위험을 구분해 살펴본다.
GitHub Actions lockfile은 무엇을 해결하나?
GitHub Actions lockfile은 GitHub Actions 의존성 잠금에 사용하는 잠금 파일이다. 예를 들어 YAML의 uses: actions/checkout@v4가 특정 태그를 가리키는 경우, 그 태그가 나중에 이동하면 동일한 워크플로 정의를 유지해도 다른 코드가 실행될 수 있다. GitHub Actions 커밋 SHA 고정의 취지를 워크플로 의존성 전체로 넓히는 방식이다. 단, 모든 워크플로에 자동 적용되는 기능이 아니다. 온보딩된 워크플로에 대해서만 기록된 커밋 사용을 강제한다.
GitHub의 10월 14일 발표와 편집자 주석에 따르면 공개 미리보기 이용 대상은 GitHub Free, Team, Enterprise Cloud, 데이터 레지던시 Enterprise Cloud를 포함한다. 이용 가능 여부는 계정·정책·제품 변경에 따라 달라질 수 있으므로 도입 직전에 제품 화면을 확인해야 한다.
GitHub actions.lock 파일 생성과 검토 순서
GitHub actions.lock은 보통 .github/workflows/actions.lock 경로에 생성된다. 작업 시작 전 워크플로에 선언된 uses 참조가 신뢰할 만한 릴리스인지, 재사용 워크플로가 어느 저장소에 있는지 확인한다. 전이 의존성과 재사용 워크플로도 검토 범위에 포함된다. 다만 원격 재사용 워크플로의 하위 의존성 관리는 해당 워크플로가 정의된 저장소의 잠금 파일에 영향을 받는다.
gh actions-lock 설치는 GitHub CLI를 준비한 뒤 다음 공식 문서 예시를 참고한다.
gh extension install github/gh-actions-lock
# 저장소 루트에서 실행
gh actions-lock
# 하나의 워크플로만 온보딩할 경우
gh actions-lock .github/workflows/ci.yml
# 생성 결과와 변경된 워크플로 확인
git diff -- .github/workflows
이 글의 명령은 GitHub 공식 문서를 바탕으로 제공한 재현용 안내이며, 이 콘텐츠 제작 과정에서 실제 테스트 저장소에 실행해 성공을 보증한 결과가 아니다. 확장 도구는 워크플로의 uses 참조를 더 구체적인 버전으로 수정할 수 있다. 변경된 파일 전체를 리뷰하고 정당한 SHA인지 확인한 다음 커밋한다. 잠금 파일을 수동 편집하지 않는 것이 공식 권고다.
Dependabot 업데이트와 Require lockfile 정책
GitHub Actions Dependabot lockfile 연동은 이미 잠금 파일을 사용하는 워크플로의 액션 버전 업데이트 PR에서 해당 잠금 항목도 갱신하는 형태다. actions.lock Dependabot 자동 업데이트는 업데이트 PR의 동기화 기능이지 미적용 워크플로를 자동 온보딩해 주는 기능이 아니다. 반드시 PR에 포함된 버전 변경, 커밋, 관련 위험을 검토한다.
GitHub Require lockfile 정책도 공개 미리보기로 소개되었다. 엔터프라이즈·조직·저장소 관리자가 적용할 수 있지만 관리자 권한과 실제 정책 UI는 저장소 환경에서 확인해야 한다. 엄격한 액션 허용 목록(allowlist)을 쓰는 경우 잠긴 SHA와 기존 태그 패턴 간 호환성도 먼저 점검한다.
GitHub Actions 공급망 보안의 실제 효과와 한계
GitHub Actions 공급망 보안 측면에서 잠금 파일은 검토 시점 이후 태그 이동으로 실행 코드가 달라지는 문제를 줄인다. 그러나 GitHub Actions lockfile 보안 한계는 분명하다. 이미 악성 코드를 포함한 커밋을 잠그면 그 커밋은 여전히 악성이다. 잠금 파일은 취약점 스캐너도, 비밀 정보 유출 탐지기도, 모든 제3자 액션에 대한 신뢰 인증서도 아니다.
운영에서는 최소 권한 토큰, PR 변경점 검토, 외부 액션의 유지보수 상태, 취약점 대응, 잠금 파일 변경 diff 리뷰를 함께 적용해야 한다. 보안 패치를 적용하면서 SHA를 갱신하지 않으면 오히려 오래된 코드에 머무를 수 있으므로 변경 통제와 갱신 프로세스를 동시에 설계해야 한다.
자주 묻는 질문과 도입 체크리스트
GitHub Actions 잠금파일 만드는 방법은?
GitHub CLI에 공식 확장 도구를 설치하고 저장소 루트에서 gh actions-lock을 실행한다. 생성된 파일과 워크플로 변경 diff를 리뷰한 뒤 커밋한다. 실행 전 해당 저장소의 사용 권한과 최신 문서를 확인한다.
GitHub Actions lockfile 무료 플랜에서도 사용 가능한가?
2026년 10월 14일 공식 발표의 공개 미리보기 대상에는 Free 플랜이 포함된다. 단, 향후 정책이나 UI가 바뀔 수 있으니 실제 적용 화면을 확인한다.
Dependabot이 잠금 파일을 알아서 도입하나?
아니다. 온보딩이 완료된 워크플로에서 액션 버전 업데이트 PR을 생성할 때 해당 잠금 파일 항목을 함께 갱신하는 것이다.
실무 적용 전 무엇을 확인하나?
- 워크플로의
uses가 올바른 액션·재사용 워크플로를 참조하는가? - 생성된 lockfile의 SHA와 변경 diff를 리뷰했는가?
- Dependabot, 보안 패치, 정책 적용 범위를 점검했는가?
- 테스트 브랜치에서 CI 성공과 배포 권한을 확인했는가?
- 장애 시 롤백과 잠금 업데이트 담당자를 지정했는가?
공식 출처와 검증 범위
공식 발표는 2026-10-14 내용을 기준으로, 설치 절차는 2026-10-17 열람한 GitHub 문서 기준으로 구분했다. 실제 테스트 저장소의 CLI·Dependabot·정책 작동을 독립 재현하지 않았으며, 실제 사이트 기존 글 중복 여부도 확인하지 않았다.
