Checkmarx 공식 Jenkins 플러그인 악성코드 감염: 오픈소스 공급망 공격과 그 대응

2. 사건 개요: Checkmarx Jenkins 플러그인 악성코드 유포

2024년 6월 첫 주말, 보안 기업 Checkmarx는 자사의 공식 Jenkins Application Security Testing(AST) 플러그인에 악성코드가 삽입되어 Jenkins Marketplace를 통해 배포되었음을 공식 확인했습니다. 이번 사고에서 유포된 악성 패키지는 정보 탈취(Infostealer) 기능을 포함하고 있어, 해당 플러그인을 설치·사용한 기업이나 개발자의 민감 정보가 외부로 유출될 위험에 노출됐습니다. Checkmarx는 공격 사실을 인지한 즉시 Jenkins Marketplace에서 해당 플러그인을 제거하고, 피해 방지 및 세부 대응을 위한 가이드라인을 공개했습니다.

3. 플러그인 감염 및 주요 피해 가능성

감염된 플러그인은 Jenkins 파이프라인 내에서 실행될 때, 사용자의 자격 증명, API 키, 빌드 구성 파일, 소스 코드 저장소 접근 정보 등 민감 데이터를 외부 서버로 전송하는 구조로 만들어졌던 것으로 분석되었습니다. Jenkins는 전 세계 소프트웨어 개발팀에서 CI/CD 파이프라인 자동화에 광범위하게 사용되는 도구이며, 특히 보안 스캐닝 및 정적 분석 플러그인은 개발 워크플로우의 핵심 역할을 합니다.

따라서 Checkmarx의 AST 플러그인을 통해 수집·처리된 데이터에는 애플리케이션 보안 진단 결과물, 취약점 보고서, 그리고 시스템에 접근 가능한 관리자 권한 정보가 포함될 수 있어, 피해 규모는 상당할 수 있습니다. 플러그인이 Jenkins Marketplace를 통해 배포된 만큼, 글로벌 수많은 조직이 이번 사고로 인한 잠재적 피해자에 해당합니다.

4. 공격 경로 및 원인 분석

현재 공격의 정확한 경위와 초기 침투 방식은 조사 중입니다. 그러나 예비 분석에 따르면, 플러그인 개발·배포 과정에서의 보안 관리 미흡이나 내부 개발 환경 침해 등으로 악성 코드가 포함된 것으로 추정됩니다. 오픈소스와 패키지 관리 생태계에서 소프트웨어가 작성·검증·패키징·배포되는 각 단계는 서로 다른 보안 신뢰 구간을 형성하며, 이들 중 어느 하나라도 취약하면 전체 공급망이 위협에 노출됩니다.

특히 Jenkins Marketplace는 플러그인 게시 전 기본 무결성 검증을 시행하지만, 패키지 내부 코드에 대한 정적 분석이나 서명 검증은 실시간으로 이루어지지 않아, 숙련된 공격자가 악성 플러그인을 상당 기간 유통시킬 수 있는 여지를 줍니다.

5. 오픈소스 공급망의 구조적 취약점 재조명

이번 Checkmarx 사례는 소프트웨어 공급망 보안의 근본 과제를 다시 한 번 드러냅니다. NPM, PyPI, Maven Central, RubyGems 등 대표 오픈소스 패키지 레지스트리뿐 아니라, Jenkins Marketplace처럼 특화된 개발 도구 생태계도 공격자 표적이 되고 있습니다. 공급망 공격이 특히 위협적인 이유는 최종 사용자가 활용하는 도구의 무결성을 자체적으로 검증하기 매우 어렵기 때문입니다. 개발자들은 신뢰할 수 있는 출처의 패키지를 설치하지만, 코드 검토는 대부분 하지 않는 것이 현실입니다.

공급망의 각 참가자—개발자, 패키지 관리자, CI/CD 운영자, 최종 사용자—가 수행할 수 있는 보안 조치에는 한계가 있으며, 전체 생태계 차원의 통합 보안 체계 없이는 유사한 사고가 반복될 수밖에 없습니다.

6. 최근 유사 공급망 공격 사례 비교

