GitHub Actions lockfile 공개 미리보기: 고정한 커밋도 검토해야 한다
워크플로 파일을 리뷰했는데 다음 실행에서 다른 코드가 실행된다면 무엇을 승인한 걸까요. GitHub가 10월 14일 공개한 workflow dependency lockfile 미리보기는 태그·브랜치 표기와 실제 실행할 커밋을 연결합니다. 작은 팀의 핵심 질문은 파일 생성 여부보다 누가 고정할 코드를 검토하고 이후 업데이트를 승인하느냐입니다.
공개 범위와 실행 근거
확인한 발표의 수정된 범위는 GitHub Enterprise Cloud, data residency를 사용하는 Enterprise Cloud, Team, Free입니다. 일반 출시가 아닌 공개 미리보기이며 gh-actions-lock 저장소는 GHES 미지원과 pre-1.0 변경 가능성을 안내합니다. 도입 문서에는 확인 날짜와 사용한 확장 버전을 함께 남기세요.
태그를 읽는 일과 커밋을 승인하는 일
공식 확장은 .github/workflows/actions.lock을 생성합니다. 도입한 workflow의 action, 전이 의존성, 재사용 workflow 의존성을 기록된 커밋으로 실행하도록 연결합니다. 태그가 이동해도 승인한 코드와 실행 코드가 조용히 갈라지는 위험을 줄이지만, 고정된 커밋에 취약점이 없다고 보증하지는 않습니다.
검토 가능한 작은 도입부터
여기부터는 운영 제안입니다. 먼저 비밀과 배포 권한이 없는 시험 workflow 하나를 정하고 현재 uses 목록·의존성 소유자·실행 목적을 적으세요. 생성된 workflow와 lockfile 변경을 한 PR에서 함께 읽고 실제 실행 기록까지 연결합니다. 파일이 생겼다는 사실만으로 운영 전체에 정책을 강제하지 마세요.
업데이트를 맡을 사람까지 정하기
공식 README의 gh actions-lock --verify는 파일을 쓰지 않는 검증 경로입니다. --verify-local은 오프라인 구조 검사여서 신뢰성 검사를 대신하지 않습니다. CI의 검사와 의존성 코드 리뷰를 나눠 기록하고, 업데이트 PR 담당자와 실패 시 중단·복구 기준을 정하세요. 이 글에서는 확장을 설치하거나 독자의 저장소를 변경하지 않았습니다.
Dependabot이 도입된 workflow의 action 버전을 갱신하면 같은 PR에서 대응 lockfile 항목도 재생성한다는 것이 발표 내용입니다. 자동 생성된 diff도 승인 대상입니다. 참조 변경과 실제 커밋 변경을 함께 보고, 새 코드가 요구하는 권한과 네트워크 접근이 달라졌는지 확인하는 것이 이 글의 제안입니다.
실무의 오해는 재현 가능한 실행을 안전한 실행으로 읽는 것입니다. 커뮤니티가 피드백에 참여했다는 공식 안내는 있지만 보안 사고 감소율이나 모든 프로젝트의 호환성을 추정하지 않았습니다. 파일 형식과 옵션이 바뀔 수 있으므로 도입 직전 공식 README를 다시 확인하고, 검토·고정·업데이트 세 책임을 작업표에 남기세요.
공식 출처
2026년 10월 15일 공식 발표·저장소·문서를 확인했습니다. 제품 기능과 이 글의 운영 제안을 구분했습니다.