CRACI vs GitLab CI

간단한 답변

GitLab은 완전한 DevSecOps 플랫폼입니다. 소스 관리, 머지 리퀘스트, 계획, CI/CD를 하나의 제품에서 제공하며, Ultimate 티어에는 폭넓은 보안 스캐너와 취약점 관리가 포함됩니다. 소프트웨어 수명 주기 전체를 하나의 공급업체로 해결하고 싶다면 GitLab은 바로 그런 용도로 만들어졌습니다.

CRACI는 범위가 더 좁습니다. 빌드가 가져오는 모든 외부 종속성을 기록하고, 빌드가 접근할 수 있는 대상을 제어하며, 그 기록을 SBOM, 출처 증명 데이터, CRA 증거로 바꾸는 GitHub Actions 호환 러너입니다. 핵심 차이는 스캐너를 덧붙인 전통적인 CI인가, 아니면 러너 자체가 보안 기록이 되는 CI인가입니다.

먼저 짚어 둘 실무적인 사항이 있습니다. CRACI는 현재 GitHub Actions만 지원하며, GitLab CI와 Jenkins는 로드맵에 있습니다. 파이프라인이 GitLab CI에 있다면 CRACI 러너를 사용하기 위해 GitHub Actions로 옮기거나, 로드맵에 있는 GitLab CI 지원을 기다려야 합니다.

GitLab의 강점

하나의 플랫폼. 코드, 리뷰, 파이프라인, 보안 발견 사항, 계획이 하나의 권한 모델 아래 같은 곳에 있습니다. 많은 조직에서는 이것만으로 결정이 납니다.

티어별 보안 스캔. 각 티어에 무엇이 포함되는지 정확히 알아야 합니다. GitLab에 따르면 기본 SAST, 시크릿 탐지, 컨테이너 스캔은 Free를 포함한 모든 티어에서 실행됩니다. Free와 Premium에서는 이러한 스캔이 JSON 보고서 아티팩트를 생성합니다. Ultimate는 그 주변의 워크플로를 추가합니다. 머지 리퀘스트의 발견 사항, 취약점 보고서, 종속성 목록, 보안 승인, GitLab Advanced SAST가 그것입니다. 종속성 스캔, 지속적인 취약점 스캔, DAST는 Ultimate 기능입니다. 컨테이너 스캔은 모든 티어에서 CycloneDX SBOM 보고서도 생성할 수 있습니다.

출처 증명. GitLab Runner는 모든 티어에서 SLSA 1.0 형식의 아티팩트 출처 증명 문서를 생성할 수 있습니다. 서명된 SLSA Level 3 증명도 있지만, GitLab은 이를 GitLab.com의 Ultimate용 실험 기능으로 분류하며 기본적으로 비활성화된 기능 플래그 뒤에 두고 있습니다.

러너 선택. GitLab 호스팅 러너는 x86-64(2~32 vCPU) 및 arm64 기반 Linux를 지원하며, Windows와 macOS는 베타입니다. 직접 운영하는 러너를 어디서든 실행할 수도 있으며, GitLab은 그런 러너에서 실행되는 작업은 컴퓨팅 시간을 소모하지 않는다고 밝힙니다. GitLab Dedicated는 원하는 리전에서의 데이터 상주를 추가로 제공합니다.

CRACI가 다른 점

SBOM은 잠금 파일이 아니라 빌드에서 나옵니다

GitLab의 SBOM 기반 종속성 스캔은 지원되는 잠금 파일이나 종속성 그래프 내보내기에서 종속성을 탐지합니다. 잠금 파일이 전체 내용을 말해 줄 때는 견고한 방식입니다. 하지만 빌드는 그보다 더 많은 일을 하는 경우가 많습니다. 설치 스크립트를 실행하고, 툴체인을 다운로드하고, 캐시를 복원하고, 베이스 이미지를 가져옵니다.

