SLSA 레벨에 도달하기 위해 해야 할 일 - 실무 가이드

배경

SLSA(소프트웨어 아티팩트 공급망 수준)는 변조 방지, 무결성 향상, 패키지 및 인프라 보안을 목표로 하는 보안 프레임워크입니다. SLSA의 핵심 개념은 소프트웨어 아티팩트가 다음 세 가지 요구 사항을 준수하는 경우에만 신뢰할 수 있다는 것입니다.

1. 유물에는 원산지와 제작 과정을 설명하는 출처 문서가 있어야 합니다(L1).
2. 출처 문서는 신뢰할 수 있고 검증된 다운스트림(L2)이어야 합니다.
3. 빌드 시스템은 신뢰할 수 있어야 합니다(L3).

SLSA 프레임워크는 소프트웨어 공급망이 얼마나 안전한지 나타내는 수준을 정의합니다. 이러한 수준은 이러한 요구 사항의 구현 수준(위에서 L1-L3으로 표시됨)에 해당합니다.

서기관의 valint slsa 명령을 사용하여 출처 문서를 생성할 수 있습니다. 다음에서는 이 도구를 사용하여 SLSA 레벨을 달성하는 방법을 설명합니다.

참고: 여기서는 SLSA V1.0 프레임워크를 참조합니다.

SLSA L1

XNUMXD덴탈의 기타 요건 SLSA L1의 경우 다음이 포함됩니다.

• 소프트웨어 제작자는 일관된 빌드 프로세스를 따릅니다.
• 빌드 플랫폼은 아티팩트가 빌드된 방법을 설명하는 출처 데이터를 자동으로 생성합니다.
• 소프트웨어 생산자는 출처 데이터를 소비자에게 배포합니다.

SLSA L1 달성을 위한 체크리스트:

• CI 시스템을 사용하여 소프트웨어를 구축하세요. 소스 제어되는 빌드 스크립트를 사용하는 것이 좋습니다.
• 활성화 valint slsa 명령을 빌드 스크립트의 일부로 사용하여 출처 문서를 생성합니다. 주의할 점은 valint slsa  명령을 사용하면 출처 문서에 추가 정보를 추가할 수 있습니다. 출처 문서의 내용을 필요에 맞게 조정할 수 있습니다.

SLSA L2

XNUMXD덴탈의 기타 요건 SLSA L2의 경우 다음이 포함됩니다.

• SLSA L1 요구 사항.
• 빌드는 출처 자체를 생성하고 서명하는 호스팅된 빌드 플랫폼에서 실행됩니다.
• 출처에 대한 다운스트림 검증에는 출처의 진위 여부를 검증하는 것이 포함됩니다.

SLSA L2 달성을 위한 체크리스트:

• SLSA L1 체크리스트.
• 호스팅된 빌드 서비스를 사용합니다(개발자 컴퓨터에서 빌드를 수행하는 것과 반대).
• 서명된 출처 문서를 생성합니다(서명되지 않은 문서 대신 SLSA L1에 충분함). 이는 다음을 실행하여 달성할 수 있습니다. valint slsa ... -o attest. 서기관의 발린트 도구에는 다양한 서명 기능이 있습니다. 기업의 경우 X.509 PKI 키와 인증서를 사용하는 것이 좋습니다. 
• 다음을 사용하여 출처 문서 다운스트림의 진위 여부를 확인합니다. valint verify명령. 확인에는 서명, 서명 신원뿐 아니라 SLSA 출처 문서의 내용을 보장하는 기타 확인 규칙이 포함될 수 있습니다. 몇 가지 예는 Scribe의에서 찾을 수 있습니다. 정책 카탈로그.

참고: 검증은 구축된 소프트웨어의 소비자가 수행해야 합니다. 내부 규정 준수를 위해 테스트 파이프라인의 일부로 검증을 수행할 수 있습니다.

SLSA L3

SLSA L3 요구 사항

XNUMXD덴탈의 기타 요건 SLSA L3의 경우 다음이 포함됩니다.

• SLSA L2 요구 사항.
• 빌드 플랫폼은 다음을 위해 강력한 제어를 구현합니다.
  • 동일한 프로젝트 내에서도 실행이 서로 영향을 미치지 않도록 합니다.
  • 출처 서명에 사용된 비밀이 사용자 정의 빌드 단계에서 액세스되지 않도록 방지합니다.

또한, 빌드 플랫폼을 신뢰하려면 다음이 필요합니다. 빌드 플랫폼 확인. 빌드 플랫폼은 출처 문서가 신뢰할 수 있다는 점에서 신뢰되어야 합니다. 위조할 수 없는 그리고 빌드는 외딴. 이러한 검증을 통해 다음 요구 사항이 도출됩니다.

• 확인 플랫폼의 사용이 중단되지 않습니다 위조 불가능성과 고립성 요구 사항.
  • 예를 들어 격리 확인은 파이프라인에서 캐시 사용을 평가하여 수행할 수 있습니다.
  • 출처 문서의 위조 불가능성을 보장하려면 전용 빌드 파이프라인에서 문서를 생성하고 서명하는 것이 좋습니다.
• 다음을 확인하십시오. 빌드 플랫폼의 신뢰성.
  •  SaaS CI의 경우 빌드 플랫폼 공급업체를 통해 확인을 수행해야 합니다. 소프트웨어 생산자가 빌드 시스템 배포를 담당하는 경우 공급업체 자체 증명과 배포 측면 분석 수행을 함께 수행하는 것이 좋습니다.
  • 예를 들어 자체 호스팅 CI를 배포할 때 공급업체 증명에서는 빌드가 서로 격리되는 방법을 선언해야 하며 배포 분석에서는 CI 시스템의 액세스 권한 및 로그 감사를 확인해야 합니다.

