선제적 방어: 코드 파이프라인 및 CI/CD 인프라 강화

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

---

소개

소프트웨어 공급망 보안 환경은 큰 변화를 겪었습니다. 최근 침입 공격 사례를 보면 정교한 공격자들이 신뢰할 수 있는 보안 및 프로그래밍 도구를 침해하여 엔지니어링 수명 주기를 체계적으로 표적으로 삼고 있음을 알 수 있습니다.

이러한 침입 공격은 세 가지 주요 전술을 보여줍니다.

• 공격자는 신뢰할 수 있는 보안 스캐너, 유틸리티 라이브러리, AI 개발자 도구를 표적으로 삼아 빌드 파이프라인 내에서 이러한 시스템에 부여된 승격된 권한을 악용합니다.

• 공격자는 고도로 맞춤화된 소셜 엔지니어링, 악성 확장 프로그램 또는 타이포스쿼팅된 로컬 종속 항목을 통해 개발자 워크스테이션과 통합 개발 환경(IDE)을 표적으로 삼아 로컬 엔지니어링 환경에서 직접 비공개 암호화 키, API 토큰, 활성 세션 사용자 인증 정보를 유출합니다.

• 공격자는 단순히 보안 침해된 정적 사용자 인증 정보에만 의존하지 않고 GitHub Actions 캐시 포이즈닝, OpenID Connect(OIDC) 토큰 추출, 변경 가능한 작업 태그 파괴 등 고급 파이프라인 조작 기법을 사용하여 합법적인 암호화 출처 기록을 그대로 유지하는 보안 침해된 패키지를 게시합니다.

이 블로그에서는 이전 가이드(여기 및 여기)를 바탕으로 소프트웨어 및 플랫폼 설계자가 전체 소프트웨어 개발 수명 주기(SDLC)에서 적극적으로 악용되고 있는 위협 벡터, 서드 파티 위험, 아키텍처 취약점으로부터 소프트웨어 공급망을 보호하기 위해 설계한 실행 가능한 청사진을 제공합니다.  

지속적 통합 및 지속적 배포(CI/CD) 보호 장치를 구축하고, 개발자 워크플로를 강화하며, 강력한 엔드 투 엔드 심층 방어를 구축하는 방법을 자세히 알아보려면 계속 읽어보세요. 

다층적 접근 방식

파이프라인의 각 단계를 독립적인 보안 영역으로 취급하는 것만으로는 더 이상 충분하지 않습니다. 이러한 다층적 공격은 전체 빌드 파이프라인의 취약점을 표적으로 삼기 때문입니다. 이러한 지속적인 위협을 방어하려면 그림 1에 제시된 소프트웨어 개발 수명 주기의 5가지 핵심 요소를 아우르는 철저한 심층 방어 접근 방식이 필요합니다.

엔드포인트 

개발자 워크스테이션은 저장소, 파이프라인, 클라우드 환경에 대한 직접적인 액세스 권한을 보유하고 있으므로 매우 중요한 표적입니다. 공격자는 종종 IDE를 표적으로 삼아 모니터링되지 않는 로컬 액세스를 악용하여 개인 액세스 토큰(PAT), SSH 키, 독점 코드를 수집합니다. 조직은 모든 로컬 호스트 머신과 클라우드 기반 개발 환경 전반에서 일관된 보안 상황을 적용하는 통합 보안 계층을 구축해야 합니다.

로컬 보안 비밀 스캔 

조직은 저장소 커밋 전에 보안 비밀을 감지하고 차단하기 위해 커밋 전 후크와 IDE 통합 스캔 도구를 배포해야 합니다. 커밋 전 로컬 템플릿을 표준화하면 변경사항이 중앙 서버로 푸시되기 전에 Git 트리를 완전히 인증할 수 있습니다. 잠재적인 데이터 유출이 미치는 영향을 최소화하기 위해 조직은 기존의 클래식 PAT에서 짧은 TTL(수명) 제한과 최소한의 환경별 권한에 의해 제한된 세분화된 PAT로 마이그레이션해야 합니다.

엔드포인트 보안 관리

