사전 예방적 파이프라인 보안: Scribe를 사용하여 OWASP 상위 10개 CI/CD 위험 적용

이 기사는 공동으로 작성되었습니다. 마이키 스트라우스 그리고 빅토르 카르타쇼프.

OWASP 상위 10대 위험을 자동화된 감사 가능한 제어로 전환

현대 DevOps 환경에서 CI/CD 파이프라인은 소프트웨어 제공의 핵심입니다. 하지만 빠른 속도만큼 노출도도 높아집니다. 기업들이 출시 속도를 높이면서, 공격자들은 악성 코드를 주입하고, 기밀 정보를 유출하고, 공급망 무결성을 침해하기 위해 안전하지 않은 파이프라인을 점점 더 노리고 있습니다.

이를 해결하기 위해 OWASP Top 10 CI/CD 보안 위험 프레임워크는 개발 파이프라인 전반에서 가장 흔하고 심각한 취약점을 강조합니다. 서기 보안, 우리는 조직이 서명된 증거, 이니셔티브 기반 시행 및 정책 코드 등을 통해 CI/CD 보안을 워크플로에 직접 내장할 수 있도록 돕기 위해 이 프레임워크를 채택했습니다.

OWASP CI/CD 위험이 중요한 이유

기존 보안 도구는 최신 파이프라인의 속도를 따라잡는 데 어려움을 겪습니다. 자동화된 시행 및 가시성이 없으면 다음과 같은 일반적인 문제가 발생합니다.

❌ 파이프라인 구성에 하드코딩된 비밀

❌ 출처가 없는 변조된 빌드 아티팩트

❌ 공개 레지스트리에서 가져온 안전하지 않은 기본 이미지

❌ 2FA 또는 검토 제어가 없는 관리자 수준 액세스

OWASP 프레임워크는 이러한 위험을 공식화하여 수정을 위한 공통 언어와 구조를 제공합니다. Scribe에서는 이를 활용하여 빌드 프로세스를 크게 변경하지 않고도 CI/CD 파이프라인의 보안 태세를 자동으로 검증하는 이니셔티브를 정의합니다.

보안은 서명된 증거로 시작됩니다

파이프라인이 안전한지 확인하기 위해 다음과 같은 증거를 수집하고 암호화하여 서명합니다.

• Git SBOM 및 이미지 SBOM
  다음을 사용하여 생성 스크라이브-시큐리티/액션-봄이를 통해 코드와 컨테이너에 무엇이 있는지 완벽하게 파악할 수 있습니다.
• SLSA 출처
  유물이 어떻게, 어디서, 누구에 의해 만들어졌는지 파악합니다.
• GitHub org 및 repo 스캔
  를 통해 실행 액션 플랫폼 비밀, 구성 드리프트, 잘못 구성된 액세스를 확인합니다.

이러한 모든 증거는 무결성과 추적성을 보장하기 위해 서명되며, 수명 주기 추적을 위해 특정 제품 및 버전에 매핑됩니다.

📌 우리는 이전 게시물에서 이 증거 기반 모델을 다루었습니다. SLSA 준수 그리고 SP 800–190 시행.

🔒 Policy-as-Code를 통한 OWASP 컨트롤 시행

Scribe에서는 OWASP Top 10 CI/CD 위험을 다음과 같이 매핑합니다. 정책-코드 이니셔티브 CI 파이프라인에서 직접 실행됩니다. 각 위험은 로컬에서 정의된 구성 가능한 규칙으로 표현됩니다. owasp-top10-cicd.yaml 파일. 이러한 규칙은 검증 단계에서 자동으로 평가되어 실행 가능한 피드백과 수정 지침을 제공합니다.

포함된 주요 제어 기능은 다음과 같습니다.

• CICD-SEC-1 : 지점 보호 규칙 시행
  중요한 브랜치에 대한 직접 푸시를 제한하여 무단 코드 변경을 방지합니다. 본관.
• CICD-SEC-2 :  ID 및 액세스 관리 제어
  Git 공급자에서 다중 요소 인증(MFA)을 요구하고 관리자 권한을 제한합니다.
• CICD-SEC-3 : 종속성 검증
  모든 기본 이미지와 타사 종속성이 승인되고 신뢰할 수 있는 레지스트리에서 가져왔는지 확인하세요.
• CICD-SEC-4 :  오염된 파이프라인 실행 방지
  워크플로에 악의적인 논리가 도입되는 것을 방지하기 위해 CI/CD 스크립트를 수정할 수 있는 사람을 제한합니다.
• CICD-SEC-6 :  신원 확인 위생 시행
  하드코딩된 비밀, 만료된 토큰 또는 유출된 자격 증명을 스캔한 다음 공개하기 전에 플래그를 지정합니다.

이러한 각 제어 기능은 조직의 위험 허용 범위, 환경 또는 규정 준수 요구 사항에 따라 맞춤 설정할 수 있습니다. 코드로 정의되므로 보안 태세가 다음과 같이 향상됩니다. 감사 가능, 버전 제어및 자동화로 시행 가능.

✅ 프로 팁 : 이니셔티브 구성 파일에서 직접 특정 규칙을 포함하거나 제외하고, 심각도 임계값을 설정하고, 수정 조언을 맞춤화할 수도 있습니다.

