Valint를 사용하여 SDLC에 정책 적용

Valint는 증거 생성, 관리, 서명 및 확인을 위한 주요 Scribe 도구입니다. 안에 이전 게시물에서는 CI/CD 파이프라인의 보안을 검증하는 주요 도구로 서명 및 증거 확인을 사용하는 이론을 다루었습니다. 간단히 말씀드리자면, Scribe가 제안한 모델에는 필요에 따라 섞고 쌓을 수 있는 여러 빌딩 블록이 포함되어 있습니다. 빌딩 블록에는 수집된 증거가 포함됩니다(SBOM, SLSA 출처, 포함하려는 제3자 테스트 결과), 수집된 증거의 환경적 맥락(누가, 어디서, 언제 등을 생성했는지 등), 해당 증거에 적용하려는 정책.

증거에 적용하려는 정책이 이 모델의 핵심 요소이기 때문에 우리는 우리가 제공하는 정책 엔진의 잠재력을 더 자세히 탐구하기 위해 블로그 게시물을 전용할 것이라고 생각했습니다.

이번 글에서는 저희가 고안한 가장 기본적인 정책(정보 서명 및 확인)에 대해 살펴보겠습니다. 보다 복잡한 정책에 대한 템플릿의 모양을 다루고 특정 사용자가 마지막 '기본' 분기를 생성한 사용자인지 확인하는 방법 또는 파이프라인이 실행되는지 확인하는 방법과 같은 정책에 대한 몇 가지 표준 예를 제공합니다. 포함되어야 하는 타사 도구 테스트가 포함되어 있습니다.

여기에서 시작하세요: 서명 및 증거 확인

발린트 는 매우 다양한 도구이지만 이 기사를 단순하게 유지하기 위해 주로 Valint의 CLI 인터페이스를 예로 사용하겠습니다.

첫 번째 단계는 Valint를 다운로드하는 것입니다.

curl -sSfL https://get.scribesecurity.com/install.sh | sh -s -- -t valint

리포지토리나 이미지에서 SBOM을 생성하는 명령은 'bom'입니다. 예를 들어, 원하는 경우 bom 의 이미지 busybox:latest 명령은 다음과 같습니다:

$HOME/.scribe/bin/valint bom busybox:latest -o attest -f

참고 attest 에 대한 별칭입니다 attest-cyclonedx-json.

기본적으로 Valint는 시그스토어 Scribe의 Cocosign 라이브러리에 내장된 서명 메커니즘 뒤에 있는 엔진인 대화형 흐름입니다. 이 라이브러리는 서명 및 확인을 위한 디지털 서명을 다룹니다. 명령을 적용한 후에는 먼저 Y/[N] 옵션을 사용하여 증거에 서명하겠다는 것을 승인해야 합니다.

서명에 표준 PKI를 사용할 수도 있습니다(x509 인증서 지원). 서명 키를 저장하는 데는 KMS, GitHub 비밀 저장소 등 여러 가지 옵션이 있으며 원하는 서명 메커니즘을 사용하도록 Valint를 쉽게 구성할 수 있습니다.

서명을 승인한다고 가정하면 브라우저에서 GitHub 계정, Google 계정 또는 Microsoft 계정을 사용하여 로그인해야 하는 Sigstore로 이동하게 됩니다.

로그인하고 나면 로그인이 성공한 것을 확인할 수 있습니다.

이 시점에서 브라우저를 닫고 셸로 돌아가서 증거가 성공적으로 생성되었음을 확인할 수 있습니다.

증명은 기본적으로 위치가 제공되는 로컬 캐시에 기록됩니다. --output-directory 구성 파일 플래그의 플래그입니다. 다음을 사용할 수도 있습니다. -결과물 파일 증명에 대한 사용자 지정 경로를 제공하는 플래그입니다.