조직은 개발자 소프트웨어 통합을 모니터링하고 지속적인 기기 보안 상황을 확인하기 위해 엔드포인트 감지 및 대응(EDR) 솔루션을 구성해야 합니다. EDR 에이전트는 신뢰할 수 있는 IDE 프로세스 트리를 모니터링하여 비정상적인 파일 액세스, 예기치 않은 프로세스 생성, 승인되지 않은 아웃바운드 네트워크 연결을 감지해야 합니다. 

완벽한 연동을 위해 이러한 EDR 규정 준수 신호를 통합 엔드포인트 관리(UEM) 시스템과 직접 통합해야 합니다. 이를 통해 기기가 규정을 준수하지 않는 경우 소스 코드 관리(SCM) 시스템에 액세스하거나, 파이프라인 작업을 실행하거나, 코드를 게시하는 사용자의 권한을 자동으로 제한하거나 취소해야 합니다. 필요한 명령줄 인터페이스(CLI) 프로세스 제외 항목은 기업 엔드포인트 전반에 광범위하게 적용하기보다는 지정되어 있는 격리된 개발자 환경으로 엄격하게 제한해야 합니다.

IDE 표준화

조직은 IDE, 브라우저 통합, 서드 파티 확장 프로그램의 특정 버전을 검증하고 승인해야 합니다. IDE 및 브라우저 마켓플레이스는 검증된 애플리케이션만 허용하도록 제한하여 인증되지 않은 확장 프로그램을 명시적으로 차단해야 합니다. 모든 통합은 허용 목록에 추가하기 전에 공식적인 서드 파티 위험 관리 검토를 거쳐야 합니다. 조직은 새롭게 발견된 위협을 차단하기 위해 엄격한 버전 고정 기능과 중앙 집중식 긴급 차단 기능과 결합된 활성 소프트웨어 애셋 인벤토리를 유지해야 합니다.

AI 지원 보안

엔지니어링팀은 병합 전 취약점 분석 및 애플리케이션 보안 테스트를 수행할 때 승인된 대규모 언어 모델(LLM)과 AI 에이전트만 활용해야 합니다. 공격자가 오픈소스 모델 컨텍스트 프로토콜(MCP) 패키지에 악성 코드를 적극적으로 삽입하고 AI 코딩 에이전트를 속이기 시작했기 때문에 이 경계는 매우 중요합니다(자세한 내용은 함께 제공되는 블로그 참조).

컨텍스트 포이즈닝 및 데이터 무단 반출과 같은 위험을 완화하기 위해 보안팀은 런타임 실행 전에 입력을 검증하는 컨텍스트 보호 도구를 배포해야 합니다. 개발자는 민감한 사용자 인증 정보가 모델의 컨텍스트 윈도우로 유입되는 것을 방지하기 위해 가능하면 플랫폼별 무시 구성을 사용하여 작업공간에서 로컬 환경(.env) 파일을 제외해야 합니다. 조직은 모든 AI 생성 코드가 저장소에 작성되기 전에 이를 인증하는 인간 참여형(Human In The Loop) 제어 모델을 유지해야 합니다.

격리된 개발자 샌드박스

호스트 수준의 보안 침해를 방지하기 위해 조직은 가능하면 컨테이너화된 개발 환경 또는 전용 가상 머신(VM)을 사용해야 합니다. 샌드박싱을 사용하면 설치 후 악성 스크립트나 종속 항목 포이즈닝 공격이 로컬 파일 시스템을 순회할 수 없게 됩니다.

보안 침해된 종속 항목이 호스트 권한으로 실행되는 것을 방지하기 위해 민감한 호스트 경로를 작업공간 컨테이너에 마운트하는 작업은 제한해야 합니다. 개발자 게스트 VM은 중앙에서 관리되는 강화된 골든 이미지에서 인스턴스화해야 하며, 네트워크는 실제 프로덕션 환경에서 격리해야 합니다. 모든 샌드박스 실행 및 네트워크 활동은 중앙 집중식 기업 로깅에 통합되어야 합니다.

코드 저장소  

소스 코드 저장소는 조직의 독점 소프트웨어와 지식 재산에 대한 확실한 정보 소스 역할을 합니다. 이 계층을 강화하려면 사용자 ID 제어, 엄격한 브랜치 거버넌스, 코드 기록의 지속적인 인증을 통해 승인되지 않은 변경사항이 수명 주기에 유입되지 않도록 해야 합니다.

