최근 들어 지속적 통합·지속적 배포(CI/CD) 파이프라인을 노리는 공급망 공격(Supply Chain Attack)이 빠르게 증가하고 있습니다. 이런 공격이 다른 조직만의 문제로 생각하기 쉽지만, 사실 조직 또한 공급망의 일부입니다. 회사가 자체적으로 사용하는 소프트웨어를 개발하든, 고객 서비스의 일부로 제공하든, 혹은 제품 형태로 판매하든 공급망 공격의 위험에서 완전히 자유로운 기업은 없습니다.
특히 Azure DevOps나 GitHub Enterprise 같은 CI/CD 도구를 사용하는 경우, 공격자는 이러한 시스템을 악용해 소스 코드를 손상시키거나 인프라를 교두보로 삼아 내부 네트워크에 침입할 수 있습니다. CI/CD 파이프라인의 보안 강화는 선택이 아니라 필수입니다. 이를 위해서는 사용 현황을 지속적으로 감사(audit)하고, 감사 로그를 SIEM 솔루션에 수집하며, 악성 활동을 감지하기 위해 로그를 실시간으로 모니터링해야 합니다.
Azure DevOps와 GitHub용으로 사전 구성된 Sumo Logic Cloud SIEM은 불필요한 노이즈를 제거하고 위협을 탐지하며, 소프트웨어 공급망의 가시성과 통제력을 강화하여 보안 운영 과정을 한층 더 간소화합니다.
공급망 공격의 정의
최근 몇 년간 공급망 공격은 뉴스 헤드라인을 장식하며 그 파급력을 입증했습니다. 대표적인 사례로는 다음이 있습니다.
- 솔라윈즈(SolarWinds) 침해: 약 18,000개 조직에 영향을 미친 파괴적 공격 사례
- 금융 소프트웨어 X_TRADER 침해: 금융 소프트웨어를 통한 공격으로, 통신·금융·핵심 인프라 기업을 겨냥한 사례
- 카세야(Kaseya) 침해: 관리 소프트웨어를 악용해 약 1,500개 고객사에 랜섬웨어 공격을 수행한 사례
공급망 공격은 여러 형태로 발생합니다. 2013년 HVAC 하청업체를 통한 타겟(Targe 침해 사례처럼 서비스 공급업체의 자격 증명을 탈취하는 방식에서, log4j 사례처럼 여러 소프트웨어 벤더가 사용하는 오픈소스 코드의 취약점을 악용하는 방식까지 다양합니다.
이 글에서는 소프트웨어 개발 및 배포 과정에서 발생하는 공급망 공격에 대해 살펴봅니다. 이러한 공격에서는 악성 코드가 신뢰된 소프트웨어에 주입되어, 정상적인 소프트웨어가 공격 도구로 변질될 수 있습니다.
결국, 공급망 공격은 ‘신뢰’를 악용하는 공격입니다. 공격자는 기업이 제공하는 소프트웨어나 서비스가 악의적이지 않고 충분히 안전할 것이라는 사용자들의 암묵적 신뢰를 노립니다.
CI/CD 파이프라인을 노린 공급망 공격의 침투 방식
앞서 언급한 주요 공격 사례들을 다시 살펴보면, 공격자들이 목표를 달성한 방식은 놀라울 만큼 유사합니다. 이들 사례 모두에서 공격자는 소프트웨어 빌드 또는 배포 과정의 한 단계를 하이재킹하여 악성 코드를 삽입했습니다. 각 공격 사례에서 사용된 침입 기법을 구체적으로 살펴보겠습니다.
- 솔라윈즈: “공격자는 오리온(Orion)의 빌드 서버 중 하나를 침해해 업데이트 모듈에 백도어를 삽입했습니다. 디지털 서명이 된 이 손상된 업데이트는 포춘 500대 기업을 포함한 약 18,000개의 SolarWinds 고객에게 배포되었으며, 웹사이트를 통해 제공되었습니다.”
- 3CX: (X_TRADER 공격으로 이어진 공급망 공격): “공격자는 최종적으로 Windows 및 macOS 빌드 환경 모두를 침해했습니다. Windows 빌드 환경에서는 TAXHAUL 런처와 COLDCAT 다운로드 프로그램을 배포하여, IKEEXT 서비스를 통해 DLL 검색 순서를 하이재킹하는 방식으로 LocalSystem 권한을 유지했습니다. macOS 빌드 서버는 Launch Daemons를 지속성 메커니즘으로 활용하는 POOLRAT 백도어로 침해되었습니다.”
- 카세야(Kaseya): “레빌(Revil) 해커들은 카세야의 VSA 원격 관리 서비스를 악용해 악성 업데이트 패키지를 배포했습니다.이 업데이트는 관리형 서비스 제공업체(MSP) 고객과 온프레미스 버전의 VSA 플랫폼을 사용하는 기업을 대상으로 실행되었습니다.”
Sumo Logic의 Azure DevOps 및 GitHub 규칙 세트
Sumo Logic Threat Labs 팀은 CI/CD 환경 내 공격자 활동을 모니터링하고 탐지하기 위해, Sumo Logic Cloud SIEM에서 사용할 수 있는 두 가지 규칙 세트를 출시했습니다.
- GitHub 규칙: GitHub에서 의심스러운 활동을 탐지하도록 설계된 규칙 세트로, 2024년 12월 6일에 공개되었습니다.
- Azure DevOps 규칙: Microsoft Sentinel의 Azure DevOps 탐지 규칙을 기반으로 하며, IBM X-Force Red의 백서 ‘클라우드에 숨기: Azure DevOps 서비스 악용을 통한 Microsoft Sentinel 분석 규칙 우회(Hiding in the Clouds: Abusing Azure DevOps Services to Bypass Microsoft Sentinel Analytic Rules)’에 제시된 튜닝 가이드를 참고해 제작되었습니다. 이 규칙은 2025년 3월 13일에 공개되었습니다.
Sumo Logic의 Azure DevOps 및 GitHub 규칙 사용 방법
Sumo Logic Cloud SIEM을 사용 중이라면, 이미 Azure DevOps 및 GitHub 규칙이 활성화된 상태일 가능성이 높습니다. 이 규칙을 효과적으로 활용하려면, 우선 CI/CD 플랫폼에서 로그를 수집해야 합니다. 아래는 로그 수집 절차를 간략히 정리한 것입니다.
Azure DevOps 로그 수집
Azure DevOps 로그를 수집하려면 다음 단계를 수행합니다.
- Azure DevOps 조직에서 감사(Auditing) 기능을 활성화합니다.
- 감사 로그를 Azure Event Hub로 스트리밍하도록 구성합니다.
- Sumo Logic Hosted Collector를 사용해 Event Hub에서 로그를 수집합니다.
자세한 단계는 Azure DevOps 조직의 감사 기능 활성화 및 감사 로그의 Azure Event Hub 스트리밍 구성에 관련된 Microsoft의 공식 문서를 참고하세요. 또한, Sumo Logic의 도움말 페이지에서 ‘Azure Event Hubs Source’ 항목을 확인하시면 로그 수집 구성에 대한 자세한 내용을 볼 수 있습니다. 마지막으로, 로그 소스를 생성할 때 반드시 ‘Cloud SIEM으로 포워드’ 옵션이 활성화되어 있는지 확인해야 합니다.
GitHub 로그 수집
참고: GitHub 규칙은 GitHub Enterprise 감사 로그를 기반으로 개발되었습니다.
GitHub 로그를 수집하려면 다음 단계를 수행합니다.
- GitHub 로그를 AWS S3 버킷으로 스트리밍합니다.
- Sumo Logic Hosted Collector를 통해 S3에서 GitHub 로그를 수집합니다.
구성 방법은 GitHub의 ‘Amazon S3로 스트리밍 설정하기’ 문서를 따라 로그 스트리밍을 설정하고, Sumo Logic의 도움말에서 ‘Amazon S3 Source’ 항목을 참조하여 S3 버킷에서 로그 수집을 구성합니다. 로그 소스를 설정할 때는 아래 필드를 반드시 추가해야 합니다.
| 필드 이름 | 필드 값 |
| _siemForward | true |
| _parser | /Parsers/System/Github/GitHub Enterprise Audit |
구성 예시 – Amazon S3 로그 소스를 통한 GitHub 로그 수집
Sumo Logic Cloud SIEM 규칙이 탐지하는 공격자 기법
Sumo Logic Cloud SIEM 규칙은 CI/CD 환경 내 다양한 공격자 기법을 탐지합니다. 아래는 Azure DevOps 및 GitHub 규칙에서 탐지할 수 있는 대표적인 공격 전술입니다.
기법: 풀 리퀘스트 검토 우회
탐지 규칙:
- Azure DevOps – 최초 감지 풀 리퀘스트 정책 우회
- GitHub – 풀 리퀘스트 검토 요건 제거
CI/CD 파이프라인은 빠른 속도를 위해 설계되어 있어, 개발자는 하루에도 여러 번 프로덕션에 코드를 업데이트할 수 있습니다. 이처럼 빠른 릴리스 속도는 비즈니스에 이점을 제공하지만, 동시에 검토되지 않은 코드나 악성 코드가 프로덕션으로 직접 반영될 위험도 증가합니다.
이러한 위험을 줄이는 가장 기본적인 방법은 동료 검토(peer review) 절차를 두는 것입니다. 즉, 빌드·배포 단계로 넘어가기 전에 반드시 풀 리퀘스트(Pull Request, PR)를 통해 승인 과정을 거치도록 해야 합니다.
OWASP 발표 CI/CD 보안 10대 위험에 따르면, 검토 절차를 우회하는 행위야말로 CI/CD 환경에서 가장 큰 보안 위험으로 꼽힙니다. 실제 사례로, 2021년 3월 PHP 코드베이스에 승인되지 않은 변경 사항이 반영된 사건이 있었습니다.
물론 특정 상황에서는 검토 우회가 필요할 수도 있습니다. Azure DevOps는 ‘우회 정책’ 설정을 통해 PR 정책을 일시적으로 우회할 수 있는 기능을 제공합니다. 조직에는 일시적으로라도 풀 리퀘스트 정책을 우회해야 하는 타당한 이유가 있을 수 있습니다. 그러나 일시적으로 이러한 정책을 허용하더라도, 남용 가능성에 대비한 모니터링이 반드시 필요합니다.
예를 들어, Azure DevOps의 규칙인 ‘최초 감지 풀 리퀘스트 정책 우회(First seen pull request policy bypassed)’는 최근 90일간 해당 사용자가 한 번도 PR 정책을 우회한 적이 없는데 새로운 우회 행위가 발생했을 경우 보안 운영센터(SOC) 분석팀에 경고를 생성합니다. 이 경고가 트리거되면, SOC 분석팀은 해당 우회가 정당한 조치였는지, 또는 계정 탈취나 내부자 위협 행위가 개입된 것은 아닌지 조사해야 합니다.
최초 감지 풀 리퀘스트 정책 우회 규칙 및 로그 샘플
GitHub 규칙 ‘PR 검토 요건 제거(PR review requirement removed)’는 풀 리퀘스트 검토를 우회하는 것도 모니터링하지만, 리포지토리에서 검토 요구 사항을 완전히 제거하는 방식으로 수행합니다.
PR 검토 요건 제거 규칙 및 로그 샘플
기법: 권한 그룹의 구성원 변경
탐지 규칙:
- Azure DevOps – 관리자 그룹으로 변경
- GitHub – 관리자 추가 또는 초대
2019년 5월, 공격자가 스택 오버플로(Stack Overflow) 네트워크를 침해해 ‘스택 교환 네트워크 전반에서 관리자 및 개발자 수준의 접근 권한을 획득’한 사건이 발생했습니다. 이 공격으로 인해 소스 코드가 유출되고, 184명의 스택 오버플로 사용자의 개인 식별 정보(PII)가 탈취되었습니다.
사용자가 관리자 권한을 획득하는 이벤트는 그 영향 범위가 매우 크기 때문에 반드시 주목해야 합니다. OWASP는 부적절한 ID 및 접근 관리를 CI/CD 파이프라인의 두 번째로 큰 위험 요소로 분류합니다. 이 위험에는 최소 권한 원칙(the principle of least privilege)을 따르지 않거나, ID 관리가 제대로 이루어지지 않아 파이프라인이 침해에 노출되는 다양한 상황이 포함됩니다.
Azure DevOps의 규칙인 ‘관리자 그룹으로 변경(Changes made to administrator group)’은 사용자가 프로젝트 관리자, 프로젝트 컬렉션 관리자, 프로젝트 컬렉션 서비스 계정, 빌드 관리자 및 프로젝트 컬렉션 빌드 관리자와 같은 Azure DevOps의 여러 권한 그룹에 추가될 경우 SOC 분석팀에 알림을 전송합니다.
이 규칙이 트리거되면, SOC 분석팀은 그룹 변경이 승인된 변경인지 확인해야 합니다. 만약 CI/CD 환경이 변경 관리의 범위 내에 있다면, 관련 변경 요청 티켓을 검토하고 그 변경을 수행한 사용자가 계정 탈취나 내부 위협의 징후를 보이지 않는지도 조사해야 합니다.
관리자 그룹으로 변경 규칙 및 로그 샘플
마찬가지로 이름에서 알 수 있듯이 GitHub의 ‘관리자 추가 또는 초대(Administrator added or invited)’ 규칙은 새 관리자가 추가되거나 초대되는 시점을 감지합니다.
관리자 추가 또는 초대 규칙 및 로그 샘플
기법: 악성 도구 통합
탐지 규칙:
- Azure DevOps – 최초 감지 – 신규 확장 기능 설치
- GitHub – API와 상호작용하는 애플리케이션 최초 감지
CI/CD 환경에는 코드 검사, 리소스 관리, 시크릿 대체 등 다양한 기능을 추가할 수 있는 서드파티 도구와 서비스의 풍부한 생태계가 존재합니다. 하지만 이 도구와 서비스는 동시에 공격 벡터(attack vector)가 될 수도 있습니다.
2020년 7월, 정적 분석(SAST), 코드 커버리지, IaC 분석 기능을 제공하는 딥소스(DeepSource) GitHub 애플리케이션의 자격 증명이 유출되어 결국 해당 애플리케이션 사용자들의 자격 증명 탈취 공격으로 악용된 사건이 있었습니다.
Azure DevOps 플랫폼에는 확장 기능 마켓플레이스가 포함되어 있습니다. 딥소스(DeepSource) 사례에서 볼 수 있듯이 확장 기능을 설치하거나 사용하면 확장 프로그램 자체에서 악성 코드가 유입되거나, 공격자가 확장 기능을 발판으로 개발·운영 환경 내 접근 권한을 획득할 위험이 존재합니다. OWASP는 이러한 위험을 ‘제삼자 서비스의 무분별한 사용’ 범주로 분류하며, CI/CD 파이프라인에서 여덟 번째로 흔한 위험으로 꼽습니다.
Azure DevOps의 ‘신규 확장 기능 설치(New extension installed)’ 규칙은 지난 90일 동안 설치 이력이 없는 새로운 확장 기능이 Azure DevOps 조직에 설치될 때 트리거됩니다. 이 규칙이 작동하면, SOC 분석팀은 변경 관리 티켓을 통해 해당 확장 기능이 승인된 변경 사항인지 또는 조직 내에서 승인된 확장 기능 목록에 포함되어 있는지 검토해야 합니다.
신규 확장 기능 탐지 규칙 및 로그 샘플
GitHub의 ‘API와 상호작용하는 애플리케이션 최초 감지(First seen application interacting with API)’ 규칙은 최근 90일 동안 관찰되지 않았던 애플리케이션이 GitHub API와 상호작용할 때 이를 감지합니다. 이 규칙은 단순히 새 확장 기능만 탐지하는 Azure DevOps 규칙보다 범위가 넓으며, API와 통신하는 모든 미확인 애플리케이션을 탐지 대상으로 포함합니다.
API와 상호작용하는 애플리케이션 최초 감지 규칙 및 로그 샘플
CI/CD 환경에서의 로그 기록은 보안 모니터링의 핵심 요소입니다. OWASP 역시 이를 강조하며, ‘로깅과 가시성 부족’을 10번째 위험 요인으로 분류합니다. OWASP는 “로깅과 가시성 부족으로 인해 공격자가 공격 체인의 어떤 단계에서도 탐지되지 않은 채 악성 행위를 수행할 수 있으며, 공격 이후 조사 과정에서도 공격자의 전술, 기법, 절차(TTP)를 식별하기 어렵게 만든다.”고 설명합니다.
Sumo Logic을 이용한 CI/CD 환경 보호
공급망 공격은 점점 더 정교해지고 있으며, CI/CD 환경은 그중에서도 주요 표적입니다. Sumo Logic의 Cloud SIEM 규칙을 활용해 CI/CD 생태계를 지속적으로 모니터링하면, 침해로 이어지기 전에 의심스러운 활동을 조기에 탐지하고 대응할 수 있습니다.
Sumo Logic Cloud SIEM에 대한 자세한 내용은 제품 페이지 또는 대화형 데모(Interactive Demo)에서 확인할 수 있습니다.
