제품
CRACI가 스택에서 대체하는 것과 함께 쓰는 것
CRACI는 GitHub Actions 러너를 대체하고, 그와 함께 빌드가 무엇을 사용했는지 재구성하려는 빌드 계층의 도구도 대체합니다. 각 팀이 실행하는 SBOM 생성 도구, 공급망 커버리지를 위한 Yocto 내장 SBOM 생성, 그리고 독립형 SBOM 기반 취약점 추적입니다. 코드, 시크릿, 실행 중인 서비스, 완성된 바이너리를 검사하는 도구와는 함께 사용합니다. 이유는 CRACI의 위치에 있습니다. CRACI는 러너 자체이므로 빌드를 볼 수 있습니다. 소스 코드를 읽어 결함을 찾지는 않습니다.
업데이트
요약: 옮겨 가는 것과 남는 것
이 표로 자사 스택을 정리해 보세요. 각 행은 스택 안의 도구가 현재 맡고 있는 작업, 그 작업에 필요한 정보, 그리고 CRACI가 자신의 위치에서 그 작업을 맡을 수 있는지를 보여 줍니다.
| 스택 안의 작업 | 작업에 필요한 정보 | CRACI | 유지하는 것과 그 이유 |
|---|---|---|---|
| GitHub Actions의 Linux 작업용 CI 러너: GitHub 호스팅, 서드파티 러너 공급업체 또는 자체 호스팅 플릿 | 작업을 실행할 곳 | 대체 | Windows, macOS, GitHub Enterprise Server, GitHub Actions 이외의 CI 시스템용 러너. CRACI는 현재 이를 지원하지 않습니다 |
| 유지하는 러너에 추가한 네트워크 모니터링 또는 이그레스 에이전트 | 작업의 아웃바운드 트래픽 | CRACI 러너에서 대체 | 다른 곳에서 계속 쓰는 러너의 에이전트 |
| 팀별로 CI에서 실행하는 SBOM 생성 도구: SBOM을 만드는 데 쓰는 매니페스트, 잠금 파일 또는 이미지 스캐너 | 빌드가 실제로 가져온 것 | CRACI 빌드에서 대체 | CRACI에서 빌드하지 않는 소프트웨어용 생성 도구(풀만 하고 빌드하지 않는 이미지 등) |
공급망 커버리지를 위한 Yocto 내장 SBOM 생성(create-spdx) |
BitBake 빌드가 가져온 모든 소스와 도구 | 공급망 커버리지에서 대체 | 레시피 메타데이터(적용된 패치, 수정됨으로 표시된 CVE)에 의존한다면 create-spdx |
| SBOM 기반 취약점 추적: SBOM 업로드, 보안 권고와 매칭, 새 권고 감시 | 릴리스마다 정확하고 최신 상태로 유지되는 SBOM | CRACI 빌드에서 대체. 공급업체 SBOM도 추가 가능 | CRACI가 하지 않는 기능(도달 가능성 분석, MTTR이나 심각도별 기한 같은 수정 지표)이 필요하다면 전용 도구 |
| 스프레드시트로 관리하는 SBOM과 구성 요소 목록 | 릴리스마다 정확하고 최신 상태로 유지되는 SBOM | 대체 | 없음 |
| 선언된 라이선스 검사와 라이선스 정책 | 각 구성 요소의 선언된 라이선스 | 일부 | 전문 및 스니펫 수준의 라이선스 스캔, 저작자 표시 고지 |
| SAST와 코드 스캔 | 소스 코드 | 함께 사용 | 유지하세요. CRACI 러너에서 워크플로 단계로 그대로 실행됩니다 |
| 시크릿 스캔과 푸시 보호 | 리포지토리와 커밋 | 함께 사용 | 유지하세요 |
| DAST와 API 테스트 | 실행 중인 서비스 | 함께 사용 | 유지하세요 |
| 서드파티 바이너리의 바이너리 및 펌웨어 분석 | 직접 빌드하지 않은 완성된 바이너리 | 함께 사용 | 유지하세요 |
| 복사되거나 벤더링된 코드의 스니펫 및 시그니처 스캔 | 리포지토리의 파일 내용 | 함께 사용 | 유지하세요 |
| 도달 가능성 기반 우선순위 지정 | 호출 그래프 | 함께 사용 | 의존하고 있다면 유지하세요 |
| IaC, 클러스터, 잘못된 구성 스캔 | 구성과 실행 중인 인프라 | 함께 사용 | 유지하세요 |
| 워크플로 구성에 대한 CI/CD 보안 태세 점검 | 워크플로 파일과 설정 | 함께 사용 | 유지하세요 |
| 티켓 관리, PSIRT 사례 관리, 보안 권고 게시 | 업무 프로세스 | 함께 사용 | 유지하세요 |
| 컴플라이언스 자동화: SOC 2 또는 ISO 27001 감사를 위한 증거 수집 | 여러 시스템에 걸친 통제 | 함께 사용 | 유지하세요. CRACI의 기록은 그 도구가 수집할 수 있는 증거가 됩니다 |
도입 전과 도입 후
도입 전: GitHub 호스팅 러너, 팀 워크플로마다 다른 SBOM 생성 도구, 빌드 시간을 늘리는 Yocto의 create-spdx,
추적 도구나 스프레드시트에 업로드되는 SBOM이 있고, 그 주변에 코드 스캔, 시크릿 스캔, 바이너리 분석, 티켓 관리가 있습니다.
도입 후: CRACI 러너가 각 작업을 실행하고, 이그레스 정책을 강제하고, SBOM을 기록해 모니터링합니다. 코드, 리포지토리, 바이너리,
업무 프로세스를 읽는 도구는 바뀌지 않습니다.
CRACI가 대체하는 것과 그 이유
이 작업들은 모두 빌드 중에 일어납니다. CRACI는 빌드가 실행되는 곳이기 때문에 이 작업들을 맡을 수 있습니다. 각각에 대해 동작 방식, 포기하는 것, 예시를 설명합니다.
러너
CRACI는 GitHub Actions용 러너입니다. runs-on을 craci로 바꾸면, 실행 결과는 다른 Actions 작업과
마찬가지로 GitHub에 표시됩니다. 각 작업은 Linux x86-64 또는 ARM64에서 1에서 32 vCPU 크기의 전용 가상 머신을 받고, 초 단위로
계량됩니다. 워크플로를 다시 작성할 필요가 없으며, 스캔 단계를 포함한 기존 단계가 그대로 계속 실행됩니다.
CRACI는 빌드 시간에 대해서만 요금을 부과합니다. vCPU 분당 $0.002(기본 2 vCPU 러너는 $0.004)이며, 초 단위로 계량하고, 월 요금도 SBOM당 요금도 없습니다. 그래서 가장 저렴한 CI 러너 중 하나입니다. 더 빠른 하드웨어, 더 짧은 대기열 시간, 캐싱 덕분에 GitHub 호스팅 러너보다 약 2배 빠르게 빌드를 실행합니다.
| 러너, 분당 | CRACI | GitHub 호스팅 | 차이 |
|---|---|---|---|
| 2 vCPU x64 | $0.004 | $0.006 | CRACI가 약 33% 저렴 |
| 2 vCPU ARM64 | $0.004 | $0.005 | CRACI가 20% 저렴 |
| 32 vCPU x64 | $0.064 | $0.082 | CRACI가 약 22% 저렴 |
| 32 vCPU ARM64 | $0.064 | $0.050 | CRACI가 28% 비쌈 |
GitHub 정가는 2026년 9월 기준입니다. GitHub는 각 작업을 1분 단위로 올림하고, CRACI는 초 단위로 계량합니다. 예시: GitHub 호스팅 2코어 x64 러너에서 10분 걸리는 빌드는 $0.060입니다. 약 2배 빠르므로 2 vCPU CRACI 러너에서는 5분이 걸리고 비용은 $0.020으로, 약 67% 낮습니다. 요금과 CI 러너 요금을 확인하세요.
포기하는 것. Windows와 macOS 러너, 다른 CI 시스템, 고객 호스팅 러너는 현재 제공되지 않습니다. GitLab CI, Jenkins, Windows, macOS, 고객 호스팅 러너는 로드맵에 있습니다. GitHub Enterprise Server는 지원하지 않습니다. 러너는 관리형이며 유럽 인프라에서 실행됩니다. 관리형 러너와 자체 플릿을 비교하고 있다면 관리형 러너와 자체 호스팅 러너 비교를 확인하세요.
유지하는 러너의 이그레스 에이전트
이그레스 에이전트는 다른 누군가가 운영하는 러너의 트래픽을 감시하거나 제한합니다. CRACI에서는 러너 자체가 이그레스 정책을 강제합니다. 기본 거부 또는 기본 허용, 24개의 내장 소프트웨어 소스 프리셋, 패키지 레지스트리와 Git용 유형별 사용자 지정 소스, 명시적인 네트워크 규칙을 사용할 수 있습니다. 정책은 작업이 시작되기 전에 검증되고 실패 시 차단(fail closed)되며, CRACI는 정책 위반을 알립니다. CRACI 러너에는 별도의 에이전트가 필요하지 않습니다.
예시: 침해된 종속성이 빌드에 한 번도 필요하지 않았던 호스트로 작업의 시크릿을 보내려고 합니다. 기본 거부 정책이면 아무도 본 적 없는 공격이라도 연결이 차단됩니다. 정책이 알려진 악성 호스트를 찾는 대신 빌드에 필요한 것만 허용하기 때문입니다.
포기하는 것. 정책은 CRACI 러너의 작업에 적용됩니다. 다른 곳에서 계속 쓰는 러너에는 여전히 별도의 통제가 필요합니다.
각 팀 워크플로의 SBOM 생성 도구
생성 도구는 매니페스트, 잠금 파일, 이미지처럼 눈앞에 있는 파일을 읽고 무엇이 들어갔는지 재구성합니다. 같은 체크아웃에서도 생성 도구마다 다른 목록을 내놓고, 팀은 보통 각자 도구를 고르기 때문에 조직에는 서로 맞지 않는 여러 인벤토리가 남습니다.
CRACI는 각 작업이 실제로 가져온 패키지를 기록합니다. CI 캐시에서 복원된 패키지와, 잠금 파일 기반 도구가 놓치는 숨은 종속성도 포함됩니다. npm install 훅이 내려받는 코드, 빌드 시점에 다운로드하는 Rust 빌드 스크립트, 컨테이너 빌드의 베이스 이미지와 운영체제 레이어가 그 예입니다. SBOM의 모든 구성 요소는 실제로 빌드에 있었던 것입니다. 각 작업의 SBOM은 Complete, Complete with connections, Incomplete, Unavailable, Not recorded 중 하나로 완전성을 표시하므로, 누락이 조용히 묻히지 않고 드러납니다. 그 결과 CRACI에서 빌드하는 모든 리포지토리에 하나의 인벤토리가 생기며, CycloneDX 또는 SPDX로 내보낼 수 있습니다. 현재 기록하는 에코시스템은 npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk, Git 소스, 그리고 Yocto와 OpenEmbedded 다운로드입니다.
예시: expressjs/express 5.2.1은 잠금 파일을 커밋하지 않습니다. 잠금 파일에서 종속성을 해석하는
생성 도구는 그곳에서 해석할 것이 없는데도, package.json에 선언된 npm 종속성을 하나도 나열하지 않은 문서를 반환할 수
있습니다. 같은 프로젝트를 CRACI에서 빌드하면 npm install이 가져온 패키지가 기록됩니다. 방법에 대한 자세한 내용은
빌드 시점 SBOM과 SCA 및 SBOM 도구 비교를
확인하세요. 생성 도구를 직접 조합한 스택이라면 DIY SBOM 스택을 확인하세요.
포기하는 것. CRACI가 아직 기록하지 않는 에코시스템입니다. Maven과 Java는 로드맵에 있으며, 위 목록에 없는 것은 지원되지 않습니다. 그런 빌드에는 생성 도구를 유지하세요.
Yocto 내장 SBOM 생성
Yocto는 create-spdx로 자체 SPDX SBOM을 작성하며, BitBake가 빌드하는 것에 대해서는 철저합니다. 하지만 BitBake
메타데이터 밖에서 일어나는 일은 볼 수 없습니다. CRACI는 BitBake 빌드를 실행하고 가져온 것을 기록합니다. 32 vCPU 네이티브
ARM64 러너에서 core-image-sato를 나란히 빌드한 비교에서 CRACI의 SBOM에는 Yocto SBOM의 모든 구성 요소와 함께
Yocto가 놓친 88개가 더 있었습니다. 빌드 머신의 호스트 패키지 23개, GitHub Action actions/upload-artifact를
포함한 GitHub 소스 10개, 빌드 중에 가져온 기타 소스와 도구 55개입니다. 653개의 Rust 크레이트 버전도 모두
pkg:cargo 패키지 URL과 함께 기록해 보안 권고와 매칭할 수 있습니다. Yocto의 SBOM 생성 없이 실행한 빌드는 시간이
43% 적게 걸렸습니다. CRACI 요금 기준으로 빌드당 약 $9.96 대비 $5.68입니다.
포기하는 것. Yocto의 SPDX에는 CRACI가 기록하지 않는 레시피 메타데이터, 즉 적용된 패치와 수정됨으로 표시된
CVE가 담겨 있습니다. 이에 의존한다면 create-spdx를 켜 두세요. 방법과 전체 비교는
CRACI의 Yocto 빌드에 있습니다.
SBOM을 취약점 추적으로 연결하기
독립형 추적 도구는 SBOM을 공급받아야 하고, 받은 것을 그대로 신뢰합니다. CRACI는 SBOM을 생성하고 기록을 보관합니다. 모니터링 중인 SBOM은 새 보안 권고가 게시될 때마다 지속적으로 재평가됩니다. 빌드 기록을 보면 취약한 종속성(직접 또는 전이적)을 포함한 빌드가 무엇인지 알 수 있으므로, 플랜의 보존 기간 안에서 영향을 받은 기간을 파악할 수 있습니다. 탐지 결과는 수정을 담당하는 팀으로 분류되고, CRACI는 취약점과 그 심각도를 관련 담당자에게 알리며, 정책 게이트는 탐지 결과를 근거로 빌드를 차단할 수 있습니다. 특정 CVE를 포함한 빌드도 차단할 수 있습니다. VEX를 지원합니다. 공급업체 SBOM도 추가할 수 있어, 구매한 구성 요소도 자체 빌드와 함께 모니터링됩니다.
예시: 서비스 중 하나가 3개월 전에 컴파일해 넣은 크레이트에 대해 보안 권고가 게시됩니다. CRACI는 모니터링 중인 모든 SBOM과 매칭해 그 버전을 포함했던 빌드를 보여 줍니다. 누구도 다시 업로드할 필요가 없습니다.
포기하는 것. CRACI는 도달 가능성 분석이나 MTTR, 심각도별 기한, 백로그 추이 같은 수정 지표를 제공하지 않습니다. 이에 의존한다면 그것을 제공하는 도구를 유지하세요. 전체 기능은 취약점 추적에서 확인하세요.
스프레드시트
SBOM 도구가 없는 팀에서 CRACI가 대체하는 것은 수작업 취합입니다. 릴리스나 감사 전에 누군가가 종속성 목록을 스프레드시트에 복사합니다. CRACI의 빌드는 실행의 부산물로 SBOM을 생성하므로, 누군가 기억한 빌드만이 아니라 모든 빌드에 목록이 존재합니다.
CRACI와 함께 쓰는 것과 그 방법
이 도구들은 CRACI가 결코 읽지 않는 것을 읽습니다. CRACI는 소스 코드를 읽어 결함을 찾지 않고, 실행 중인 서비스를 테스트하지 않으며, 직접 빌드하지 않은 바이너리를 분석하지 않습니다. 이 도구들은 지금처럼 계속 실행됩니다.
코드와 리포지토리를 읽는 도구
SAST, 시크릿 스캔과 푸시 보호, 스니펫 및 시그니처 스캔, IaC 스캔, CI/CD 보안 태세 점검은 모두 코드, 커밋 또는 구성을 검사합니다. 워크플로의 단계는 CRACI 러너에서 그대로 실행되고, 리포지토리 수준 기능은 원래 러너에서 실행된 적이 없으므로 영향을 받지 않습니다. 코드 스캔 단계는 빌드와 같은 작업에 둘 수 있습니다. SAST는 의도적으로 범위에서 제외했습니다. CRACI와 함께 쓸 수 있는 훌륭한 SAST 도구가 많습니다. 두 종류의 탐지 결과가 어떻게 다른지는 SAST와 SCA 비교에서 확인하세요.
직접 빌드하지 않은 것을 검사하는 도구
공급업체 바이너리의 바이너리 및 펌웨어 분석, 풀만 하고 빌드하지 않는 이미지의 스캐너, 실행 중인 서비스에 대한 DAST는 모두 다른 곳에서 빌드되었거나 이미 실행 중인 것을 봅니다. CRACI는 빌드를 기록합니다. 공급업체에서 오는 바이너리는 CRACI가 본 적 없는 곳에서 빌드된 것입니다. 공급업체가 SBOM을 제공하면 CRACI는 자체 빌드와 함께 그것을 모니터링할 수 있습니다.
도달 가능성 기반 우선순위 지정은 호출 그래프를 읽는데, CRACI는 호출 그래프를 분석하지 않습니다. 의존하고 있다면 유지하세요. 그것이 알려 줄 수 있는 것과 없는 것은 도달 가능성 분석에서 확인하세요.
업무 프로세스 시스템
티켓 관리, PSIRT 사례 관리, 보안 권고 게시, 컴플라이언스 자동화 플랫폼은 여러 시스템에 걸쳐 업무 프로세스를 운영합니다. CRACI는 탐지 결과를 담당 팀으로 전달하고 빌드의 증거를 보관합니다. 나머지에는 프로세스 도구를 계속 사용하세요. 기록은 CycloneDX 또는 SPDX SBOM으로, 그리고 API를 통해 CRACI에서 내보낼 수 있으며, API는 SBOM, 네트워크 추적, 출처 증명 데이터를 반환합니다. 감사 측면은 SOC 2를 위한 SBOM 점검을 확인하세요. 고지문이나 전문 검토처럼 선언된 라이선스를 넘어서는 라이선스 업무는 오픈소스 라이선스 컴플라이언스를 확인하세요. CRACI는 각 구성 요소의 선언된 라이선스를 담고, 라이선스를 이유로 빌드를 차단하는 것을 포함해 라이선스 정책 규칙을 강제합니다.
자사 스택에서 대체 지점을 찾는 방법
오후 한나절이면 답할 수 있는 다섯 가지 질문입니다. 각 답을 보면 스택의 어떤 줄이 옮겨 가는지 알 수 있습니다.
- 빌드가 Linux의 GitHub Actions에서 실행되나요? 그렇다면 러너가 옮겨 갑니다. 아니라면 현재 CRACI가 대체하는 것은 없습니다.
- 지금 누가 SBOM을 생성하고, 서로 다른 생성 도구를 몇 개나 쓰고 있나요? CRACI로 옮기는 리포지토리의 생성 도구는 하나하나 빠지는 줄입니다.
-
Yocto 이미지를 빌드하나요? 그렇다면 끄기 전에
create-spdx출력의 적용된 패치와 수정된 CVE에 의존하는 사람이 있는지 확인하세요. - 생성된 SBOM은 어디로 가나요? 추적 도구, 스프레드시트, 아니면 아무 데도 가지 않나요? 그 도구나 프로세스가 두 번째로 빠지는 줄입니다. 단, 거기서 도달 가능성이나 수정 지표가 필요하다면 예외입니다.
- 보안 도구 중 코드, 리포지토리, 서드파티 바이너리를 읽는 것은 무엇인가요? 그것들은 남습니다. CRACI가 대체하리라고 아무도 기대하지 않도록 적어 두세요.
실제 적용 예시
실제 기업에 기반하지 않은 설명용 기기 제조사의 예입니다. Linux 빌드는 GitHub 호스팅 러너에서 실행되고, 두 팀이 서로 다른 SBOM
생성 도구 두 개를 쓰며, Yocto 제품군에서는 create-spdx가 켜져 있고, SBOM은 공유 스프레드시트에 모이며, 코드 스캔
제품군과 티켓 관리 시스템이 있습니다. 보안팀은 질문 1과 3에 "예"라고 답하고, 질문 2에서 생성 도구 두 개, 질문 4에서
스프레드시트를 찾으며, 질문 5에는 코드 스캔, 시크릿 스캔, 티켓 관리 시스템을 적습니다. Yocto SPDX의 패치 메타데이터는 아무도
쓰지 않습니다.
| CRACI로 옮겨 가는 것 | 남는 것 |
|---|---|
| Linux 작업용 GitHub 호스팅 러너 | 코드 스캔(CRACI 러너에서 단계로 실행) |
| 두 SBOM 생성 도구 | 시크릿 스캔 |
create-spdx(패치 메타데이터가 필요한 사람이 없으므로) |
티켓 관리 시스템 |
| SBOM 스프레드시트 |
러너 줄에서는 GitHub 호스팅 2코어 x64 러너에서 $0.060이 드는 10분짜리 빌드가 속도 향상 덕분에 CRACI에서는 약 $0.020입니다. 다른 도구의 비용은 그 회사가 직접 채워 넣을 부분입니다.
CRACI가 답이 아닌 경우
- 파이프라인이 GitLab CI, Jenkins, Azure DevOps 또는 다른 CI 시스템에서 실행되는 경우. CRACI는 현재 GitHub Actions만 지원하며 GitLab CI와 Jenkins는 로드맵에 있으므로, 아직 대체하는 것이 없습니다.
- 빌드에 Windows나 macOS 러너 또는 GitHub Enterprise Server가 필요하거나, 자체 인프라에서 실행해야 하는 경우.
- 주된 고민이 자사 코드의 코드 스캔에서 나오는 노이즈인 경우. 그것은 SAST 튜닝 문제입니다. SAST와 SCA 비교와 취약점 노이즈를 줄이는 방법을 확인하세요.
- 주된 위험이 직접 빌드하는 코드가 아니라 공급업체에서 받는 펌웨어와 바이너리인 경우.
- 스택의 대부분이 Java와 Maven(로드맵에 있음)이거나, .NET(CRACI가 기록하는 에코시스템 목록에 없음)인 경우.
- 도달 가능성 기반 우선순위 지정이나 PSIRT 사례 관리가 지금 당장 필요한 경우.
제품을 단계별로 보려면 CRACI 작동 방식을, SBOM 자체는 SBOM 생성을 확인하세요.
CRACI가 대체하는 것: 자주 묻는 질문
CRACI는 무엇을 대체하나요?
Linux 작업용 GitHub Actions 러너, CRACI로 옮기는 빌드에 대해 팀이 CI에서 실행하는 SBOM 생성 도구, 공급망 커버리지를 위한 Yocto의 create-spdx, 러너의 이그레스 에이전트, 그리고 그 빌드에 대한 독립형 SBOM 기반 취약점 추적입니다. 코드, 리포지토리, 서드파티 바이너리를 읽는 도구는 대체하지 않습니다.
CRACI는 SCA 도구의 애드온인가요, 아니면 무언가를 대체하나요?
빌드 계층의 작업을 대체합니다. 러너, SBOM 생성, 그리고 SBOM에서 이어지는 추적입니다. 그것이 SCA 도구를 대체하는지는 SCA 도구를 어디에 쓰는지에 달려 있습니다. 코드를 읽거나, 스니펫 또는 바이너리 분석을 하거나, 도달 가능성 분석을 제공한다면 그 부분은 남습니다.
CRACI에서 빌드를 실행해도 SBOM 생성 도구가 여전히 필요한가요?
CRACI에서 실행되고 CRACI가 기록하는 에코시스템을 쓰는 빌드에는 필요 없습니다. CRACI는 각 작업이 가져온 패키지를 기록하고 SBOM을 CycloneDX 또는 SPDX로 내보냅니다. 풀하는 이미지처럼 CRACI에서 빌드하지 않는 소프트웨어와, Maven처럼 CRACI가 아직 기록하지 않는 에코시스템에는 생성 도구를 유지하세요.
Yocto 내장 SBOM 생성(create-spdx)이 여전히 필요한가요?
공급망 커버리지에는 필요 없습니다. core-image-sato를 나란히 빌드한 비교에서 CRACI의 SBOM에는 Yocto SBOM의 모든 구성 요소와 함께 Yocto가 놓친 88개가 더 있었고, create-spdx 없이 실행한 빌드는 시간이 43% 적게 걸렸습니다. CRACI가 기록하지 않는 적용된 패치와 수정됨으로 표시된 CVE에 의존한다면 create-spdx를 켜 두세요.
CRACI가 코드 스캔이나 시크릿 스캔을 대체하나요?
아니요. CRACI는 소스 코드나 커밋을 읽어 결함이나 시크릿을 찾지 않습니다. 그 도구들은 유지하세요. 코드 스캔 단계는 CRACI 러너의 워크플로에서 그대로 실행되고, 리포지토리 수준 기능은 영향을 받지 않습니다.
CRACI가 바이너리나 펌웨어 분석을 대체하나요?
아니요. CRACI는 자신이 실행하는 빌드를 기록합니다. 공급업체에서 받는 펌웨어와 바이너리에는 바이너리 분석이 알맞은 도구입니다. 공급업체가 SBOM을 제공하면 CRACI는 자체 빌드와 함께 그것을 모니터링할 수 있습니다.
CRACI 러너에서도 GitHub Actions의 기존 보안 단계를 유지할 수 있나요?
네. CRACI가 대체하는 것은 러너이며 GitHub Actions가 아닙니다. runs-on을 craci로 설정하면 워크플로, 단계, 결과는 GitHub에 그대로 남습니다. 스캔 단계, 테스트 단계, 그 밖의 모든 단계가 이전처럼 계속 실행됩니다.