범용 ID

저장소를 보호하려면 사용자 ID를 엄격하게 제어해야 합니다. 회사 관리 사용자(CMU) 모델을 구현하면 조직은 외부 공동작업자를 포함한 모든 계정에 대한 완전한 소유권을 유지할 수 있으며, FIDO2를 준수하는 실물 보안 키 또는 디지털 패스키와 같은 피싱을 방지하는 다중 인증(MFA)을 적용할 수 있습니다.

그러나 CMU 계정은 외부 오픈소스 저장소에 기여하는 데 제약이 있을 수 있습니다. 이러한 한계로 인해 공개 또는 오픈소스 게시 및 비공개 공동작업에 참여하는 팀에는 MFA가 적용된 싱글 사인온(SSO)이 통합된 일반 사용자 모델이 여전히 권장되는 접근 방식입니다.

선택한 계정 모델과 관계없이 본인 인증은 지속적으로 이루어져야 합니다. 조직은 액세스 권한을 부여하기 전에 조건부 액세스 정책을 배포하여 기기 보안 상황을 인증해야 하며, 사용자 API 활동을 모니터링하여 보안 침해된 세션을 신속하게 감지해야 합니다.

브랜치 보호

조직은 기본 브랜치로 직접 병합 금지(zero direct-to-main) 정책을 구현하여 모든 변경사항이 격리된 기능 브랜치에 반영되도록 해야 합니다. 이 과정에서 병합 전에 동료 검토를 거치고 자동화된 CI 검사를 통과해야 합니다. 관리자 권한을 이용한 우회 정책은 사용 중지해야 합니다. 파일 시스템 수준에서는 강제 푸시 활동을 제한하고 모니터링해야 합니다. 보안팀은 타임라인 조작을 식별하고 코드 무단 반출에 사용되는 승인되지 않은 데드 드롭 저장소를 감지하기 위해 감사 기록을 지속적으로 분석하여 시간순 불일치를 파악해야 합니다.

사용자 인증 정보 수명 주기

장기적인 지속성을 방지하기 위해 조직은 사용자 인증 정보 순환을 자동화하고, 적시(Just-in-Time) 검색 메커니즘을 구현하고, 엄격한 토큰 TTL을 설정해야 합니다. 개발자 액세스의 경우, 조직은 로컬 인포스틸러 멀웨어에 취약한 정적인 호스트 저장 비밀번호와 다름없는 PAT를 지원 중단하고 하드웨어 보안 키(예: FIDO2/YubiKey 또는 macOS Secure Enclave)에 기반한 암호화 방식으로 인증된 SSH 기반 인증으로 전환해야 합니다.

자동화된 CI/CD 파이프라인 및 서드 파티 통합의 경우, 조직은 서비스 계정 PAT 대신 GitHub Apps 사용을 의무화하여 1시간 후 자동으로 만료되는 수명이 짧고 범위가 지정된 액세스 토큰을 활용해야 합니다. 보안 비밀은 환경 변수에 저장해서는 안 됩니다. 로컬 환경 파일(.env)은 .gitignore를 통해 제외해야 하고 런타임 삽입을 위해 네이티브 플랫폼 보안 비밀 기능을 활용해야 합니다.

종속 항목 보안

시맨틱 버전 관리(SemVer)를 활용하는 애플리케이션 매니페스트의 경우, 조직은 해결 과정에서 종속 항목 드리프트를 유발하는 동적 버전 범위(예: 캐럿 ^, 물결표 ~, 와일드 카드 * 연산자)를 금지해야 합니다. 대신 엄격하게 적용되고 암호화 방식으로 인증된 잠금 파일에서 지원하는 정확한 SemVer 고정(예: 1.4.2)을 구성에서 의무화해야 합니다.