이제 서명된 증명을 만들었으므로 그것이 존재하고 서명되었는지 확인해 보겠습니다. 증거를 확인하라는 명령은 다음과 같습니다. verify. 사용방법은 거의 동일합니다. bom 우리가 플래그를 사용할 것이라는 점을 제외하고 명령 -i짧게 --input-format 기본값은 다음과 같습니다. bom, 증명-cyclonedx-json. verify 명령은 먼저 Valint가 사용하는 기본 위치에서 필요한 증거를 찾습니다. 증거를 저장하고 나중에 찾기 위해 다른 위치를 지정할 수 있습니다.

그래서, 그 내용을 확인하고 싶다면 busybox:latest 이전 예에서 생성하고 서명한 이미지 증명 명령은 다음과 같습니다.

$HOME/.scribe/bin/valint verify busybox:latest -i attest

모든 작업을 올바르게 수행했다고 가정하면 결과는 다음과 같습니다.

원본 증명의 서명자 이메일이 포함된 이메일 목록을 볼 수 있으며 확인된 증명 유형(이 경우 cyclonedx-json)도 볼 수 있습니다. 

꽤 간단해 보이죠? 한 단계 더 발전시켜 봅시다.

정책 템플릿

A 정책 의 세트로 구성 모듈. 정책에 포함된 모든 모듈이 평가되고 확인되면 정책이 확인됩니다. 모듈 구성 및 설정을 준수하는 증거가 발견되면 모듈이 검증됩니다.  

정책은 정책 섹션 아래 Valint 구성 파일의 일부로 구성됩니다. 이는 잠재적인 정책을 포함하는 Valint 구성 파일의 일부 예입니다. 

프로젝트에 구성 파일을 포함할 필요가 없다는 점을 기억하세요. Valint는 기본 옵션만 활성화해도 잘 작동할 수 있습니다. 또한 이 파일의 모든 내용은 선택 사항이므로 정책만 포함하는 파일을 갖는 것이 완벽하게 유효합니다. 

기본 이름이 .valint.yaml인 구성 파일은 저장소 루트에 포함되어야 합니다. 이 파일에 포함된 정책에 따라 명령을 실행할 때 valint verify 활성화된 모든 정책과 모듈이 실행됩니다. 기본 '확인' 정책이 기본값이므로 verify .valint.yaml 파일이 없어도 제대로 작동하는 명령입니다.

구성 파일에 추가하는 모든 정책은 찾아야 할 증거가 있는지에 따라 달라집니다. 기본적으로 파이프라인에서 'bom' 명령을 실행하면 결과 증거가 Scribe 증거 저장소에 업로드됩니다. 마찬가지로 'verify' 명령을 실행하면 Scribe 증거 저장소에서 증거를 찾습니다. 이 기본값을 변경하고 OCI 또는 캐시를 증거 저장소로 사용할 수 있지만 이 문서에서는 기본값이 사용되고 모든 증거가 Scribe 증거 저장소에서 업로드되고 가져오는 것으로 가정합니다.

따라서 이 예를 바탕으로 정책의 구성 요소를 살펴보겠습니다. 그만큼 정책 다음 필드를 지원합니다.

• name, 정책 이름(필수).
• 가능, 모듈을 활성화합니다(기본값은 false입니다).
• 모듈, 정책 모듈 구성 목록입니다.  

 

이 어플리케이션에는 XNUMXµm 및 XNUMXµm 파장에서 최대 XNUMXW의 평균 출력을 제공하는 모듈 섹션은 다음 필드를 지원합니다.

• name, 정책 모듈 이름(필수).
• 가능, 모듈을 활성화합니다(기본값은 false입니다).
• 유형, 현재 지원하는 모듈 유형 검증-아티팩트 and 자식 소유자.
• 일치, 특정 맥락과 증거를 일치시킵니다.
• 입력, 모듈별 구성.

정책에는 여러 모듈이 있을 수 있으며 'verify' 명령을 실행하면 활성화된 모든 모듈이 실행됩니다. 