CRACI는 러너 자체이므로 이러한 활동을 봅니다. 패키지를 인식하는 프록시가 작업 실행 중 npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk, Git 소스와 다운로드 프리셋 전반에서 패키지 소스로 향하는 트래픽을 관찰합니다. 종속성 증거는 CI 캐시와 함께 이동하므로 캐시에서 복원된 패키지도 빠짐없이 기록됩니다. 모든 작업은 CycloneDX 또는 SPDX 형식의 SBOM을 생성합니다.

완전성은 가정하지 않고 명시합니다

각 SBOM에는 작업별·캐시별 완전성 상태가 표시됩니다. Complete, Complete with connections, Incomplete, Unavailable, Not recorded 중 하나입니다. 기록에 빈틈이 있으면 확인할 수 있습니다.

빌드 네트워크는 정책입니다

CRACI의 이그레스 정책은 기본 거부 또는 기본 허용이며, 24개의 내장 소프트웨어 소스 프리셋과 npm, PyPI, apt, apk, Go 프록시, Nix, Cargo, OCI 레지스트리, Git용 유형별 사용자 지정 소스를 제공합니다. 정책은 작업 시작 전에 검증되고, 실패 시 차단(fail closed)되며, 위반 시 알림을 보냅니다. GitLab에서 빌드의 네트워크 통제는 직접 운영하는 러너 주변에 스스로 구성한 것이 전부입니다.

출처 증명

API는 SBOM, 네트워크 트레이스, 출처 증명을 반환합니다. CRACI는 출처 증명에 서명하지 않으며 SLSA 레벨을 주장하지 않습니다.

출시된 것의 모니터링

CRACI는 빌드와 리포지토리 전반의 취약점을 집계하고, 새 보안 권고가 나오면 모니터링 중인 SBOM을 지속적으로 재평가합니다.

어떤 제품이 맞을까

• 코드와 파이프라인이 GitLab에 있고 하나의 플랫폼을 원하거나, SAST, DAST, 시크릿 탐지를 같은 제품에서 사용해야 한다면 GitLab을 계속 사용하세요.
• 코드가 GitHub에 있고 GitHub Actions를 사용하며, 각 릴리스에 무엇이 들어갔는지에 대한 증거, 빌드가 접근할 수 있는 대상에 대한 통제, 감사에서 입증할 수 있는 SBOM이 필요하다면 CRACI를 선택하세요.
• 조직에서 두 플랫폼을 모두 사용한다면 둘 다 사용하세요. GitLab은 계속해서 GitLab 프로젝트와 스캐너를 담당하고, CRACI는 GitHub Actions 쪽을 실행하며 그 빌드를 기록합니다.

Cyber Resilience Act 대응

EU Cyber Resilience Act에 따라 제조업체는 각 제품 릴리스에 무엇이 들어 있는지 파악하고 그 안의 취약점을 처리해야 합니다. 취약점 보고 의무는 2026년 9월부터 적용되며, 규정 전체는 2027년 12월부터 적용됩니다. GitLab Ultimate는 프로젝트 전반의 취약점을 찾고 관리하는 데 도움이 됩니다. CRACI는 각 릴리스가 무엇으로 빌드되었는지 기록하고, 이를 계속 모니터링하며, SBOM을 CycloneDX 또는 SPDX로 내보냅니다. 기업이 더 넓은 CRA 컴플라이언스 프로세스에 필요로 하는 소프트웨어 공급망 가시성과 증거의 상당 부분을 자동화합니다. 어느 도구도 그 자체로 규정 준수를 보장하지는 않습니다.

CRACI 추가하기

GitHub에 있는 리포지토리라면 조직에 CRACI GitHub App을 설치하고(전체 리포지토리 또는 선택한 리포지토리) 러너 레이블을 변경하세요.

runs-on: craci

워크플로, 액션, GitHub UI는 그대로입니다. CRACI는 GitHub Actions가 아니라 러너를 대체합니다. 빌드 시점 SBOM 생성과 CRA 증거에 대해 자세히 알아보거나 요금을 확인하세요.