맹목적인 'curl to bash' 스크립트와 같이 인증되지 않은 실행 벡터는 차단하고 명시적인 SHA-256 다이제스트를 통해 호출되는 공급업체 컨테이너를 사용해야 합니다. 조직은 애플리케이션 경로 내에서 실제로 실행되는 취약점에 대한 패치를 우선 적용하기 위해 연결 가능성 분석과 결합된 소프트웨어 구성 분석(SCA)을 구현해야 합니다. 빌드 과정에서는 소프트웨어 자재명세서(SBOM)를 생성하고 소프트웨어 아티팩트에 대한 공급망 등급(SLSA) 레벨 2 이상의 출처 기록 검사를 시행해야 합니다.

아티팩트 관리 

아티팩트 계층을 방어하려면 신뢰할 수 있는 빌드 환경의 경계를 넘어 유입되는 요소를 제어해야 합니다. 특정 시점 스캔만으로는 더 이상 충분하지 않습니다. 조직은 업스트림 구성요소가 다운스트림으로 전파되기 전에 지속적으로 검사하고 인증해야 합니다.

종속 항목 대기 시간

조직은 새로 게시된 공개 패키지 버전이 설치 가능해지기 전에 최소 7일의 출시 대기 시간을 의무화해야 합니다. 커뮤니티 감지는 악성 오픈소스 패키지가 게시된 직후에 이를 식별하고 삭제하는 경우가 많습니다.

엄격한 7일의 버퍼 기간을 설정하면 오픈소스 생태계가 오염된 출시 버전이 내부 빌드에 도달하기 전에 이를 감지하고 가져올 수 있는 시간을 확보할 수 있습니다. 이 지연 시간은 중앙 집중식 레지스트리 또는 로컬 구성에서 적용해야 합니다. 특정 구성 파라미터(예: npm의 minimumReleaseAge 대기 시간 구성 또는 안전한 Python pip 색인 생성)에 대한 상세한 기술 구현 단계는 함께 제공되는 블로그를 참조하세요.

프록시 및 격리

모든 외부 패키지와 컨테이너 이미지는 가능하면 각 구성요소를 캐시, 검사, 제어하는 중앙 집중식 내부 프록시를 통해 라우팅해야 합니다. 조직은 비공개 저장소를 호스팅하고, 가상 업스트림 저장소를 구성하고, 빌드 실행자가 공개 레지스트리에 직접 액세스하는 것을 제한하기 위해  Google Artifact Registry를 사용하여 이 보안 경계를 관리할 수 있습니다. 프록시를 통해 도달하는 새로운 구성요소는 격리 상태로 유지하고 검사해야 하며, 보안 확인 결과에서 실패한 것으로 나타나면 빌드를 자동으로 차단해야 합니다. 내부 저장소는 종속 항목 혼란 공격을 방지하기 위해 공개 레지스트리와 구분되어야 하며, 신뢰할 수 있는 레지스트리로 승격 시 정책에 기반한 신중한 승인 경로를 따라야 합니다.

취약점 스캔

컨테이너 이미지와 서드 파티 종속 항목은 레지스트리 계층 및 런타임 환경에서 자동 스캔을 거쳐야 합니다. 새로운 취약점이 발견되면 저장된 아티팩트를 지속적으로 재평가해야 합니다. 알림 수를 관리하려면 연결 가능성 분석과 실제 취약점 공격 신호(예: CISA의 알려진 취약점 공격(KEV) 카탈로그)를 사용하여 결과의 우선순위를 지정해야 합니다. VEX(Vulnerability Exploitability eXchange) 문을 사용하여 적용할 수 없는 발견 사항을 억제하고 노이즈를 줄여야 합니다.

이미지 출처 기록

아티팩트가 신뢰할 수 있는 소스에서 제공되었는지 확인하는 것은 알려진 취약점이 없는지 확인하는 것만큼이나 중요합니다. 출처 기록은 내부적으로 생성된 모든 컨테이너 이미지와 패키지에 암호화 방식으로 서명한 다음, 이를 특정 빌드 워크플로 및 소스 커밋에 바인딩하여 이러한 신뢰를 구축합니다. 최신 서명 도구를 사용하면 수명이 긴 서명 키를 관리해야 하는 부담 없이 각 서명 이벤트를 빌드 ID에 연결하고 공개 투명성 로그에 기록하여 이를 실용적으로 구현할 수 있습니다. 서명은 검사 시에만 의미가 있으므로 인증은 허용 시 시행해야 하고, 예상되는 정확한 빌드 ID로 제한해야 하며, 변경 가능한 태그가 아닌 아티팩트의 변경 불가능한 다이제스트에 대해 수행해야 합니다.

