CI/CD 파이프라인 내부에서 발생하는 세부 사항은 매우 불투명합니다. 지침의 파이프라인 목록인 YAML 구성 파일을 작성했음에도 불구하고 모든 일이 설명된 대로 정확히 발생하는지 어떻게 확신할 수 있습니까? 더 나쁜 것은 대부분의 파이프라인이 완전히 일시적이기 때문에 오작동이 발생하더라도 문제의 세부 사항을 포함하거나 포함하지 않을 수 있는 기록된 것 외에는 증거가 거의 없다는 것입니다.
자동화된 CI/CD(지속적 통합/지속적 전달) 파이프라인을 사용하여 신속한 개발이 달성됩니다. 코드를 자동으로 컴파일, 빌드, 테스트 및 제공하는 트리거나 스케줄링을 갖는 것은 환상적입니다. 그러나 대부분의 파이프라인은 보안을 염두에 두고 구축되지 않았으며 속도와 사용 편의성을 위해 설계되었습니다. 파이프라인은 일반적으로 종속성 및 파일을 다운로드하기 위해 인터넷 액세스가 필요하므로 파이프라인이 손상되면 공격자는 작업을 방해하거나 정보 또는 비밀을 유출할 수 있는 다양한 옵션을 갖게 됩니다.
이 문서에서는 CI/CD 파이프라인을 보호하기 위해 적용할 수 있는 몇 가지 모범 사례를 다루겠습니다. 우리의 목적을 위해 어떤 자동화 도구나 시스템을 사용하고 있는지는 중요하지 않습니다. 보안 원칙은 여전히 유효합니다. 파이프라인의 해당 섹션을 보호하는 작업에 적합한 도구를 찾으면 됩니다.
CI/CD(지속적 통합/지속적 전달) 파이프라인이란 무엇입니까?
CI/CD 파이프라인은 소프트웨어, 애플리케이션 또는 아티팩트를 구축, 테스트 및 게시하기 위한 자동화된 프로세스입니다. 이러한 파이프라인은 점점 더 일반화되고 복잡해지고 있습니다. 파이프라인은 팀 생산성을 높이고 소프트웨어 아티팩트를 보다 일관되고 예측 가능하게 생성하기 위한 탁월한 도구입니다. 대기업에는 수백 개의 상호 연결되고 조직화된 파이프라인이 있을 수 있으며, 이 파이프라인은 모두 서로 의존하여 제대로 작동한다는 점을 고려할 때 이러한 절차 자동화의 중요성이 훨씬 더 분명해집니다.
코드 변경 사항을 새로운 최종 제품으로 자동으로 정기적으로 구축하고 테스트하는 것을 지속적인 통합(CI)이라고 합니다. 코딩 변경 사항은 지속적인 전달 및/또는 배포(CD)라는 2단계 프로세스의 일부로 전달, 테스트 및 통합됩니다. 지속적인 배포는 자동으로 프로덕션 환경에 업데이트를 제공하는 반면, 자동 프로덕션 배포 직전에 지속적인 업데이트를 중지합니다. 파이프라인이 둘 중 하나를 사용하는지 여부는 전적으로 귀하와 환경 및 결과물이 설정되는 방식에 달려 있습니다.
소프트웨어 공급망에 대한 CI/CD 보안의 중요성
대부분의 기업이 의존하는 CI/CD 도구 파이프라인 자동화를 위한 것입니다. 즉, 다른 많은 사람들과 마찬가지로 소프트웨어 공급망 공격, 나쁜 행위자에게 필요한 모든 것은 단일 목표를 침해하여 광범위한 폭발 반경을 얻는 것입니다. 주요 약점 중 하나는 파이프라인이 종속성을 다운로드하여 최종 제품이나 아티팩트에 통합해야 한다는 것입니다. 하나의 잘못된 종속성이라도 원치 않는 요소에 파이프라인의 발판을 제공하기에 충분합니다. 파이프라인은 필요에 따라 인프라의 소스 코드 및 기타 다양한 요소에 액세스할 수 있으므로 권한 에스컬레이션을 통해 특정 파이프라인에서 생성된 제품의 거의 모든 부분에 액세스하고 나중에 변경하거나 유출할 수 있습니다.
간단한 예는 다음 설명에서 찾을 수 있습니다. 캐시 또는 종속성 중독.
지난 몇 년 동안 여러 대기업이 CI/CD 파이프라인을 발신지로 삼는 소프트웨어 공급망 공격으로 어려움을 겪었습니다. 예를 들어 다음을 볼 수 있습니다. CircleCI 침해 2023년 XNUMX월, Argo CD의 타협 2022년 XNUMX월, 그리고 코드코브 침해 4 월 2021.
이러한 공격의 잠재적인 결과는 심각하므로 파이프라인을 최대한 안전하게 보호하기 위해 할 수 있는 모든 조치를 취하는 것이 좋습니다.
CI/CD 보안 모범 사례
어떤 CI/CD 플랫폼이나 도구를 사용하든, 보안을 강화하고 적대적인 행위자가 파이프라인이나 네트워크에 액세스하는 경우 발생할 수 있는 잠재적 피해를 줄이기 위해 수행할 수 있는 몇 가지 작업이 있습니다.
모니터링 및 경고 – 피싱 및 기타 사회 공학 사기에 주의하도록 엔지니어를 교육한 경우에도 위반이 발생할 수 있습니다. 대부분의 파이프라인 환경은 일시적이므로 작업이 완료되면 적극적으로 기록하지 않는 한 많은 흔적이 남지 않습니다. 각 PR, 병합, 빌드 및 테스트 작업을 수행할 때 환경 또는 구성 파일에 대한 모든 수정 사항이 기록되는지 확인하세요. 문제가 발생할 경우 조사를 위해 사용자 데이터도 다른 모든 데이터와 함께 기록되어야 합니다. 침해를 재구성하고 무엇이 잘못되었는지, 어떻게 잘못되었는지 판단할 수 있는 것이 여기서의 목표입니다. 경고를 발생시켜야 하는 이벤트를 미리 선택하고 해당 당사자에게 알리십시오. 무의미하거나 지나치게 민감한 경고로 개인을 압도하지 않도록 주의하십시오. 이는 경고 피로로 이어질 수 있으며, 이는 단순히 경고를 무시하거나 신중한 것보다 훨씬 늦게 반응하게 만들 수 있습니다.
최소 권한과 결합된 RBAC 원칙 사용 – 조직 내에서 사용자에게 지정된 역할이나 직무를 기반으로 시스템 리소스에 대한 액세스를 제공하는 것이 역할 기반 액세스 제어(RBAC)의 기초입니다. 사용자에게는 파일, 폴더, 프로그램과 같은 다양한 시스템 리소스에 대한 액세스 권한과 사용 권한을 지정하는 RBAC 역할이 부여됩니다. 반면, 최소 권한 개념은 사용자에게 업무를 수행하는 데 필요한 최소한의 액세스 및 권한을 부여하는 방식을 의미합니다. 이는 사용자가 할당된 작업을 완료하는 데 필요한 리소스만 사용할 수 있다는 것을 의미합니다. 최소 권한과 RBAC는 보완적인 보안 개념으로 함께 적용되는 경우가 많습니다. 최소 권한 원칙은 사용자가 특정 업무를 수행하는 데 필요한 최소한의 리소스에만 액세스할 수 있도록 하며, RBAC는 사용자에게 업무 기능을 수행하는 데 필요한 리소스에 대한 적절한 액세스 권한만 제공하는 역할을 할당합니다. . 이러한 지침을 결합하면 잘 관리되고 상대적으로 안전한 시스템을 유지하는 데 도움이 됩니다. 추가 보안 계층으로 필수 시스템 작업에 대해 여러 사용자 인증을 요구하도록 구성할 수 있습니다. 이 전략은 개발 프로세스가 눈에 띄게 지연될 수 있으므로 신중하게 사용해야 합니다.
파이프라인 출처를 불변 로그로 유지 – 무언가가 언제, 어디서, 어떻게 생성되었는지 설명하는 소프트웨어 가공물에 대한 검증 가능한 정보를 출처라고 합니다. 입력된 파일과 파이프라인에서 해당 파일에 어떤 일이 발생했는지 정확하게 아는 것은 해당 파이프라인의 위조할 수 없는 로그를 형성하는 출처 파일로 생성될 수 있습니다. 보안을 유지하려면 사용자가 중단하거나 수정할 수 있는 모든 항목을 완전히 신뢰할 수는 없으므로 출처는 사용자와 독립적으로 생성되어야 합니다. 서기의 발린트 ~ 할 수있게 해준다. 출처를 밝히다 다양한 SCM 시스템을 위한 파이프라인에 포함됩니다. 각 출처 파일(JSON)은 나중에 액세스할 수 있으므로 이를 검토하여 예상치 못한 일이나 바람직하지 않은 일이 발생했는지 확인할 수 있습니다. 그런데 파이프라인 전체에서 출처 파일을 생성하고 관리하는 것이 핵심입니다. SLSA 프레임워크.
SBOM을 최대한 활용하세요 – 잠재적인 용도 중 몇 가지를 놓친 경우를 대비해 파이프라인 마지막에 만들어진 SBOM은 사용된 모든 오픈 소스 패키지를 나열하는 데 도움이 될 수 있습니다. 해당 목록을 알려진 CVE와 비교하면 최종 제품에 어떤 잠재적인 취약점이 있는지 알 수 있습니다. 또한 목록을 사용하여 여전히 오래된 버전의 오픈 소스 패키지를 사용하고 있는지 확인하고 다음과 같은 것을 사용할 수도 있습니다. OpenSSF 스코어카드 사용중인 패키지의 '상태'를 확인하십시오. 새로운 CVE가 지속적으로 밝혀지기 때문에 일회성 SAST와 달리 기존 패키지 중 하나에서 새 CVE가 발견되었는지 알려주는 서비스가 있어야 합니다. Scribe의 서비스를 사용하면 이 모든 작업을 자동으로 수행할 수 있습니다.
정책 준수 확인 – 각 회사, 때로는 각 파이프라인에는 모든 것이 제대로 작동하는지 확인하기 위해 수행해야 하는 정책이 있습니다. 일부 정책은 일반적이며(예: 2인 확인 프로세스가 있는지 확인) 다른 정책은 고유합니다(예: 프로덕션에 출시하기 전에 Mike가 최신 변경 사항에 대해 승인했는지 확인). 암호화 서명 확인 메커니즘과 고유한 정책 파일을 활용하면 이제 각 파이프라인에 필요한 정책을 포함하고 해당 정책이 발생했는지 확인할 수 있습니다(자신과 다른 사람에게). 스트레스를 받으면 일부 요구 사항을 건너뛰고 일부 규칙이 기한을 맞추려고 구부러지는 것은 인간의 약점입니다. 이 조치를 취하면 사람들은 더 이상 규칙을 어길 수 없으며 이는 내부 및 외부 위협으로부터 파이프라인의 보안을 유지하는 데 도움이 됩니다. Scribe는 이러한 정책을 시행하고 사용자가 직접 작성할 수 있는 새로운 방법을 개발했습니다. 확인 해봐 LINK.
파이프라인의 지침 파일을 보호하세요 – 위협 행위자는 PPE(Poisoned Pipeline Execution)라는 기술을 사용하여 CI 파이프라인을 "중독"시킬 수 있습니다. PPE(Poisoned Pipeline Execution)는 파이프라인 명령 파일에 원래 지정된 대로 파이프라인 단계나 시퀀스를 근본적으로 수정합니다. 이 방법은 소스 코드 관리(SCM) 저장소의 권한을 남용하여 빌드 프로세스를 조작합니다. 빌드 파이프라인 설정에 악성 코드나 명령을 삽입하면 파이프라인이 감염되어 빌드가 완료되는 동안 악성 코드가 실행될 수 있습니다. 파이프라인 지침 파일을 확인하기 전까지는 빌드가 의도한 대로 작동하지 않는다는 것을 알 수 없습니다. 파이프라인이 의도한 대로 실행되고 있는지 확인하려면 각 실행 전에 지침 파일을 확인해야 합니다. 암호화 방식으로 파일에 서명하고 파이프라인의 첫 번째 단계로 서명 확인을 추가하는 것은 해당 보안을 달성하는 한 가지 방법입니다. 서기의 발린트 서명하고 확인하다 함수는 새 파이프라인 실행을 시작하기 전에 지침 파일이 변경되지 않은 상태로 유지되었는지 확인하는 한 가지 방법입니다.
최종 결과를 확보하세요 – 최종 제품을 사기성 버전으로 교체하는 것이 훨씬 쉬운데 공격자가 파이프라인을 방해하기 위해 열심히 노력해야 하는 이유는 무엇입니까? 이러한 유형의 공격에서는 생성 회사가 이미지의 소스로 나타나므로 해당 회사가 이를 보호하는 유효한 인증서를 보유하는 것만으로는 충분하지 않습니다. 간단히 말하면 가짜의 신뢰성이 높아진다는 것입니다. 해결책은 파이프라인에서 생성된 최종 아티팩트가 무엇이든 암호화 방식으로 서명하고 최종 사용자가 해당 서명을 확인할 수 있도록 하는 것입니다. Scribe의 Valint는 다음과 같은 용도로 사용할 수 있습니다. 서명하고 확인하다 다양한 아티팩트를 통해 사용자가 얻고자 하는 것을 정확히 얻을 수 있도록 추가 보안을 제공합니다.
미래를 내다 보며
작업 속도를 높이기 위해 CI/CD와 같은 자동화 기술 사용을 중단하는 사람은 아무도 없습니다. 그와는 반대로, 우리가 살고 있는 세상에서 우리는 항상 더 빠른 소프트웨어 업데이트 반복을 추진하고 있습니다. 우리는 최소한 생산 환경이나 프로세스의 소스 코드를 위험에 빠뜨리지 않도록 조심하면서 작업에 접근해야 합니다.
중요한 것은 누군가가 귀하의 파이프라인, 환경 또는 소스 코드에 불법적으로 액세스할 경우 발생할 수 있는 결과를 고려하는 것입니다. 누출이 얼마나 위험할 수 있는지, 그리고 파이프라인과 네트워크가 가장 취약한 곳이 어디인지 알게 되면 잠재적인 누출을 막거나 완화하기 위해 적절한 조치를 취할 수 있을 것이라고 확신합니다.
상호 연결된 파이프라인은 점점 더 복잡해지기 때문에 파이프라인을 보호하기 위한 첫 번째 단계로 전체 환경 보안(분할된 네트워크, RBAC, 제로 트러스트 등)을 유지하는 것이 중요합니다. 그런 다음, 확실하고 위조할 수 없는 증거를 만들고 암호화 서명 및 데이터 확인을 사용하여 파이프라인이나 파이프라인의 캐시를 손상시킬 수 있는 소프트웨어 공급망 공격의 가능성을 최대한 완화하려고 노력하십시오. 경계심을 갖고 의심을 가지면 회사에서 말할 수 없는 골칫거리를 줄일 수 있습니다.
이 콘텐츠는 소프트웨어 공급망 전반에 걸쳐 코드 아티팩트와 코드 개발 및 전달 프로세스에 최첨단 보안을 제공하는 선도적인 엔드투엔드 소프트웨어 공급망 보안 솔루션 제공업체인 Scribe Security에서 제공합니다. 자세히 알아보기.
관련 게시물
