GitHub Actions의 OpenID Connect(OIDC) 토큰 발급 방식이 잠재적인 보안 위험을 안고 있다는 문제가 제기되었습니다. 현재 GitHub Actions는 워크플로 내에서 `id-token: write` 권한을 부여하면, 실행 중인 작업이 임의의 `audience`를 지정하여 OIDC 토큰을 발급받을 수 있습니다. 이는 취약하거나 악성인 서드파티 코드가 원래 의도하지 않은 다른 서비스로 접근 권한을 확장하는 데 악용될 수 있다는 우려를 낳고 있습니다.
OIDC의 `aud` 클레임은 토큰을 수락할 서비스를 제한하는 중요한 보안 요소입니다. 토큰을 받은 서비스는 `audience`가 자신과 일치할 때만 토큰을 수락해야 합니다. 이는 특정 서비스용 토큰이 탈취되더라도 다른 서비스에서 오용되는 것을 방지하는 심층 방어(defense in depth) 역할을 합니다. 하지만 GitHub Actions는 런타임에 `audience`를 동적으로 지정하는 방식을 채택하고 있어, 공격자가 `audience`를 통제할 경우 이 방어 효과가 약해질 수 있습니다. 반면 GitLab CI/CD는 작업 정의에 `audience`를 정적으로 선언하도록 강제하여 이러한 위험을 줄이고 있습니다. 예를 들어, PyPI 배포 작업이 `sts.amazonaws.com`용 토큰을 발급받아 AWS 접근에 악용되는 상황을 막기 위해, GitHub도 `id-token: [pypi]`와 같이 허용할 `audience`를 미리 선언하는 방식이 필요하다는 목소리가 커지고 있습니다.
이러한 보안 문제는 CI/CD 환경에서 OIDC가 기계 신원(machine identity)을 제공하며 외부 서비스와 신뢰 관계를 맺는 데 핵심적인 역할을 한다는 점에서 중요합니다. Trusted Publishing이나 Sigstore와 같은 서비스들이 OIDC를 활용해 워크플로의 신원을 검증하고 있습니다. 따라서 GitHub Actions가 작업별로 허용할 `audience`를 명시적으로 선언할 수 있는 기능을 추가해야 한다는 제안이 나옵니다. 이는 특정 작업이 특정 서비스에만 접근하도록 제한하여 공격 범위를 최소화할 수 있습니다. 기존의 `id-token: write`는 덜 안전한 포괄적 옵션으로 유지하되, 정적 제약을 지원함으로써 독립적인 OIDC 연동 서비스 간의 공격 전환을 줄일 수 있을 것입니다. 이는 GitHub Actions의 전반적인 보안 수준을 높이고 사용자들에게 더 안전한 CI/CD 환경을 제공하는 데 기여할 것으로 보입니다.