아티팩트를 게시하는 사용자 인증 정보에도 동일한 원칙이 적용됩니다. 레지스트리에 게시된 수명이 긴 토큰은 공급망 문제의 반복적인 근본 원인입니다. 도용된 토큰을 통해 공격자가 신뢰할 수 있는 이름으로 오염된 버전을 게시할 수 있기 때문입니다. 가능한 경우 이러한 정적 토큰은 출시 시점에 특정 빌드 워크플로에 발급되는 수명이 짧고 ID에 바인드된 게시 토큰으로 대체해야 합니다. 퍼스트 파티 빌드의 경우, 인정된 출처 기록 표준을 채택하면 소프트웨어가 빌드된 방식과 위치에 대한 일관된 기준을 마련할 수 있습니다.

SHA 참조

컨테이너 이미지 태그와 작업 참조는 기본적으로 변경 가능합니다. 즉, 업스트림 행위자가 언제든지 신뢰할 수 있는 이름 뒤에 있는 콘텐츠를 몰래 바꿀 수 있습니다. 하지만 변경할 수 없는 암호화 다이제스트에 고정하면 이러한 취약점을 해결할 수 있습니다. 다이제스트는 콘텐츠 해시이므로 기본 아티팩트가 변경되면 다른 식별자가 생성되어 참조가 손상됩니다. 따라서 파이프라인이 이미 신뢰하는 이름으로 악성 콘텐츠를 대체하는 상황을 방지할 수 있습니다.

이미지는 다이제스트별로 고정해야 하며, 서드 파티 작업은 재지정할 수 있는 버전이 아닌 전체 커밋 해시에 고정해야 합니다. 이러한 원칙은 기본 애플리케이션 이미지뿐만 아니라 빌드 과정에서 다루는 모든 이미지에 적용되어야 합니다. 기본 이미지, 사이드카, 초기화 컨테이너도 변경 가능한 태그로 그대로 남겨둘 경우 동일하게 실행 가능한 주입 지점이 될 수 있기 때문입니다. 또한 프로덕션 환경에서 다시 시작할 때마다 변경 가능한 태그를 다시 확인하는 구성을 피해야 합니다.

지속적 통합/지속적 배포(CI/CD)

CI/CD 인프라 내에서 자동화된 파이프라인을 강화하는 것은 더 광범위한 소프트웨어 개발 수명 주기를 보호하기 위한 중요한 요구사항입니다. 이러한 환경은 소스 저장소, 서드 파티 레지스트리, 클라우드 인프라에 액세스하기 위해 권한이 있는 광범위한 통합 네트워크에 의존하기 때문에 공격자에게 매우 중요한 표적이 됩니다. 이러한 빌드 및 배포 시스템을 보호하려면 최소 권한 원칙을 엄격하게 적용하고, 엄격한 네트워크 경계를 시행하며, 신뢰할 수 있는 모든 소프트웨어 구성요소를 지속적으로 인증해야 합니다.

실행자 및 빌드 서버

CI/CD 인프라를 강화하는 것은 중요한 작업입니다. 이러한 파이프라인은 코드 저장소, 종속 항목 레지스트리, 클라우드 환경에 대한 액세스 권한을 필요로 하기 때문입니다. 이러한 통합을 보호하기 위한 주요 방어 목표는 실행자 지속성을 제거하는 것입니다. 조직은 일회용 임시 실행자를 사용하여 모든 작업이 완료 시 자동으로 삭제되는 새로운 격리된 환경에서 실행되도록 해야 합니다. 이러한 초기화 접근 방식은 작업 간 오염을 방지하고 공격자가 영구적인 발판을 마련하지 못하도록 합니다. 자체 호스팅 환경의 경우, 이러한 격리는 네트워크 계층까지 확장되어야 하며, 데이터 무단 반출을 방지하기 위해 아웃바운드 실행자 트래픽을 사전 승인된 레지스트리 및 저장소 API로만 제한해야 합니다. 또한 오염된 파이프라인 실행(PPE)을 완화하기 위해 실행 엔진은 관리자가 수동으로 승인할 때까지 pull 요청에서 검증되지 않은 코드가 보안 비밀에 액세스하거나 배포 등급 실행자를 트리거하지 못하도록 차단해야 합니다.