2023~2024년 사이 대표적 공급망 공격들을 살펴보면, 그 방식과 공격 대상이 점점 다양해지고 있습니다.

6.1 XZ 백도어 사고(2024)

리눅스 시스템 압축 유틸리티 XZ Utils의 유지관리자에 대한 장기적 사회공학 및 신뢰 구축 후 악성 백도어 코드를 삽입한 매우 정교한 공격이 있었습니다.

6.2 PyPI 악성 패키지 유포(2023~2024)

Python 패키지 인덱스(PyPI)에서 수백 개의 악성 패키지가 반복적으로 배포되었고, 오타 유사 패키지명(타이포스쿼팅), 의존성 혼란 등 다양한 기법이 동원되었습니다. 공격 초점은 개발자 환경 감염을 통한 빌드 파이프라인 전체 침투에 있었습니다.

이번 Checkmarx 사고도 이러한 신뢰할 수 있는 배포 채널에 악성 코드가 유입되는 구조로, 피해 범위와 위협 수준 자체가 매우 심각한 사례에 해당합니다.

7. 현재까지 대응 현황 및 Checkmarx 공식 지침

Checkmarx는 사고 인지 즉시 해당 플러그인을 Marketplace에서 삭제하고, 공식 보안 알림을 통해 주요 대응 절차를 안내했습니다.

• 즉시 플러그인 비활성화 및 제거: Jenkins 관리 콘솔에서 해당 플러그인을 즉시 비활성화 및 삭제 권고
• 자격 증명 순환: 플러그인 접근 자격 증명, API 키, 비밀 정보 등 모든 인증 정보를 빠르게 순환·재발급
• 로그 감사: Jenkins 빌드 및 네트워크 트래픽 로그를 분석해 외부 통신이나 정보 유출 조짐을 확인
• 공식 채널 모니터링: Checkmarx 보안 권고 페이지에서 최신 대응 정보와 패치 상황을 주기적으로 확인

현재 Checkmarx 보안팀은 피해 범위 파악과 동시에 패키지 서명·검증 강화 방안을 검토 중입니다.

8. 기업·개발자를 위한 예방 및 대응 조치 제안

이번 사고를 교훈 삼아 기업과 개발자들은 다음과 같은 다층적 보안 조치를 체계적으로 이행해야 합니다.

• 플러그인 설치 전 신뢰 검증: 다운로드 수, 최종 업데이트 일자, 개발자·조직 신뢰도 등을 미리 확인하고, 가능할 경우 소스 코드도 리뷰합니다.
• 최소 권한 원칙 적용: Jenkins 플러그인 접근 권한은 필수 최소 범위로 제한하며, 네트워크 외부 데이터 전송 등도 상시 모니터링합니다.
• SBOM(소프트웨어 구성명세서) 및 변경이력 관리: 프로젝트 의존 플러그인을 명확히 관리·기록하고, 감사와 이력 관리도 정기적으로 진행합니다.
• 네트워크 차단 정책 적용: egress filtering 등으로 예기치 않은 외부 도메인 통신을 사전 차단하고 이상 징후는 즉시 탐지됩니다.
• 정기적 보안 교육: 개발팀을 대상으로 공급망 공격 식별, 신뢰 출처 확인, 해시값 검증 등 기본 확인 습관이 생활화될 수 있도록 교육합니다.

9. 결론 및 시사점

Checkmarx 공식 Jenkins 플러그인 감염 사고는, 핵심 DevSecOps 도구마저 공급망 공격의 타깃이 될 수 있다는 점을 생생하게 보여줍니다. 특히 보안 점검을 위한 도구가 도리어 공격 도구로 악용된 이번 사례는, 공급망 검사 체계 전반의 근본 강화를 요구하는 강력한 경고장입니다.

향후에는 패키지 레지스트리뿐 아니라, 각 개발 조직 내부에서도 코드 서명·검증 및 커뮤니티 위협 정보 공유 체계가 더욱 촘촘히 작동해야 합니다. ‘보안은 도구를 신뢰하는 것에서 시작된다’는 점을 이번 사고는 모든 IT 조직에 깊이 각인시켰습니다.