모두가 점점 더 인식하게 되면서, 소프트웨어 공급망 보호 모든 조직의 사이버 보안 전략에서 중요한 부분이 되어야 합니다.
소프트웨어 공급망 위협을 완화하기 위한 포괄적인 전략을 수립하는 데 있어 가장 어려운 점 중 하나는 공급망의 복잡성과 다양성입니다. 각 공급망은 고유하고 관련 요소가 끊임없이 변화하므로 공급망이 생산하는 소프트웨어는 물론이고 자체 공급망을 신뢰하기도 어렵습니다.
이 기사에서는 소프트웨어 소비자와 생산자가 SDLC 보안에 대한 신뢰와 규정 준수를 투명하게 입증하고, 보안 모범 사례를 장려하고, 규제 요구 사항을 충족하고, 완화할 수 있는 지속적인 규정 준수 플랫폼에 대해 설명합니다. 사이버 위험 사용 a테스트.
우리가 제안한 모델은 선호하는 플랫폼이나 사용 사례에 관계없이 쉽게 확장하고 스택에 통합할 수 있는 세트 블록으로 구성됩니다. 다음을 사용하여 기본 확인 정책을 시연하는 것으로 마무리하겠습니다. Scribe의 Valint 도구 이 과정이 처음에 두려워했던 것만큼 복잡하지 않다는 것을 보여주기 위해서입니다.
공급망 혼란 이론
공급망을 확보하는 데 있어 주요 과제 중 하나는 관련 시스템이 매우 복잡하다는 것입니다. 소프트웨어 공급망에는 최종 제품 생성과 관련된 모든 소프트웨어가 환경의 일부로 또는 코드 베이스에 통합된 소프트웨어로 포함됩니다. 이 설명을 통해 이러한 공급망은 방대하며 개발자가 코드를 작성하기 시작하는 순간부터 컴파일, 테스트, 통합을 거쳐 최종 제품이 실행되고 모든 부분을 통합하는 지점까지 모든 것을 포함한다는 것을 알 수 있습니다. 그 과정에서 사용되는 소프트웨어와 라이브러리.
이러한 시스템에 대한 보안 모델을 정의하려면 광범위한 프로그래밍에 대한 이해가 필요합니다. 특정 공급망에 포함될 수 있는 언어, 패키지 관리자, 제품, 기술 스택, CI 서비스, 클라우드 공급자, 종속성 가져오기, VM, 운영 체제 및 기타 구성 요소. 애플리케이션, 토큰, 키 및 기타 형태의 액세스 권한을 포함하여 이러한 시스템 내에서 위험에 처할 수 있는 광범위한 자산을 고려하는 것이 중요합니다.
정책 검증 모델 개요
우리가 제안한 모델에는 공급망의 보안과 규정 준수를 보장하기 위해 함께 작동하는 여러 빌딩 블록이 포함되어 있습니다.. 이러한 빌딩 블록은 소프트웨어 보안 측면과 소프트웨어 공급망 규정 준수를 지속적으로 확인하는 데 필요합니다.
- 증거: 정책에 의해 자동으로 사용되는 불변 객체입니다. 이러한 개체에는 정책 시행을 활성화하고 규정 준수 요구 사항을 충족하는 데 필요한 메타데이터가 포함되어 있습니다. 증거 콘텐츠에는 아티팩트, 이벤트 및 설정에 대한 메타데이터가 포함되지만 실제 보고서, 구성 또는 스캔을 수집할 수도 있습니다.
증거 서명된 형식과 서명되지 않은 형식 모두로 올 수 있습니다. 우리는 i를 따르는 것을 제안합니다엔토토 증명 사양 서명된 것을 활용하여 증명 그리고 서명되지 않은 성명서 형식을 각각 지정합니다.- 증명(AKA 검증 가능한 서명된 증거): 특정 사건과 관련된 검증 가능한 증거 환경적 맥락, 어떤 형태의 PKI 서명을 사용하여 신뢰를 전달합니다.
- 환경적 맥락: 상황별 정보가 모델을 하나로 묶습니다.
증거가 어디서 왔는지, 어떤 정보가 포함되어 있는지에 대한 질문에 답합니다. 동일한 컨텍스트에 연결된 여러 증거 조각을 가질 수 있고 이 모델을 사용하면 증거를 더 쉽고 효율적으로 검색할 수 있으므로 컨텍스트가 증거의 일부가 되기보다는 증거에 연결되는 것이 중요합니다.
기본적으로 환경 컨텍스트는 환경, 플랫폼 또는 아티팩트에서 대부분의 레이블을 읽는 레이블 지정 시스템입니다. 레이블은 개발 프로세스 및 CI/CD 파이프라인의 여러 프로세스에 대한 정규화된 액세스를 제공합니다. Git 리포지토리, 태그, 커밋뿐만 아니라 워크플로 이름, 작업 이름, runID 등과 같은 증거의 출처와 관련된 측면입니다. 환경 컨텍스트에는 아티팩트 해시, 이름 및 태그와 같은 주제의 측면도 포함될 수 있습니다.
컨텍스트는 in-toto의 확장으로 볼 수 있습니다. 증명 사양, 서명된 페이로드에 통합되었습니다. 라벨링 시스템을 사용하면 정책 평가 단계에서 다양한 측면에서 라벨별로 증거를 쿼리하는 방법을 제공할 수 있습니다. 또한 상황 데이터는 정책 평가 프로세스의 일부로 사용되어 증거에 "상황 인식"을 추가할 수 있습니다.
- 정책 : 필수 규정 준수 보고서를 정의하는 사용자 구성 정책 모듈 세트입니다. 정책은 빌드 파이프라인이나 개발 프로세스에 포함된 다양한 유형의 제품이나 시스템에 대해 최소 보안 표준이나 필수 규정 준수 수준을 지정할 수 있습니다. 가장 중요한 것은 정책 평가 결과를 통해 준수 보고서가 생성된다는 것입니다. 증명 또한. 이를 통해 우리는 규정 준수 상태를 이해관계자에게 공개하는 등 규정 준수 보고서를 관리할 수 있을 뿐만 아니라 조직에 대한 규정 준수 규정의 더 넓은 범위를 캡슐화할 수 있는 보다 복잡한 정책에 대한 규정 준수 보고서를 활용할 수도 있습니다. 정책은 다음과 같이 그룹화될 수 있습니다. 정책 모듈. 이는 일부 특성(소프트웨어 모듈과 유사)을 공유하는 정책 규칙 세트를 구현하는 플러그인입니다. 이러한 플러그인은 정책 제공자(나중에 자세히 설명)에서 제공합니다.
정책 모듈을 평가하면 평가, 규정 준수 세부 사항, 문제의 보안 규정을 언급하는 평결 등이 포함된 결과가 제공됩니다. 또한 결과에는 규정 준수 여부를 평가한 증거 모듈을 역추적하는 데 필요한 증거의 기록 추적이 포함됩니다. - 판매처: 증거에 대한 호스팅, 업로드/다운로드 및 쿼리 기능을 제공하는 서비스입니다(자세한 내용은 나중에 설명). 이는 이미지 레지스트리(저장소로서의 OCI), 전용 서비스(예: Scribe 서비스) 또는 단순히 로컬 파일 시스템을 통해 활용될 수 있습니다.
- 정책 제공자: 이는 정책 모듈 서명 및 제공을 담당하는 엔터티(회사, 조직)입니다. 공급자는 일종의 증명으로 정책을 제공함으로써 정책 자체에 신뢰와 투명성을 전달합니다. 예를 들어, OPA 번들 증명은 규제 기관이 정책 모듈을 구현하는 공식 OPA 번들을 게시하고 서명할 수 있는 권한을 부여할 수 있습니다.
이러한 빌딩 블록을 활용함으로써 우리 모델을 통해 조직은 빌드 파이프라인 및 개발 수명 주기의 보안과 규정 준수를 상대적으로 쉽게 확인할 수 있습니다.
어떻게 작동합니까?
이 워크플로의 시작점은 소프트웨어 제품이나 구성 요소에 대한 증거를 생성하는 개발자나 시스템입니다. 증거 내용은 물론 상황별 정보, 제목, 서명도 수집되어 증거 저장소에 업로드됩니다.
반면, 규정 준수 보고서는 조직의 필요와 요구 사항에 맞는 정책을 평가하여 생성됩니다.
정책 평가는 상황별 정보를 사용하여 공급망에서 생성된 증거를 쿼리하고 규제에서 요구할 수 있는 모든 정보가 포함되어 있는지 확인할 수 있습니다..
추가적인 이점으로, 정책 및 규정 준수 보고서는 그 자체로 증거로 액세스할 수 있어 투명성과 신뢰를 제공할 뿐만 아니라 관련된 모든 증거에 대한 기록 추적을 제공합니다. 이를 통해 조직은 규정 준수 보고서를 관리할 수 있을 뿐만 아니라 이를 신뢰할 수 있는 증명으로 사용하여 소프트웨어 소비자에게 신뢰를 전달할 수 있습니다..
이러한 흐름을 활용함으로써 조직과 이해관계자는 위험을 줄이고 투명성을 제공하며 공급망 내 규정 준수를 보장하여 혼란의 영향을 줄이고 제품에 대한 전반적인 보안과 신뢰를 향상시킬 수 있습니다.
정책 평가
이 어플리케이션에는 XNUMXµm 및 XNUMXµm 파장에서 최대 XNUMXW의 평균 출력을 제공하는 평가 정책은 각각 특정 규정 및 규정 준수 요구 사항을 준수하는 일련의 정책 모듈을 확인하여 수행됩니다.
정책 평가에서는 각 모듈에 두 가지 간단한 질문을 던집니다.
- 모듈을 준수하려면 어떤 증거가 필요합니까?
- 규정 준수를 입증하는 증거의 기준은 무엇입니까?
예를 들어, 다음과 같은 맥락에서 SLSA(소프트웨어 아티팩트에 대한 공급망 수준) 프레임워크, 정책 모듈은 보안 요구 사항을 준수하기 위해 서명된 SLSA 출처 증거와 빌드 파이프라인에 대한 보안 상태 검색이 모두 필요함을 지정할 수 있습니다. 그런 다음 이러한 모듈에서 제공되는 증거를 확인하여 모든 SLSA 요구 사항을 충족하는지 확인합니다.
- SLSA 요구 사항을 준수하려면 어떤 증거가 필요합니까?
- 빌드 아티팩트의 SLSA 출처 증명(서명된 증거)입니다.
- 아티팩트를 생성하는 CI 파이프라인의 보안 상태 스캔입니다.
- SLSA 요구 사항 준수를 입증하는 증거의 기준은 무엇입니까?
- 두 가지 증거에는 모든 SLSA 요구 사항을 충족하는 정보가 포함되어야 합니다.
이 예에서 SLSA 출처 증명은 이미지 빌드 프로세스를 전체적으로 설명해야 하는 반면, 보안 상태 증명은 이미지 소스를 저장한 SCM이 분기 보호 규칙을 사용하는지 확인해야 합니다.
- 두 가지 증거에는 모든 SLSA 요구 사항을 충족하는 정보가 포함되어야 합니다.
정책 모듈의 또 다른 예는 다음과 같습니다. 아티팩트 모듈 확인, 이는 일부 아티팩트가 신뢰할 수 있는 소스에 의해 서명되어야 함을 지정합니다. 증명 활용(검증 가능한 서명된 증거) PKI(공개 키 인프라) 서명은 아티팩트에 서명하고 아티팩트가 시작된 컨텍스트를 증명해야 하는 일부 특정 개인/단체의 요구 사항을 준수합니다.
이 어플리케이션에는 XNUMXµm 및 XNUMXµm 파장에서 최대 XNUMXW의 평균 출력을 제공하는 아티팩트 모듈 확인 다음 질문에 답합니다.
1. 보안 요구 사항 준수를 입증하려면 어떤 증거가 필요합니까?
- PKI 서명(증명)을 포함하는 아티팩트를 설명하는 증거입니다.
2. 규정 준수를 보장하기 위해 이 증거를 어떻게 확인할 수 있습니까?
- 증명 PKI 서명이 유효합니다.
- PKI 인증서 ID가 사용자 요구 사항과 일치합니다.
- 증거의 주제가 사용자 요구 사항과 일치합니다.
- 형식과 출처가 사용자 요구 사항과 일치합니다.
이론에서 실습으로
현재 Valint 도구에서 지원되는 이 모델의 구현을 자세히 살펴보겠습니다.
이미지의 서명과 원본을 확인하는 방법을 지정하는 간단한 정책 예를 살펴보겠습니다.
구체적으로, 증거가 다음 기준을 충족하는지 확인해야 합니다.
- 증거 유형은 이미지를 설명하는 CycloneDX SBOM 증명입니다.
- 유물에 서명된 사람은 다음과 같습니다. mycompany.com.
- 이미지는 다음에 의해 트리거된 Circle-CI 워크플로에서 생성됩니다. my_image_src 레포.
템플릿 정책
이전 예에서 정책은 정적이었고 다음과 같은 특정 이미지에 대해서만 확인되었습니다. 내 회사/내_이미지. 그러나 템플릿/변수 기능을 지원하는 정책을 갖는 것이 더 나은 경우가 많습니다. 이를 통해 CI/CD 빌드 파이프라인의 여러 유사한 프로세스 또는 아티팩트에 적용할 수 있는 요구 사항을 정의할 수 있습니다.
정책을 템플릿화하려면 정책을 제품에 정적으로 잠그는 대신 변수를 사용할 수 있습니다. 위의 예에서는 유물_이름 값을 `$MY_IMAGE대신 평가자는 동일한 규정 준수 규정을 요구하는 다수의 이미지에 대해 하나의 정책을 구성할 수 있습니다.
기대
At 학자, 우리의 궁극적인 목표는 증거 중심의 검증 가능한 규정 준수 모델을 통해 공급망의 위험을 완화하는 것입니다. 이 모델을 시험해 볼 수 있는 첫 번째 장소 중 하나는 CI/CD 빌드 파이프라인입니다. 우리는 이러한 증거 검증 접근 방식이 공급망의 투명성과 책임성을 보장하고 관련된 모든 이해관계자에게 이익을 주는 열쇠라고 믿습니다. 우리의 모델은 소프트웨어 공급망 커뮤니티에서 떠오르는 많은 아이디어를 요약하여 이들 간의 관계를 정의합니다. 우리는 소프트웨어 공급망 투명성을 혁신하고 개선하기 위해 최선을 다하고 있습니다. 이 모델이 관심을 불러일으켰다면 당사의 제품을 확인해 보시기 바랍니다. Valint CLI 문서 여기서는 도구의 기능과 용도를 확장합니다. 자유롭게 사용해 보세요.
이 콘텐츠는 소프트웨어 공급망 전반에 걸쳐 코드 아티팩트와 코드 개발 및 전달 프로세스에 최첨단 보안을 제공하는 선도적인 엔드투엔드 소프트웨어 공급망 보안 솔루션 제공업체인 Scribe Security에서 제공합니다. 자세히 알아보기.
관련 게시물