무미건조한 필드 목록은 별로 유익하지 않다는 것을 알고 있으므로 바로 다음 섹션인 샘플 정책으로 넘어가겠습니다.

샘플 정책

이미지 검증 정책

Valint 서명 확인 흐름을 표현하는 가장 간단한 정책부터 시작해 보겠습니다. 

증명: cocosign: 정책: - 이름: verify_policy 활성화: true 모듈: - 이름: signed_sbom 유형: verify-artifact 활성화: true 입력: 서명됨: true 형식: attest-cyclonedx-json ID: 이메일: - barak@scribesecurity.com

다시 말하지만, 이 정책은 저장소 루트에 있는 .valint.yaml 파일에 포함되어야 합니다. 작동하려면 다음을 실행하여 서명된 SBOM을 미리 생성해야 합니다. valint bom 명령. 확인할 준비가 되면 다음을 실행해야 합니다. valint verify 명령.

이 예를 보면 정책이 활성화되어 있고 다음 유형의 활성화된 모듈이 하나 있음을 알 수 있습니다. ‘verify-artifact‘. 모듈은 입력이 서명되었는지, 형식인지 확인합니다. ‘attest-cyclonedx-json’, 이메일에 표시된 신원으로 서명되었습니다. ‘barak@scribesecurity.com’.

이 정책을 실행하려면 다음을 실행해야 합니다. verify파이프라인에서 다음과 같은 명령을 실행하세요.

valint verify busybox:latest

이후 verify 명령은 이제 우리가 제공한 정책을 기반으로 합니다. busybox:latest Scribe 증거 저장소에 있는 증거 조각. 형식의 서명된 SBOM을 찾습니다. `cyclonedx-json` SBOM에 서명한 신원이 정책에 규정된 이메일을 사용하는지 확인합니다. `barak@scribesecurity.com`.

그 증거 저장소에 그런 이미지가 여러 개 있을 수 있다고 말할 수도 있고 당신 말이 맞을 수도 있습니다. 이것이 바로 맥락이 작용하는 곳입니다. 기본적으로, verify 명령은 사용 가능한 가장 가까운 일치 항목을 찾습니다. 그러나 명령이 파이프라인 실행 ID의 컨텍스트 또는 아티팩트가 생성된 빌드 시스템과 일치해야 한다고 지정할 수 있습니다. 그렇게 하려면 필드를 사용해야 합니다. match: 적절한 컨텍스트 유형을 사용합니다. 예를 들어:

            일치: context_type: github git_url: github.com/my_org/myimage.git 분기: 메인

이 경우 증거는 Github에서 이름이 지정된 저장소에 의해 생성되어야 합니다. git_url 과에 의해 main 해당 저장소의 분기입니다. 정책에서 확인하려는 내용을 정확하게 확인하려면 필요한 경우 올바른 컨텍스트를 사용하는 것이 중요합니다. 

바이너리 검증 정책

또 다른 예를 살펴보겠습니다. 이 정책은 우리가 확인하고 있는 exe 파일이 특정 저장소에서 왔으며 여러 알려진 개인 중 한 명이 서명했는지 확인하기 위한 것입니다. 

증명: cocosign: 정책: - 이름: verify_policy 활성화: true 모듈: - 이름: 바이너리_모듈 유형: verify-artifact 활성화: true 입력: 서명됨: true 형식: attest-cyclonedx-json ID: 이메일: - barak@scribesecurity.com - mikey@scribesecurity.com - adam@scribesecurity.com match: target_type: file context_type: azure git_url: https://dev.azure.com/mycompany/somerepo # 환경의 Git URL. input_name: my_binary.exe

