CI/CD 파이프라인은 내부에서 정확히 무슨 일이 일어나는지 알 수 없을 정도로 불투명합니다. 당신이 YAML 구성 파일(명령의 파이프라인 목록)을 작성한 사람이라 할지라도 모든 것이 설명된 대로 정확하게 수행되는지 어떻게 확신할 수 있습니까? 더 나쁜 것은 대부분의 파이프라인이 완전히 임시적이므로 나쁜 일이 발생하더라도 나중에 흔적이 남지 않는다는 것입니다.
간단히 말해서 파이프라인은 소프트웨어, 앱 또는 아티팩트를 테스트, 빌드 및 게시하는 자동화된 방법입니다. 이러한 파이프라인은 점점 더 일반화되고 점점 더 복잡해지고 있습니다. 파이프라인은 팀이 더 빠르게 작업하고 소프트웨어 아티팩트를 생성할 때 보다 일관되고 예측 가능한 결과를 제공하는 데 효과적입니다. 대기업이 서로 의존하는 수백 개의 조정된 파이프라인을 보유할 수 있으므로 모든 것이 원활하고 실패 없이 실행되는 것이 중요하다는 점을 고려하면 이러한 프로세스 자동화의 중요성은 더욱 분명해집니다.
개발자와 최종 사용자 또는 클라이언트 사이의 개발 프로세스의 최종 링크로서 이러한 자동화된 프로세스가 잠재적인 공격 벡터로 어떻게 사용될 수 있는지에 대한 초점이 충분하지 않다고 생각합니다. 빌드 파이프라인에 액세스하면 악의적인 행위자가 제작 회사의 시스템에 침투할 수 있을 뿐만 아니라 잠재적으로 결과 아티팩트를 수정하여 미래의 모든 사용자에게 영향을 미칠 수 있으므로 종종 폭발이라고 설명되는 거대한 폭발 반경을 생성할 수 있습니다. 소프트웨어 공급망 공격.
이전 기사에서는 지침이 되는 원칙에 대해 논의했습니다. CI/CD 파이프라인 보안. 이 기사에서는 CI/CD 파이프라인의 보다 일반적인 잠재적인 약점 중 일부를 다루고 몇 가지 해결 옵션을 제공하겠습니다. 우리의 목적을 위해서는 어떤 자동화 도구나 시스템을 사용하고 있는지는 중요하지 않습니다. 보안 원칙은 여전히 유효하며 파이프라인의 해당 섹션을 보호하는 작업에 적합한 도구를 찾으면 됩니다.
CI/CD 기술 익히기: 무시할 수 없는 핵심 요소
파이프라인마다 요소가 다르며 도구도 다릅니다. 제가 집중적으로 선택한 요소는 거의 모든 파이프라인과 관련이 있으므로 SCM, 도구 또는 기존 보안 설정에 관계없이 이러한 요소를 보호하는 것이 모범 사례로 간주될 수 있습니다.
비밀 관리 – 비밀은 일반적으로 소프트웨어나 파이프라인을 다른 리소스에 연결하는 데 사용되는 문자열 또는 토큰입니다. 일반적인 예는 코드를 S3 버킷과 같은 AWS 리소스에 연결하는 데 사용되는 API 키입니다. 대부분의 사람들은 이러한 비밀을 숨겨야 하며 공개 저장소에 일반 텍스트로 포함해서는 안 된다는 것을 이미 알고 있습니다. CI/CD 파이프라인 내부에서는 상황이 좀 더 복잡합니다. 일반적으로 파이프라인은 이러한 비밀이 나타내는 리소스와 정보에 액세스하려면 이러한 비밀에 액세스해야 합니다. 이는 파이프라인 내부에서 일어나는 일에 액세스할 수 있는 사람은 누구나 잠재적으로 귀하의 비밀을 보고 복사할 수 있음을 의미합니다. 파이프라인 내부에서도 비밀을 안전하게 유지하는 한 가지 방법은 다음과 같은 비밀 관리 도구를 사용하는 것입니다. Hashicorp 금고. 이러한 도구는 파이프라인 내부에서도 비밀을 난독화할 수 있을 뿐만 아니라 비밀 회전을 훨씬 쉽게 만들어 정기적으로 변경할 수 있으므로 파이프라인에서 비밀을 훔치는 것이 쓸모 없게 됩니다. 어떤 비밀 관리 도구를 선택하든 정기적으로 비밀을 교체하는 것은 좋은 보안 관행으로 간주될 수 있습니다.
중독된 파이프라인 실행(PPE) - PPE(포이즌 파이프라인 실행)는 위협 행위자가 CI 파이프라인을 '포이즌'할 수 있도록 하는 기술입니다. 즉, 파이프라인 지침 파일에 정의된 대로 파이프라인 단계나 순서를 변경하는 것입니다. 이 기술은 소스 코드 관리(SCM) 저장소의 권한을 남용하여 빌드 프로세스를 조작합니다. 이를 통해 빌드 파이프라인 구성에 악성 코드나 명령을 주입하여 파이프라인을 중독시켜 빌드 프로세스 중에 악성 코드를 실행할 수 있습니다. 각 빌드 전에 파이프라인 지침 파일을 확인하지 않으면 빌드가 지정한 대로 더 이상 실행되지 않는다는 사실을 알지 못할 가능성이 높습니다. 한 라이브러리를 다른 라이브러리로 호출하는 것과 같은 사소한 변경이라도 최종 제품에 백도어나 암호화폐 채굴기를 포함시키는 등 광범위한 영향을 미칠 수 있습니다.
PPE를 방지하는 방법 중 하나는 파이프라인 지침 파일이 수정되지 않았는지 확인하는 것입니다. 파일에 암호화 방식으로 서명하고 모든 파이프라인의 첫 번째 단계로 서명 확인을 추가할 수 있습니다. 파일에 서명하고 확인하는 데 사용할 수 있는 도구는 다음과 같습니다. 발린트, Scribe Security에서 게시한 도구입니다. 어떤 서명 확인 도구를 사용하든지 지침 파일 무결성이 그대로 유지되는지 확인하는 것이 중요합니다.
캐시/종속성 중독 – CI/CD 파이프라인 워크플로는 수행해야 하는 특정 작업을 지정하는 데 자주 사용됩니다. 각 워크플로우는 일련의 작업으로 특징지어지는 하나 이상의 일련의 작업으로 구성됩니다. 대부분의 워크플로는 보안상의 이유로 리소스를 공유하지 않습니다. 그러나 리소스를 공유해야 하는 경우에 대한 해결 방법이 있습니다. 모든 워크플로가 동일하게 액세스할 수 있는 캐시가 그러한 해결 방법 중 하나입니다. 캐시는 여러 워크플로에서 공유되므로 워크플로에서 한 번의 위반만 있으면 캐시를 변경하여 모든 후속 워크플로 사용에 해를 끼치게 됩니다. 싱글 중독된 캐시 다운로드할 새 아티팩트나 패키지가 있을 때만 캐시가 업데이트되므로 해당 파이프라인에서 실행되는 수많은 소프트웨어 빌드 반복에 영향을 미치면서 매우 오랫동안 활성화될 수 있습니다.
파이프라인 지침 파일 확인과 마찬가지로 다음을 사용할 수 있습니다. 발린트 서명하고 나중에 파이프라인에 필요한 모든 사전 승인된 종속성을 포함하는 캐시 또는 폴더를 확인합니다. 편집증적인 유형이라면 파이프라인이 독립적으로 인터넷에 연결하고 필요하다고 판단되는 라이브러리를 다운로드하도록 허용하는 것은 최종 빌드에 더 많은 취약점과 가능한 악용 가능성을 확보할 수 있는 확실한 방법입니다.
SSH 키 – SSH 키는 SSH(보안 셸) 네트워크 프로토콜에 대한 액세스 자격 증명입니다. 이 네트워크 프로토콜은 컴퓨터 간의 원격 통신에 사용됩니다. 보안되지 않은 개방형 네트워크. SSH는 원격 파일 전송, 네트워크 관리 및 원격 운영 체제 액세스에 사용됩니다. 예를 들어 SSH 키를 사용하면 방문할 때마다 사용자 이름과 개인 액세스 토큰을 제공하지 않고도 GitHub에 연결할 수 있습니다. SSH 키를 사용하여 커밋에 서명할 수도 있습니다. 마찬가지로 다음과 같은 SSH 키를 사용하여 다른 애플리케이션을 GitHub에 연결할 수 있습니다. BitBucket and GitLab.
계정 보안을 유지하려면 SSH 키 목록을 정기적으로 검토하고 유효하지 않거나 손상된 키를 취소/삭제해야 합니다. GitHub의 경우 다음 페이지에서 SSH 키 목록을 찾을 수 있습니다.
접속하다 설정 > SSH 및 GPG 키
SSH 키를 관리하는 데 도움이 되는 도구 중 하나는 다음과 같은 오픈 소스 보안 상태 보고서입니다. GitGat. GitGat 보고서는 구성된 SSH 키 중 하나라도 만료되었거나 유효하지 않은 경우 경고합니다. 키를 주의 깊게 관찰하고 자주 교체하는 것 외에도 GitHub는 익숙하지 않은 SSH 키가 보이면 즉시 삭제하고 문의하라고 경고합니다. GitHub 지원 추가 도움을 받으려면. 식별되지 않은 공개 키는 보안 위반 가능성을 나타낼 수 있습니다.
불변 파이프라인 로그로서의 SLSA 출처 - SLSA Supply Chain Levels for Software Artifacts의 약자로, 소프트웨어 공급망의 보안과 무결성을 개선하기 위해 Google과 기타 업계 파트너가 개발한 프레임워크입니다.
SLSA는 네 가지 수준으로 구성된 집합을 정의하며, 각 수준은 소프트웨어 공급망에서 더 높은 수준의 신뢰와 보증을 나타냅니다. 각 수준마다 보안 요구 사항이 증가합니다. 중요한 요구 사항 중 하나는 파일 출처가 필요하다는 것입니다. SLSA 프레임워크의 경우
출처는 무언가가 언제, 어디서, 어떻게 생산되었는지 설명하는 소프트웨어 가공물에 대한 검증 가능한 정보입니다. CI/CD 파이프라인의 대부분의 목적은 무언가(일반적으로 빌드)를 생성하는 것이므로 어떤 파일이 들어갔고 그 파일에 어떤 일이 발생했는지 정확히 추적할 수 있는 것은 일종의 위조할 수 없는 파이프라인의 머신 로그입니다. 이를 위해서는 SLSA 출처가 모든 사용자와 독립적으로 생성되는 것이 중요합니다. 사용자가 중단하거나 수정할 수 있는 모든 항목의 무결성이 의심될 수 있습니다.
다양한 SCM 시스템에 대한 파이프라인에서 SLSA 출처를 생성할 수 있는 도구 중 하나는 다음과 같습니다. 발린트 (예, Scribe와 동일한 도구입니다. 매우 다양한 도구입니다.) 링크는 Valint를 GitHub 파이프라인에 연결하여 해당 파이프라인에서 실행되는 각 빌드에 대한 SLSA 출처를 생성하는 방법을 보여줍니다. 나중에 각 출처 파일에 액세스하여 예상치 못한 일이 발생했는지 확인할 수 있습니다. 다음은 이러한 출처 파일의 일부입니다.
출처 파일은 단지 JSON 파일이지만 출처 파일을 읽는 자동화된 도구가 아직 없기 때문에 이를 읽고 해석하는 작업은 사용자의 몫입니다.
최종 결과 확보 – 최근 기억에 남는 가장 잘 알려진 소프트웨어 공급망 침해 중 하나는 SolarWinds 사건. 해커는 회사에서 출시되는 각 빌드에 비밀 백도어가 포함되도록 빌드 서버의 일부 코드를 수정했습니다. 최종 결과를 손상시키는 또 다른 유명한 사례는 2020년 베트남 정부 인증 기관(VGCA) 해킹에서 볼 수 있습니다. SignSight 작전. 침입자는 VGCA 웹사이트에 침투하여 다운로드 링크를 악성 코드가 포함된 소프트웨어 버전으로 리디렉션했습니다. 두 경우 모두 최종 사용자는 자신이 받은 소프트웨어가 생산 회사에서 출시하려고 했던 소프트웨어인지 확인할 방법이 없었습니다.
더 간단한 공격은 파이프라인 끝에 구축된 최종 이미지를 악의적인 이미지로 대체하고 잘못된 이미지를 필요한 모든 곳에 업로드하는 것입니다. 대부분의 이러한 공격에서 이미지는 생산 회사에서 나오는 것으로 추정되므로 해당 회사가 유효한 인증서로 보호되더라도 충분하지 않습니다. 그것은 가짜를 훨씬 더 믿을만하게 만들 것입니다.
다시 한 번 해결책은 파이프라인에서 생성된 최종 아티팩트가 무엇이든 암호화 방식으로 서명하고 최종 사용자가 해당 서명을 확인할 수 있도록 하는 것입니다.
이미 언급했으니까 발린트 오픈 소스 사용을 제안하겠습니다. Sigstore의 코사인. Cosign은 주요 인프라의 필요성을 제거하여 서명을 쉽게 만드는 것을 목표로 합니다. 이를 통해 사용자는 온라인으로 확인된 ID(예: Google, GitHub, Microsoft 또는 AWS)를 키로 사용할 수 있습니다. Cosign을 사용하면 이미지에 서명하고 확인할 수 있으므로 파이프라인의 최종 빌드 이미지에 서명하고 나중에 확인하는 데 이상적입니다.
Valint를 사용하든 Cosign을 사용하든 사용자가 최종 아티팩트의 암호화 서명을 확인하여 전달하려는 내용을 정확히 얻을 수 있도록 하는 것은 대부분의 최종 사용자가 높이 평가할 아이디어라고 확신합니다.
미래의 파이프라인 보안
물론 보안 강화로 이점을 얻을 수 있는 빌드 파이프라인과 관련된 다른 요소도 있습니다. 이 기사에서는 보다 분명하고 취약한 파이프라인 요소 중 일부를 살펴보기로 했습니다.
어떤 파이프라인 도구나 인프라를 사용하든 침해 가능성을 항상 주시해야 합니다. 완전히 안전하다고 말하는 시스템을 맹목적으로 신뢰하지 마십시오.
신원 도용, 스피어 피싱 및 기타 합법적인 액세스를 위조하는 형태의 증가하는 위협을 고려할 때 서명 확인 메커니즘이 디지털 도구 상자에 포함할 수 있는 훌륭하고 다재다능한 도구라고 생각합니다.
이미지, 파일 또는 폴더에 서명해야 한다면 그러한 요구에 맞는 원스톱 쇼핑 도구인 Scribe Security의 Valint를 자세히 살펴보시기 바랍니다.
이 콘텐츠는 소프트웨어 공급망 전반에 걸쳐 코드 아티팩트와 코드 개발 및 전달 프로세스에 최첨단 보안을 제공하는 선도적인 엔드투엔드 소프트웨어 공급망 보안 솔루션 제공업체인 Scribe Security에서 제공합니다. 자세히 알아보기.
관련 게시물
