GitHub Actions lockfile로 실행 커밋을 고정하는 범위를 확인해보세요

어떤 플랜에서 무엇이 달라지나요?

10월 14일 공지의 대상은 Enterprise Cloud, 데이터 레지던시를 지원하는 Enterprise Cloud, Team, Free예요. 아직 public preview라 동작이 바뀔 수 있어요. 워크플로에 태그나 브랜치 참조를 남겨 두면서 실제 실행 코드는 잠근 커밋으로 고정해요.

태그를 검토한 뒤 upstream에서 같은 태그를 다른 커밋으로 옮기는 상황에 대응해요. 다만 잠금은 의존성의 안전성을 판정하지 않아요. 검토할 대상이 고정될 뿐, 악성 코드가 든 커밋을 골랐다면 그 코드도 그대로 실행돼요.

lockfile은 어떻게 만들고 관리하나요?

공식 개념 문서는 GitHub CLI 확장 gh actions-lock으로 .github/workflows/actions.lock을 생성하라고 해요. 자동 생성 파일이므로 손으로 고치면 안 돼요. 문서의 설치 안내로 확장을 준비한 뒤 생성된 의존성 참조와 커밋을 대조하세요.

파일은 워크플로가 쓰는 의존성 목록과 참조가 가리키는 커밋을 기록해요. 출처 저장소의 숫자 식별자도 담아요. 도입한 워크플로의 의존성은 모두 lockfile에 있어야 하고, 실행 때는 기록한 커밋을 사용해요. allowed actions 정책도 이 커밋을 검사해요.

재사용 워크플로 안쪽도 같이 잠기나요?

일반 action이 다른 action을 부르는 전이 의존성까지 포함해요. 재사용 워크플로 호출도 잠그지만, 그 안에서 쓰는 의존성은 재사용 워크플로를 정의한 저장소의 lockfile을 기준으로 해요. 호출하는 저장소의 파일 하나로 내부 의존성까지 모두 통제한다고 생각하면 범위를 잘못 잡게 돼요.

도입 준비 때는 호출 관계를 직접 그려 보는 방법을 제안해요. 저장소 밖의 재사용 워크플로를 발견하면 담당 팀과 잠금 적용 여부를 확인하세요. 호출부 변경만 검토하는 담당자와 내부 action을 갱신하는 담당자가 다르면 각각 어느 변경을 검토할지 정해 두는 편이 좋아요.

조직 전체에 적용하기 전에는 무엇을 확인하나요?

워크플로별로 순차 도입할 수 있어요. Require lockfile 정책은 엔터프라이즈·조직·저장소 관리자가 잠금을 요구할 수 있게 해요. Dependabot은 이미 도입한 워크플로의 action 버전 업데이트를 열 때 대응 항목도 같은 PR에서 다시 생성해 참조와 커밋을 맞춰요.

팀의 적용 순서로는 다음을 제안해요.

1. 담당자가 분명한 CI 워크플로를 골라 의존성과 생성된 커밋 변경을 대조하세요.
2. 재사용 워크플로를 제공하는 저장소의 잠금 여부를 따로 확인해요.
3. Dependabot 업데이트 PR에서 참조와 잠금 항목을 함께 검토해 보세요.
4. 빠진 워크플로와 갱신 담당자를 정리한 뒤 잠금 필수 정책을 검토하세요.

전체 강제를 먼저 켜면 아직 옮기지 않은 워크플로가 걸릴 수 있어요. 정책 적용 전에 도입 대상 목록과 실제 lockfile의 워크플로 목록을 비교해 보세요. 공식 자료 확인일은 2026-10-17이에요.