10월 28일 정식 출시, 무엇이 달라졌나
GitHub는 2026년 10월 28일 GitHub Actions 워크플로 의존성 잠금 파일(workflow dependency lockfiles)을 정식 제공(GA)한다고 발표했다. 10월 14일 공개 미리보기 이후 약 2주 만이다. Enterprise Cloud(데이터 레지던시 포함), Team, Free 요금제가 공식 발표의 적용 대상이다.
이번 기능의 핵심은 워크플로 YAML에서 읽기 편한 태그나 브랜치 이름을 유지하면서도, 실제 실행할 Action 코드를 잠금 파일에 기록된 특정 커밋으로 고정하는 것이다. 예컨대 uses: actions/checkout@v4처럼 사람이 읽기 쉬운 표기를 사용해도 이미 잠긴 실행은 해당 커밋을 참조한다.
변경 전과 달라진 것은 단지 편집 편의가 아니다. 태그가 나중에 다른 커밋을 가리켜도, 온보딩된 워크플로는 검토한 커밋을 유지하도록 하는 공급망 변경 관리 수단이 추가된 것이다. 다만 잠긴 의존성이 안전한 코드라는 보증은 아니다.
태그와 SHA, 전이 의존성은 어떻게 고정되나
Action 공급자는 태그를 변경할 수 있다. 워크플로에서 태그만 참조한다면 같은 YAML도 실행 시점에 따라 다른 코드를 가져올 가능성이 있다. GitHub Actions lockfile은 .github/workflows/actions.lock에 Action과 그 전이(transitive) Action 의존성의 해결된 커밋을 기록한다. 온보딩된 워크플로가 이 기록을 기준으로 실행한다는 점이 중요하다.
범위를 과대평가해서는 안 된다. 다른 저장소의 재사용 워크플로를 jobs.<id>.uses 형태로 호출하는 경우, 호출 저장소의 lockfile이 해당 재사용 워크플로 자체를 직접 고정하지 않는다. 호출 SHA를 고정하거나 재사용 워크플로 정의 저장소에서도 별도 보호책을 마련해야 한다.
Docker·컨테이너 이미지, 러너 이미지, 시크릿 노출 방지, 잠금 대상 Action 코드의 악성 여부는 자동 해결 대상이 아니다. 컨테이너 이미지를 재현 가능하게 관리하려면 별도의 digest 고정과 업데이트 검토가 필요하다.
설치부터 커밋까지: 첫 적용 절차
GitHub CLI(gh)를 설치하고 인증을 마친 뒤, 저장소 루트에서 아래 명령을 실행한다. GitHub의 공식 확장 프로그램 설치 명령과 생성 명령이며, 실제 설치 성공 여부는 이 기사 제작 과정에서 재현 시험하지 않았다.
gh extension install github/gh-actions-lock
gh actions-lock
git diff -- .github/workflows/
git add .github/workflows/
git commit -m "Lock GitHub Actions dependencies"전체가 부담스럽다면 gh actions-lock .github/workflows/ci.yml처럼 특정 워크플로를 먼저 온보딩할 수 있다. 생성 후에는 .github/workflows/actions.lock뿐 아니라 확장 프로그램이 수정했을 수 있는 워크플로의 uses: 참조까지 diff로 검토해야 한다. 잠금 파일을 자동 생성했다는 이유만으로 코드를 검토 없이 병합해서는 안 된다.
./ 경로를 사용하는 로컬 Action은 자동 추적되지 않는다. 도구의 마이그레이션 및 무시 옵션은 동작과 위험이 다를 수 있으므로, 로컬 Action을 쓰는 저장소는 공식 문서를 확인하고 시험 저장소에서 먼저 적용하는 편이 안전하다.
Dependabot 갱신·검증·태그 이동 처리
Dependabot이 이미 GitHub Actions 버전 업데이트를 설정한 저장소에서 온보딩된 워크플로의 Action 업데이트 PR을 만들면, 대응되는 lockfile 항목도 함께 갱신한다. 그러나 Dependabot이 새로 추가한 모든 워크플로를 자동 온보딩하는 기능으로 이해하면 안 된다.
CI에 gh actions-lock --verify를 두면 잠금 파일이 현재 워크플로와 일치하는지 확인하는 용도로 활용할 수 있다. --verify-local은 오프라인에서 잠금 커버리지를 점검하는 방식으로, 출처(provenance) 검증까지 대신하는 것은 아니다.
원격 태그가 이동했을 때 도구가 아무 검토 없이 최신 커밋을 받아들이는 것으로 가정하면 안 된다. 변경 이유를 확인하고 필요한 경우 --relock을 실행해야 한다. 이동되거나 사라진 참조를 수락하는 옵션을 자동화 과정에 무분별하게 넣는 것은 피해야 한다.
조직 적용 전에 확인할 보안 경계
조직·저장소 관리자에게는 Require lockfile 정책도 제공된다. 정책 대상인 워크플로가 준비되지 않은 상태에서 강제 적용하면 실행이 차단될 수 있으므로, 우선 샘플 저장소에서 생성·검증하고 확산하는 순서가 권장된다. 정책 평가(Evaluate) 모드는 GitHub Enterprise Cloud에 한정된다는 점도 별도로 확인해야 한다.
잠금 파일의 SHA 변경은 곧 실행할 외부 코드의 변경 가능성을 뜻하므로, 단순 자동 생성 파일이 아니라 코드 리뷰 대상이다. 보호 브랜치·CODEOWNERS·CI 검증을 함께 운용하는 것은 실무적으로 합리적이다. 한편 GA 발표와 별개로 gh-actions-lock 공식 저장소는 CLI 확장의 pre-1.0 변경 가능성을 알리고 있어 자동화 스크립트의 업데이트 위험도 점검해야 한다.
핵심 결론은 명확하다. GitHub Actions lockfile은 예상하지 못한 의존성 커밋 변경을 줄이기 위한 장치이지, 모든 공급망 공격을 막는 단일 보안 솔루션은 아니다. 먼저 잠금 대상과 비대상을 구분하고, PR 검토와 업데이트 절차를 함께 마련해야 실제 운영상 의미가 있다.
