CI/CD 파이프라인은 이제 공격 표면이다
Novee Security가 공개한 Cordyceps 취약점 패턴은 보안 커뮤니티에 다시 한번 경종을 울리고 있다. 핵심은 간단하다. 인증 없이 CI/CD 파이프라인에 접근할 수 있는 경로가 존재했다는 것이다. 이는 단순한 설정 실수처럼 보일 수 있지만, 실제로는 빌드 스크립트 변조, 시크릿 탈취, 배포 산출물 조작 등 치명적인 공격으로 이어질 수 있는 진입점이 된다. CI/CD를 "개발 편의 도구"로만 바라보던 시각이 얼마나 위험한지를 다시 한번 확인시켜 주는 사례다.
왜 파이프라인 접근 제어가 간과되는가
백엔드 서비스의 API 엔드포인트나 데이터베이스 접근 권한에는 꼼꼼하게 인증·인가 정책을 적용하면서도, Jenkins, GitHub Actions, GitLab CI 같은 파이프라인 도구의 접근 제어는 상대적으로 느슨하게 운영되는 경우가 많다. 이유는 몇 가지로 압축된다.
- 파이프라인은 "내부망에 있으니 괜찮다"는 안일한 가정
- 빠른 개발 사이클 속에서 보안 설정보다 기능 배포가 우선시됨
- CI/CD 도구 자체의 접근 정책이 기본값으로 열려 있는 경우가 많음
- 파이프라인 설정 파일(
.yml,Jenkinsfile)이 코드 리뷰에서 보안 관점으로 검토되지 않음
이러한 관행이 쌓이면, 파이프라인은 사실상 인증 없이 내부 인프라 전체에 접근할 수 있는 관리자 권한 통로가 된다.
실무에서 점검해야 할 접근 제어 포인트
Cordyceps 패턴이 시사하는 바를 실무에 적용하려면 파이프라인 단계별로 접근 제어를 명시적으로 정의해야 한다. 아래는 GitHub Actions 환경에서 시크릿 노출 범위를 최소화하는 예시다.
jobs:
deploy:
runs-on: ubuntu-latest
environment: production # 환경별 승인 정책 적용
permissions:
contents: read # 최소 권한 원칙
id-token: write # OIDC 기반 인증만 허용
steps:
- uses: actions/checkout@v4
이처럼 permissions 블록을 명시하고, 환경(environment)별 보호 규칙을 설정하는 것만으로도 공격 표면을 상당히 줄일 수 있다. 추가로 점검해야 할 항목은 다음과 같다.
- 파이프라인 트리거 범위 제한: 외부 PR에서 시크릿에 접근 가능한 워크플로우가 실행되지 않도록 설정
- 시크릿 범위 분리: 모든 잡(job)이 동일한 시크릿을 공유하지 않도록 환경별로 격리
- 파이프라인 에이전트 네트워크 격리: 빌드 에이전트가 프로덕션 내부망에 직접 접근하지 못하도록 제한
- 감사 로그 활성화: 파이프라인 실행 이력과 시크릿 접근 로그를 주기적으로 모니터링
정리
- CI/CD 파이프라인은 내부 인프라 전체에 접근 가능한 고권한 경로로, 인증·접근 제어를 애플리케이션 수준과 동등하게 관리해야 한다.
- 최소 권한 원칙(Least Privilege)을 파이프라인 설정 파일 수준에서 명시적으로 적용하고, 환경별 보호 규칙을 반드시 구성해야 한다.
- 파이프라인 설정 파일(
.yml,Jenkinsfile)도 코드 리뷰 단계에서 보안 관점의 검토 대상에 포함시켜야 한다.