이 예를 보면 정책이 활성화되어 있고 다음 유형의 활성화된 모듈이 하나 있음을 알 수 있습니다. ‘verify-artifact‘ 모듈은 입력이 서명되었는지, 형식이 맞는지 확인합니다. ‘attest-cyclonedx-json’, 모듈에 나열된 허용된 이메일 1개 중 3개에 의해 서명되었습니다. 또한, 다음을 확인합니다. verify 명령은 입력을 수신하여 입력 이름이 지정되었는지 확인합니다. ‘my_binary.exe’, 입력은 Azure에서 생성된 파일이고 특정 git URL에서 가져온 것입니다. https://dev.azure.com/mycompany/somerepo.

보시다시피 이 예에는 정책을 확인하기 위한 더 많은 요구 사항이 있습니다.

이 정책을 실행하려면 다음을 실행해야 합니다. verify 파이프라인에서 다음과 같은 명령을 실행하세요.

valint verify file:my_binary.exe

Scribe 증거 저장소에 이 바이너리의 서명된 버전이 있는지 확인하려면 먼저 다음과 같은 증거를 만들어야 합니다.

valint bom file:my_binary.exe -o attest

제3자 증거 검증 정책

마지막 예에서는 우리가 사용하는 타사 도구가 파이프라인에서 제대로 실행되고 JSON 파일 형식으로 기대하는 결과를 생성했는지 확인하는 방법을 살펴보겠습니다. 

증명: cocosign: 정책: - 이름: verify_policy 활성화: true 모듈: - 이름: 타사 규칙 유형: verify-artifact 활성화: true 입력: 서명됨: false 형식: attest-generic ID: 이메일: - bob@scribesecurity. com 일치: target_type: 일반 context_type: azure git_url: https://dev.azure.com/mycompany/somerepo git_branch: 기본 input_name: 3rd-party-scan.json

이 예에서는 파이프라인의 어느 시점에서 타사 도구를 실행하여 '3rd-party-scan.json' 파일을 생성했다고 가정합니다. 해당 파일이 Azure DevOps에서 시작되어야 한다는 정책을 충족하려면 `https://dev.azure.com/mycompany/somerepo` 저장소 및 서명자 `bob@scribesecurity.com`. 

우리가 찾고 있는 증거를 생성하려면 타사 도구가 실행된 직후 결과 파일을 캡처하고 Valint를 사용하여 증거로 바꿔야 합니다.

valint bom 3rd-party-scan.json -o attest-generic --predicate-type https://scanner.com/scan_format

증거는 무엇을 증명하는가? 

따라서 우리는 Valine을 사용하여 파이프라인의 다양한 사항을 확인할 수 있다는 것을 확인했습니다. 이 능력은 실제로 무엇에 사용될 수 있습니까?

우리의 파이프라인이 침해되었고 일부 악당이 그 안에서 우리가 원하지 않는 일을 하기 시작했다고 상상해 봅시다. 파이프라인의 다양한 단계가 예상대로 발생했는지 확인하고 예상한 결과를 생성하며 승인된 직원이 서명함으로써 악의적인 사람들이 우리를 속이는 것을 훨씬 더 어렵게 만듭니다.

한 가지 잠재적인 공격은 클라이언트가 얻는 버전이 원본이 아닌 악성 버전이 되도록 파이프라인 끝에서 바이너리 파일을 바꾸는 것입니다. 귀하의 버전에 서명하고 귀하의 고객에게 해당 마스터 사본에 대해 확인하도록 요청함으로써 교묘한 위조가 아닌 귀하가 생성한 동일한 파일을 모든 고객이 사용하는지 확인할 수 있습니다.

증거를 만들고 검증하는 이 모델은 이제 시작에 불과합니다. 우리는 Valint에 추가 기능을 추가하여 더욱 강력하고 다재다능하게 만들기 위해 지속적으로 노력하고 있습니다. 그동안 다음을 확인해 보시기 바랍니다. 선적 서류 비치 Scribe가 제공하는 기능과 Valint로 더 많은 작업을 수행할 수 있는 기능에 대해 자세히 알아보세요. Valint는 무료로 다운로드하여 사용할 수 있으므로 오늘 이 도구를 사용해 보는 것을 방해할 만한 요소가 전혀 없습니다.