깃허브 액션 '@v4'가 몰래 바뀌면? — 워크플로 lockfile 정식 출시, 1인 개발자가 5분 만에 거는 법

깃허브 액션에서 uses: 누군가/액션@v4처럼 태그로 불러온 코드는, 그 태그가 다른 커밋으로 옮겨지면 다음 빌드부터 바뀐 코드가 그대로 돕니다. 깃허브는 2026년 10월 28일 이를 막는 워크플로 lockfile을 Free·Team·Enterprise Cloud 플랜에 정식 출시했습니다.

무슨 일인가

lockfile은 .github/workflows/actions.lock 파일에 워크플로가 쓰는 액션마다 '태그 이름 → 실제 커밋 → 원본 저장소 ID'를 적어 두는 방식입니다. 한 번 잠그면 태그가 이동해도 깃허브 액션은 기록된 커밋만 실행합니다. 파일은 GitHub CLI 확장 gh actions-lock으로 만들고 손으로 고치지 않으며, 액션이 내부에서 다시 부르는 액션(전이 의존성)까지 잠깁니다. 디펜더봇이 액션 버전 업데이트 PR을 열면 lockfile 항목도 같은 PR에서 함께 갱신되고, 관리자는 'Require lockfile' 정책으로 저장소 전체에 강제할 수 있습니다.

왜 중요한가

CI(자동 빌드·배포)에는 스토어 서명 키·Firebase 토큰·서버 비밀번호가 비밀값으로 들어가 있어서, 남의 액션 한 줄이 바뀌면 그 비밀값이 바로 노출됩니다. 2025년 3월 tj-actions/changed-files 사건 때도 태그가 악성 커밋으로 옮겨져 많은 저장소의 빌드 로그에 비밀값이 찍혔습니다. 오늘 아침 다룬 폴리마켓 외부 스크립트 사고와 같은 구조로, '같은 이름 아래 내용이 바뀌는' 공격입니다.

내 사업·앱에 무슨 의미

• 앱 운영자 — 외주 개발사가 만든 자동 빌드·스토어 업로드가 깃허브 액션이면, 저장소에 actions.lock이 있는지 물어볼 항목이 하나 생겼습니다.
• 개발자 — 깃허브 문서는 lockfile을 쓰는 저장소라면 워크플로 파일에 SHA를 따로 박을 필요가 없다고 설명합니다.
• 자체 서버 운영 — GitHub Enterprise Server(설치형)는 아직 지원 대상이 아닙니다.

제가 맥의 작업 폴더 전체를 find . -path '*/.github/workflows/*'로 확인해 보니 워크플로 파일은 0개였습니다. 앱몬스터 사이트는 깃허브 액션 없이 배포 스크립트로 직접 올리고 있어서, 당장 잠글 대상은 없고 나중에 자동 배포를 붙일 때 첫날부터 lockfile을 함께 두기로 했습니다.

지금 해볼 것

Q&A — 깃허브 액션 lockfile 자주 묻는 질문

출처

• GitHub Changelog — Workflow lockfiles are generally available (2026-10-28)
• GitHub Docs — Workflow dependency lockfiles
• github/gh-actions-lock (CLI 확장)