이러한 요구 사항을 충족하는 것은 CI 플랫폼에 따라 다르고 완전히 자동화할 수 없으며 빌드 시스템 및 파이프라인에 대한 전문적인 보안 분석이 필요하기 때문에 어렵습니다. 이것이 바로 SLSA 프레임워크가 조직이 SLSA L2에서 SLSA L3 준수로 점진적으로 발전할 것을 구체적으로 제안하는 이유입니다.

이 기사를 여기까지 읽어보고 SLSA L3가 자신에게 적합하다고 결정했다면 소매를 걷어붙이고 권장되는 체크리스트는 다음과 같습니다.

SLSA L3 달성을 위한 체크리스트:

• SLSA L2 체크리스트.
• CI 시스템을 평가합니다. 목표는 다음 질문에 답하는 것입니다.
  • 어떤 조건에서 승인되지 않은 개체가 빌드 시스템을 회피할 수 있나요?
  • 어떤 조건에서 빌드가 서로 영향을 미칠 수 있나요?

답변을 받은 후 나머지 위험을 관리하십시오.

• 출처 문서의 생성을 분리합니다.
  • 출처 문서 생성을 다른 파이프라인, 바람직하게는 별도의 빌드 서비스로 분리합니다.
    • 출처 문서 서명에 사용된 비밀만 이 파이프라인에 노출합니다.
    • 이 파이프라인에서 출처 문서 콘텐츠를 생성하거나 확인하세요. 검증의 경우 빌드 플랫폼이나 기타 신뢰할 수 있는 소스에서 직접 수집된 데이터를 사용하여 파이프라인 내에서 생성된 출처 문서의 가능한 모든 필드를 검증합니다.
• 다른 파이프라인 실행에서 빌드 파이프라인을 격리하고 확인합니다.
  • 캐시 및 공유 볼륨의 사용을 확인하십시오.
  • 다른 파이프라인과 공유된 비밀로 인해 파이프라인이 서로 영향을 미칠 수 없는지 확인합니다.
  • 파이프라인 실행이 서로 영향을 미칠 수 없는지 확인
    • 예를 들어, 한 파이프라인을 통해 수행된 설치가 다른 파이프라인 실행에 영향을 미치지 않도록 방지합니다. 이는 임시 빌드 실행기(예: 각 빌드에 대해 생성되는 컨테이너)를 사용하거나 빌드 실행기가 미리 결정된 상태에서 매번 시작되는지 확인하여 수행할 수 있습니다.

Scribe 도구를 사용하여 SLSA L3을 달성하려면 다음을 권장합니다.

• 출처 문서를 채우는 데 필요한 모든 증명을 생성하기 위해 빌드 파이프라인을 계측합니다. 예를 들어, 빌드 중에 설치되는 종속성 목록을 원한다고 결정할 수 있습니다. 이 목록은 다음을 통해 생성될 수 있습니다. valint bom dir:명령. 또한 다음을 사용하여 파이프라인에서 출처 증명을 생성합니다. valint slsa 명령.
• 다음을 수행하는 별도의 신뢰할 수 있는 출처 생성 파이프라인을 만듭니다.
  • 빌드 파이프라인에서 생성된 문서를 기반으로 신뢰할 수 있는 출처 문서를 생성합니다.
    • 빌드 서비스에서 데이터를 수집하고 이를 사용하여 출처 문서를 확인하고 업데이트합니다.
    • 빌드 파이프라인에서 생성된 증명의 콘텐츠를 확인합니다. 예를 들어 빌드 파이프라인의 SBOM 증명을 별도로 샘플링된 SBOM 증명과 비교하여 빌드 실행기의 콘텐츠를 확인하세요.
    • 빌드 파이프라인에서 수집된 증명을 사용하여 출처 문서를 업데이트합니다.
    • 출처 문서 업데이트는 다음을 사용하여 수행할 수 있습니다. valint slsa 명령.
  • 빌드 서비스에서 수집된 데이터를 평가하여 빌드가 격리되었는지 확인합니다. 예를 들어 캐시와 비밀의 사용을 확인합니다.

이러한 데이터 수집 및 평가를 수행하기 위해 Scribe는 빌드 실행에 대한 증명을 생성하고 필요한 확인을 수행하는 도구를 제공합니다.

---

괜찮은. 이제 갈 준비가 다 된 것 같습니다. 물론, 도움이 필요하다면, 알려주. 우리는 도움을 드리기 위해 여기 있으며 조언이나 적극적으로 도움을 드리고 싶습니다.

관련 게시물

GitHub 캐시 중독

CI 내부에서 무슨 일이 일어나는지 알고 있나요? 깊은 이해가 없으면 혁신적인 공급망 공격에 취약할 수 있습니다. 이 문서에서는 이러한 공격에 대해 설명합니다.

ML-뭐? ML-Bom의 개념과 활용에 대한 이해

업계에서는 아직 SBOM에 대한 아이디어를 완전히 이해하지 못했고, 우리는 이미 ML-BOM(머신 러닝 자재 명세서)이라는 새로운 용어를 듣기 시작했습니다. 당황하기 전에 이러한 BOM을 생성해야 하는 이유, ML-BOM 생성의 어려움, ML-BOM의 모양을 이해해 보겠습니다. […]

CISA의 SBOM 공유 수명 주기 보고서에서 배울 수 있는 내용

2023년 XNUMX월 DHS, CISA, DOE, CESER는 '소프트웨어 자재 명세서(SBOM) 공유 수명 주기 보고서'라는 제목의 보고서를 발표했습니다. 보고서의 목적은 사람들이 SBOM을 공유하는 현재 방식을 검토하고 이러한 공유가 어떻게 더 효율적이고 정교하게 수행될 수 있는지 개괄적으로 설명하는 것이었습니다.