또한 파이프라인은 공유 빌드 캐시가 조작되지 않도록 보호해야 합니다. 빌드 속도를 높이기 위해 빌드 캐시가 브랜치 간에 공유되는 경우가 많으므로 악성 pull 요청이 손상된 종속 항목을 공유 캐시에 직접 삽입할 수 있습니다. 제한 없이 남겨둘 경우 후속 프로덕션 빌드가 이 오염된 캐시를 검색하고 신뢰할 수 있는 환경에서 악성 코드를 실행합니다. 파이프라인 설정은 브랜치 권한에 따라 캐시 액세스를 엄격하게 격리하고 인증되지 않은 포크의 캐시 쓰기를 거부해야 합니다.

최소 권한 CI/CD

• 제휴 임시 ID: 워크플로 내에서 영구 자동화 보안 비밀을 금지하여 OIDC를 활용해 파이프라인 ID를 수명이 짧은 토큰으로 교환합니다.

• 제로 트러스트 실행 범위: 기본적으로 읽기 전용 또는 null 권한의 실행자 ID를 발급하여 구성요소가 최소한의 실행 가능한 권한을 명시적으로 요청하도록 합니다.

• 공유 상태 파라미터화: 다운스트림 템플릿 또는 중첩된 워크플로에서 사용자 인증 정보의 자동 상속을 금지하여 민감한 변수를 격리합니다.

• 런타임 거버넌스: 미허가 서드 파티 플러그인 및 마켓플레이스 작업을 제한합니다. 또한 보안팀은 패키지 설치 수명 주기 스크립트를 샌드박스 처리하거나 사용 중지하여(함께 제공되는 블로그에 자세히 설명된 ignore-scripts=true와 같은 구성 사용) 보안이 침해된 종속 항목이 빌드 환경에서 임의의 명령어를 실행하지 못하도록 해야 합니다.

• 환경 격리: 초기 단계 검증 또는 린트 작업이 출시 권한을 가진 시스템과 완전히 분리되어 작동하도록 네트워크 및 IAM 경계를 세분화합니다.

• 변경 불가능한 브랜치 기록: 표준 브랜치에서 기록 재작성 기능과 강제 푸시를 사용 중지하여 추가 전용 감사 추적을 유지합니다.

• IaC 검증: 배포 전에 코드형 인프라(IaC)를 스캔하여 과도한 권한이 있는 키, 따옴표가 없는 사용자 파라미터 삽입, 암호화되지 않은 웹훅, 실행자 RBAC 구성 오류를 차단합니다.

스캔 게이트 및 증명

CI/CD 스캔 게이트는 배포 프로세스 내에서 자동화된 품질 관리 역할을 수행하며, 설정된 보안 표준에 따라 코드를 평가하고 정의된 기준을 충족하지 않을 경우 배포를 자동으로 중단합니다. 프로세스 초기에 스캔 게이트를 배치하면 개발자가 프로덕션 환경에 도달하기 전에 잠재적인 취약점을 파악할 수 있습니다.

보안 비밀 스캔(개발자 커밋/PR 게이트): 커밋 전 후크 및 SCM 수준 스캐너를 구성하여 하드코딩된 API 키, 비밀번호 또는 SSH 키가 포함된 경우 개발자 푸시를 차단합니다. 이렇게 하면 보안 비밀이 저장소의 영구 기록에 입력되지 않습니다.

SAST - 정적 애플리케이션 보안 테스트(풀 요청/동료 검토 게이트): SAST를 지속적 통합(CI) 테스트에 통합하여 초안 코드를 main 브랜치에 병합하기 전에 분석합니다. 이를 통해 활발한 개발 과정에서 구조적 결함, 논리적 취약점, 위험한 함수(예: 이스케이프 처리되지 않은 사용자 입력)를 자동으로 신고합니다.

