소프트웨어 공급망을 노린 보안 위협이 갈수록 교묘해지는 가운데, 깃허브(GitHub)가 CI/CD 자동화 도구인 '깃허브 액션(GitHub Actions)'의 의존성을 안정적으로 관리할 수 있는 '워크플로 의존성 잠금파일(actions.lock)' 기능을 공개 프리뷰로 선보였다.
소프트웨어 개발 현장에서는 빌드나 배포 자동화를 위해 액션 코드를 불러올 때 보통 특정 버전 태그나 브랜치명을 지정해 사용한다. 'actions/checkout@v4'나 '@v6'처럼 가독성 높은 버전을 적어두는 식이다. 문제는 외부 개발자나 오픈소스 유지관리자가 기존 태그나 브랜치가 가리키는 실제 코드를 임의로 변경하거나, 계정이 탈취돼 악성 코드가 덮어씌워질 때 발생한다. 동일한 워크플로를 돌려도 어제와 오늘 실제로 실행되는 코드가 달라지는 보안 사각지대가 생겼던 셈이다.
이번에 도입된 잠금파일 체계는 이 같은 문제점을 깔끔하게 파고든다. 워크플로 파일 내부에는 사람이 읽기 편한 버전 명칭을 그대로 유지하면서도, 시스템 백엔드에서는 검토가 끝난 정밀한 커밋(SHA) 값을 별도의 잠금파일에 기록해 고정된 코드만 구동되도록 통제한다. 중간에 태그가 다른 코드로 바뀌더라도 잠금파일에 기록된 특정 커밋만 불러오기 때문에 기습적인 코드 변조나 공급망 공격을 원천 차단할 수 있다.
잠금파일의 생성과 관리는 깃허브 CLI 전용 확장 프로그램인 'gh actions-lock'을 통해 이뤄진다. 개발자가 프로젝트 루트에서 해당 명령어를 실행하면, 각 워크플로가 직접 참조하는 외부 액션은 물론 간접적으로 연결된 하위 전이 의존성(Transitive Dependencies), 재사용 가능한 워크플로까지 모두 추적해 '.github/workflows/actions.lock' 파일에 한데 모은다. 잠금파일에는 의존성 경로와 해시값 외에도 소속 조직 및 리포지토리의 고유 식별자(ID)가 함께 기록되어, 외부 소스코드의 소유권이 슬그머니 바뀌는 변칙 공격까지 점검한다.
지속적인 코드 관리를 돕는 자원들과의 연동도 다듬었다. automated 의존성 업데이트 도구인 '디펜다봇(Dependabot)'은 이미 잠금파일이 설정된 워크플로의 액션 버전을 높일 때, 풀 리퀘스트(PR) 내부에서 해당 'actions.lock' 파일의 커밋 기록까지 알아서 갱신하도록 설계됐다. 개발진이 일일이 명령어를 돌려 잠금파일을 다시 찍어낼 필요 없이 코드 검토와 업데이트를 동시에 마칠 수 있다.
관리자를 위한 중앙 규제 정책도 준비됐다. 깃허브는 엔터프라이즈, 조직, 리포지토리 단위에서 잠금파일 사용을 강제할 수 있는 '잠금파일 필수 적용(Require lockfile)' 정책을 함께 제공한다. 이를 활성화하면 잠금파일에 포함되지 않은 액션을 호출하거나 잠금 기록이 오염된 워크플로는 실행 자체가 거부된다.
개발 현장에서는 전체 시스템에 한 번에 정책을 들이대기보다는, 보안 수준이 중요한 일부 핵심 워크플로부터 단계를 나눠 적용하는 방식을 권장하는 분위기다. 깃허브 CLI 도구가 제공하는 정밀 검증 옵션('gh actions-lock --verify')을 지속적 통합(CI) 파이프라인에 먼저 붙여 변경 사항을 사전 점검하는 절차가 안착될 필요가 있어서다.
이번 공개 프리뷰는 깃허브 프리(Free), 팀(Team), 깃허브 엔터프라이즈 클라우드(GitHub Enterprise Cloud) 및 데이터 레지던시가 적용된 엔터프라이즈 클라우드 고객 전반을 대상으로 일괄 열렸다.
형상 관리와 빌드 자동화 영역에서 소스코드 자체의 안전성만큼이나 빌드 환경을 구성하는 도구의 신뢰성이 핵심 화두로 떠오른 만큼, 가독성을 해치지 않으면서 실행 정밀도를 가두는 이번 의존성 잠금 체계는 데브옵스(DevOps) 및 보안 현장에 빠르게 스며들 것으로 보인다.