이러한 제어를 파이프라인으로 가져오면 임시 검토에서 자동화되고 검증 가능한 보안 시행  – 소프트웨어 공급망을 보호하는 데 중요한 단계입니다.

GitHub Actions: 실제 CI/CD 통합

다음은 Scribe의 작업을 사용하여 OWASP Top 10 CI/CD 프레임워크를 구축하고, 증거를 수집하고, 조직을 검사하고, 규정 준수를 확인하는 워크플로의 예입니다.

이름: OWASP CI/CD 보안 빌드 대상: push: branch: - main env: PRODUCT_NAME: my-app PRODUCT_VERSION: v1.0 jobs: build: runs-on: ubuntu-latest outputs: image-name: ${{ steps.meta.outputs.image }} steps: - uses: actions/checkout@v4 - uses: docker/setup-buildx-action@v3 - run: echo "${{ secrets.REGISTRY_PASSWORD }}" | docker login ${{ secrets.REGISTRY_URL }} -u ${{ secrets.REGISTRY_USER }} --password-stdin - id: meta uses: docker/build-push-action@v5 with: context: . push: true 태그: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} - 사용: scribe-security/action-bom@master 대상: 'git:.' 제품 키: ${{ env.PRODUCT_NAME }} 제품 버전: ${{ env.PRODUCT_VERSION }} 형식: attest - 사용: scribe-security/action-bom@master 대상: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} 기본 이미지: Dockerfile 제품 키: ${{ env.PRODUCT_NAME }} 제품 버전: ${{ env.PRODUCT_VERSION }} 형식: attest - 사용: scribe-security/action-verify@master 대상: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} 제품 키: ${{ env.PRODUCT_NAME }} 제품 버전: ${{ env.PRODUCT_VERSION }} 이니셔티브: slsa.l2@v2 출처: true 형식: attest beautify: true org-scan: runs-on: ubuntu-latest 단계: - 사용: scribe-security/action-platforms@master with: 명령: discover 플랫폼: github 서명: true attest-default: sigstore 인수: >- --token ${{ secrets.GITHUB_PAT }} --organization.mapping ${{ github.repository_owner }}::${{ env.PRODUCT_NAME }}::${{ env.PRODUCT_VERSION }} --repository.mapping $(basename ${{ github.repository }})::${{ env.PRODUCT_NAME }}::${{ env.PRODUCT_VERSION }} --scope.workflow.past_days 1 --scope.branch ${{ github.ref_name }} --hook trivy_iac_and_secrets_sarif verify: runs-on: ubuntu-latest에 필요한 것: [build, org-scan] 단계: - 사용: scribe-security/action-verify@master with: initiative: owasp-top10-cicd.yaml 제품 키: ${{ env.PRODUCT_NAME }} 제품 버전: ${{ env.PRODUCT_VERSION }} 형식: attest all-evidence: true beautify: true

지속적인 규정 준수 실천

이 워크플로는 파이프라인의 OWASP 위험 통과 여부를 보여주는 검증 가능한 증명을 제공합니다. 각 위반 사항은 특정 증거(SBOM, 워크플로 로그, 조직 구성)를 통해 추적 가능하므로 팀은 문제를 신속하고 확실하게 해결할 수 있습니다.

실제로 어떻게 보이는지 보고 싶으신가요? 저희 내부 파이프라인 중 하나에서 얻은 스캔 결과 예시를 보여드리겠습니다.

요약 보기

위반 보기

증거 보기

관련 게시물

SBOM 서명: 끊임없이 변화하는 퍼즐 풀기

지난 몇 년 동안 SBOM(Software Bill Of Materials)에 관해 많은 말이 쓰여졌습니다. 이러한 모든 노출을 통해 사람들은 설명하기에 충분할 만큼 잘 알고 있다고 느낍니다. 이는 소프트웨어 구성 요소의 목록이고 투명성과 보안에 중요하며 일시적인 종속성을 노출하는 데 도움이 됩니다. 모두 […]

소프트웨어 자재 목록을 통한 취약점 식별: 보안, 투명성 및 규정 준수 보장

소프트웨어 공급망의 복잡성이 증가함에 따라 소프트웨어 구성 요소를 관리하고 보호하는 것이 더욱 어려워졌습니다. 이를 해결하기 위해 소프트웨어 자재 목록(SBOM)이 소프트웨어 개발 라이프사이클에서 보안, 투명성 및 규정 준수를 보장하는 중요한 도구로 등장했습니다. SBOM은 […]를 만드는 데 사용된 모든 구성 요소에 대한 포괄적인 기록입니다.

OMB 메모로 인해 수익이 손실되지 않도록 어떻게 할 수 있나요?

미국 정부는 사이버 보안 정책을 개편하는 과정에 있습니다. 여기에는 SDLC(소프트웨어 개발 수명 주기) 전반에 걸쳐 보안 취약성을 줄이는 것을 목표로 하는 NIST(National Institute of Standards and Technology)의 SSDF(Secure Software Development Framework) 버전 1.1 출시가 포함됩니다. 이 문서는 소프트웨어 공급업체와 인수업체에 "[...]