SCA - 소프트웨어 구성 분석(빌드 단계): 빌드 환경에서 종속 항목을 해결할 때 SCA 스캔을 트리거합니다. 패키지 잠금 파일(예: package-lock.json 또는 requirements.txt)을 Google OSV와 같은 데이터베이스와 비교하여 스캔하면 활성 상태의 알려진 CVE가 있는 라이브러리를 가져오려고 시도하는 빌드를 자동으로 실패 처리할 수 있습니다.

컨테이너/이미지 스캔(레지스트리/푸시 게이트): 자동화된 스캐너를 컨테이너 레지스트리 파이프라인에 직접 빌드합니다. 새로 빌드된 컨테이너 이미지가 프로덕션용으로 허용 목록에 추가되기 전에 레지스트리 스캐너는 기본 OS 패키지를 검사하고 중요한 OS 수준 취약점 또는 기본 루트 액세스가 포함된 이미지를 거부해야 합니다.

DAST - 동적 애플리케이션 보안 테스트(스테이징/배포 전): 배포 단계의 일환으로 실행 중인 애플리케이션의 임시 격리된 스테이징 인스턴스를 만듭니다. 자동화된 DAST 테스트를 실행하여 엔드포인트에 대한 실제 공격(예: SQL 삽입 또는 교차 사이트 스크립팅)을 시뮬레이션하고 활성 런타임 방어 구성이 작동하는지 검증합니다.

CSPM - 클라우드 보안 상황 관리(배포 전 IaC 스캔 및 배포 후): 코드형 정책(PaC) 도구를 사용하여 변경사항을 적용하기 전에 코드형 인프라(IaC) 템플릿(예: Terraform 또는 Kubernetes 매니페스트)을 스캔합니다. 이를 통해 과도한 권한이 있는 IAM 역할이나 인터넷에 SSH(포트 22)가 개방된 보안 그룹과 같이 잘못 구성된 클라우드 환경의 프로비저닝을 자동으로 차단합니다.

SBOM 생성 및 증명

SBOM은 빌드에 포함된 모든 구성요소의 완전하고 인증 가능한 인벤토리입니다. 빌드의 일부로 SBOM을 생성하고 서명하면 이 인벤토리가 나중에 재구성되는 것이 아니라 조작 방지 증명 형태로 생성됩니다.

실제로 이는 CycloneDX 또는 SPDX와 같은 인정된 형식으로 빌드 단계에서 SBOM을 생성하는 것을 의미합니다. 이렇게 생성되는 SBOM에는 아티팩트의 다이제스트에 연결된 증명으로 서명하여 수정하지 못하도록 해야 합니다. 서명된 SBOM은 Fleet의 모든 이미지를 다시 스캔하지 않고도 영향을 받는 아티팩트에 다시 매핑되어야 합니다. 모니터링의 유효성을 유지하려면 VEX 문을 사용해 코드에 적용되지 않는 발견 사항을 표시하여 인벤토리가 실행 가능한 분류 도구로 기능하도록 해야 합니다.

배포

런타임 단계를 보호하면 공격자가 초기 파이프라인 방어를 우회하더라도 워크로드를 계속 보호할 수 있습니다. 이 운영 계층은 코드가 빌드 파이프라인에서 활성 프로덕션으로 전환될 때 최종 품질 게이트 역할을 합니다.

워크로드 보호 및 런타임 강화

실행 중인 애플리케이션과 컨테이너 인스턴스에 직접 워크로드 보호를 적용하여 실행 공간을 제한하고 활성 익스플로잇을 차단해야 합니다.

• 배포 가드레일: 프로덕션 환경 진입점에 자동화된 보안 검사를 설정하여 유효한 암호화 서명이 없거나, 불필요한 루트 권한을 요청하거나, 신뢰할 수 없는 공개 레지스트리에서 시작된 컨테이너를 차단합니다.

• 워크로드 보안 상황: 강화된 기본 이미지에서 워크로드를 빌드하고 읽기 전용 루트 파일 시스템은 있지만 SSH 기능이 삭제된 변경 불가능한 인프라에서 실행하여 익스플로잇 후 파일 생성 또는 측면 디렉터리 순회를 방지합니다.

• 능동적 애플리케이션 보호: 런타임 애플리케이션 자가 보호(RASP)를 배포하여 SQL 삽입과 같은 실행 수준의 취약점 공격 시도를 차단합니다. Google Model Armor와 같은 런타임 가드레일을 사용하여 프롬프트 삽입 및 탈옥으로부터 AI 워크로드를 보호합니다.

• 적시(Just-in-Time) 액세스: 상시 관리 권한을 없애고 시간 제한이 있고 작업 범위가 지정된 액세스 사용자 인증 정보를 사용합니다. 이는 자동으로 만료되며, 필요한 경우에만 런타임에 권한 있는 사용자 인증 정보를 삽입합니다.

실제 인프라 보호

주변 네트워크와 클라우드 컨트롤 플레인을 보호하면 배포된 애플리케이션을 외부 위협으로부터 보호하고, 측면 이동을 차단하며, 클라우드 구성의 절대적인 무결성을 유지할 수 있습니다.

• 웹 애플리케이션 방화벽(WAF): 에지 방화벽을 배포하여 유입되는 애플리케이션 계층 트래픽을 검사합니다. 이를 통해 악성 페이로드를 필터링하고, 교차 사이트 스크립팅 또는 OWASP Top 10개 취약점과 같은 일반적인 웹 익스플로잇이 백엔드 서비스에 도달하기 전에 차단합니다.

• API 게이트웨이 및 부하 분산기: 에지 인증을 중앙 집중화하고, 속도 제한을 적용하고, 요청 서명을 검증하여 애플리케이션 백엔드가 외부에 직접 노출되는 것을 방지합니다.

• 마이크로세그멘테이션: 세분화된 ID 인식 네트워크 정책을 적용하여 워크로드를 격리하고 사전 승인된 서비스 간 통신 경로로만 트래픽을 제한하여 기본적으로 측면 네트워크 이동을 차단합니다.

• 구성 무결성: 코드형 정책(PaC) 도구를 배포하여 버전 제어되는 IaC 정보 소스를 기준으로 실제 환경을 지속적으로 검증하고, 대역 외 수정을 자동으로 되돌려 무단 변경을 방지합니다.

• 능동적 보안 상황 스캔: 클라우드 보안 상황 관리(CSPM) 및 클라우드 네이티브 애플리케이션 보호 플랫폼(CNAPP)을 실행하여 클라우드 구성 오류, 과도한 권한이 있는 IAM, 노출된 스토리지를 지속적으로 스캔합니다.

• 지속적 모니터링: 로그, 시스템 측정항목, 감사 이벤트를 수집하여 모든 시스템에 대한 완전한 가시성을 유지하고 실시간 보안 이벤트를 신속하게 감지, 추적, 대응합니다.

결론 

최근 소프트웨어 공급망 침입 공격 사례는 개발 인프라, 빌드 파이프라인, 개발자 유틸리티가 중요한 위협 벡터이자 주요 보안 침해 지점임을 보여줍니다. 기존의 액세스 제어와 특정 시점 보안 스캔으로는 정교한 침입 공격으로부터 이러한 환경을 방어하기에 충분하지 않습니다. 개발 수명 주기를 강화하려면 모든 단계에서 지속적이고 자동화된 검증을 구현하고 개발자 엔드포인트, 코드 저장소, 패키지 레지스트리, 빌드 실행자, 배포 가드레일 전반의 보안 상황을 일관된 방어 프레임워크로 통합해야 합니다.

궁극적으로 파이프라인 보안의 목표는 침입 공격을 격리하고 차단할 수 있는 복원력 있는 아키텍처를 빌드하는 것입니다. 초기 코드 커밋부터 최종 프로덕션 배포에 이르기까지 암호화 검증 및 정책 시행을 자동화하면 전반적인 공격 표면을 크게 줄이고, 다운스트림 소비자를 보호하며, 개별 보안 침해가 확산되기 전에 신속하게 격리하고 해결할 수 있습니다.

감사의 말씀

이 지침은 Arafat Ismail, Bhavesh Dhake, Brentyn Muir, Brian Meyer, Emilio Oropeza, Eyad Mahmoud, Franklin Ramos, Gursev Singh, Omar ElAhdan, Sara Takhim, Stuart Carrera, Stuart Munro, Will Silverstone, 그리고 Mandiant Security Transformation Services팀의 지원이 없었다면 불가능했을 것입니다.