2026년 하루 평균 보고된 CVE가 전년 대비 131% 증가했습니다.

플랫폼

CRACI 작동 방식

CRACI는 GitHub Actions 빌드를 실행하고 각 빌드가 가져오는 항목을 기록합니다. 취약점 추적부터 CRA 증거까지 나머지 모든 기능은 이 기록을 바탕으로 합니다.

업데이트

CRACI 플랫폼 개요. GitHub의 소스 코드가 GitHub Actions를 거쳐 CRACI Secure Build Service로 흐릅니다. 빌드는 CRACI Package Analytics로 이어지고, 이어서 Vulnerability Analysis(서드파티 공급업체의 입력도 받음), Digital Inventory, Compliance Reporting으로 이어지며, Compliance Reporting은 고객, 공급업체, ENISA 같은 제3자에게 보고합니다. 빌드는 CRACI Attack Prevention으로도 이어집니다. Attack Prevention과 Digital Inventory는 모두 스테이징 및 프로덕션 배포로 연결됩니다. Vulnerability Analysis는 분류된 발견 사항을 귀사의 팀에도 전달하며, 팀이 수정을 진행합니다. 수정된 릴리스는 GitHub를 거쳐 다시 빌드되고 추적됩니다.
왼쪽에서 오른쪽으로 본 CRACI 플랫폼. 전체 크기 다이어그램 열기.

요약

대부분의 보안 도구는 사후에 코드나 매니페스트를 보고 빌드에 무엇이 들어 있었을지 추론합니다. CRACI는 빌드 러너이므로 빌드가 실제로 가져온 항목을 가져오는 그 순간에 봅니다. 이 기록이 다이어그램의 모든 요소, 즉 패키지 분석, 공격 방지, 취약점 분석, 추적성, 컴플라이언스 보고의 입력이 됩니다.

GitHub와 GitHub Actions는 그대로 사용합니다. 변경 사항은 각 워크플로의 한 줄뿐입니다.

Switching a GitHub Actions job to CRACI A workflow file with a build job. The line runs-on: ubuntu-latest changes to runs-on: craci. That is the only change, and the job's runs still show up in GitHub. .github/workflows/build.yml jobs: build: runs-on: ubuntu-latest ubuntu-lates ubuntu-late ubuntu-lat ubuntu-la ubuntu-l ubuntu- ubuntu ubunt ubun ubu ub u c cr cra crac craci ✓ One line per job. Runs still show up in GitHub.

단계별 설명

1. 소스 코드와 CI/CD: GitHub와 GitHub Actions

코드는 GitHub에 그대로 둡니다. CRACI GitHub App을 모든 리포지토리 또는 선택한 리포지토리에만 설치해 조직을 연결합니다. 워크플로는 계속 GitHub Actions에서 실행되고 실행 내역도 GitHub에 그대로 표시됩니다. 현재 지원되는 CI 통합은 GitHub Actions이며, 다른 CI/CD 시스템 지원은 로드맵에 있습니다.

2. 빌드: CRACI Secure Build Service

작업은 CRACI 러너의 격리된 가상 머신에서 실행됩니다. 러너는 네이티브 x86-64와 ARM64에서 1~32 컴퓨팅 유닛(유닛당 1 vCPU, 3 GB RAM)으로 확장되며, GitHub 호환 Ubuntu 이미지 또는 CRACI의 경량 이미지를 사용합니다. 사용량은 초 단위로 측정됩니다.

CRACI에서의 빌드는 GitHub 표준 호스팅 러너보다 약 2배 빠르게 실행됩니다. 분당 비용도 더 저렴합니다. 표준 2 vCPU Linux 러너가 분당 $0.004로, GitHub의 $0.006보다 약 33% 저렴합니다. 이를 합하면 GitHub에서 10분 걸리는 빌드가 CRACI에서는 약 5분 만에 끝나고 비용은 약 67% 줄어듭니다. 또한 CRACI는 각 작업을 1분 단위로 올림하지 않고 초 단위로 과금하므로, 짧은 작업이 많은 파이프라인일수록 더 많이 절약됩니다. GitHub 호스팅 러너와의 전체 비교 보기.

One 10-minute build, GitHub-hosted runner versus CRACI On a GitHub-hosted 2-core Linux runner, a 10-minute build at $0.006 per minute costs $0.060, and each job is rounded up to a whole minute. On CRACI, the same build takes about 5 minutes at $0.004 per minute and costs $0.020, billed per second. That is about 67 percent less. GitHub-hosted runner standard 2-core Linux x64 build time 10 min per minute $0.006 cost of the build $0.060 CRACI size 2, Linux x64 build time about 5 min per minute $0.004 cost of the build $0.020 About 2x faster and about 67% less per build Billed per second; GitHub rounds jobs up to a minute.

3. 공급망 탐색: CRACI Package Analytics

작업이 실행되는 동안 패키지를 인식하는 프록시가 패키지 소스로 가는 트래픽을 관찰하고, 빌드가 가져오는 모든 외부 종속성을 기록합니다. npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk, Git 소스와 Yocto 및 OpenEmbedded 다운로드 프리셋을 지원합니다. 증거가 CI 캐시와 함께 전달되므로, 캐시에서 복원된 패키지도 빠짐없이 반영됩니다.

이것이 다른 SBOM 도구와의 차이입니다. 다른 도구는 잠금 파일이나 빌드 출력물을 읽고 무엇이 들어갔는지 추정합니다. CRACI는 트래픽을 보기 때문에 어떤 잠금 파일에도 나오지 않는 숨은 종속성까지 기록합니다. npm install 훅이 내려받는 코드, Rust 빌드 스크립트가 빌드 시점에 가져오는 파일, 컨테이너 빌드의 베이스 이미지 레이어가 그 예입니다.

How a scanned SBOM and a recorded SBOM are made Left, a scanner: it reads the lockfile after the build, which lists packages A to E, so its SBOM contains A to E. The build also fetched code through an install hook, a build script download and a base image, which are in no lockfile, so the scanned SBOM is missing them. Right, CRACI: it sees the traffic coming into the build, so all eight packages, including the three hidden dependencies, land in the recorded SBOM. Scanner reads files after the build package-lock.json A B C D E the build also fetched install hook download build script download base image layers in no lockfile, so the scan never sees them Scanned SBOM A B C D E missing missing missing CRACI sees the traffic into the build the network build job on CRACI every package that comes in Recorded SBOM A B C D E install hook build script base image hidden ones too
A scanner can only list what the lockfile or the output declares. CRACI sees what actually came into the build, including the hidden dependencies.

각 작업과 캐시에는 Complete부터 Not recorded까지의 완전성 상태가 부여되므로, 생성된 SBOM을 어느 정도까지 신뢰할 수 있는지 알 수 있습니다. SBOM은 전이적 종속성을 포함해 CycloneDX 또는 SPDX로 내보낼 수 있습니다.

4. 지속적인 공급망 보안: CRACI Attack Prevention

트래픽을 기록하는 바로 그 계층이 트래픽을 통제하기도 합니다. 이그레스 정책은 작업이 접근할 수 있는 호스트를 결정하며, 기본 거부 또는 기본 허용, 일반적인 소프트웨어 소스를 위한 기본 제공 프리셋, 자체 소스를 위한 사용자 지정 규칙을 지원합니다. 정책은 작업 시작 전에 검증되고 실패 시 차단되며, 위반이 발생하면 CRACI가 알림을 보냅니다. 침해된 종속성이나 빌드 도구가 외부와 통신하려 하면 러너에서 차단됩니다.

정책은 알려진 악성 호스트를 찾는 대신 빌드에 필요한 것만 허용하므로, 아무도 본 적 없는 공격에도 효과가 있습니다. Shai-Hulud 같은 웜이 먼저 빌드에 도달하더라도, 시크릿을 외부로 보내려는 시도는 똑같이 차단됩니다.

What happens when malware in a build tries to send your secrets out Left, a runner that allows all outbound traffic: the build reaches its package registry and publishes its output, then a malicious install hook sends the build's secrets to an attacker's server, and they arrive. Right, CRACI with a default-deny egress policy: the registry and publish connections are allowed, the connection to the attacker's server is blocked at the policy, and an alert is sent. The policy allows only what the build needs, so it works even against an attack nobody has seen before. Any outbound allowed build job holds your tokens and keys malicious install hook runs no egress policy package registry publish output attacker server allowed allowed secrets sent to the attacker CRACI default-deny egress policy build job on CRACI holds your tokens and keys malicious install hook runs egress policy: only what the build needs package registry publish output attacker server allowed allowed blocked blocked, and you get an alert
The policy allows only what the build needs, instead of looking for known-bad hosts, so it stops a new attack the first time it runs.

5. 지속적인 공급망 대응: CRACI Vulnerability Analysis

기록된 패키지는 알려진 취약점과 매칭되고, 모니터링 중인 SBOM은 지속적으로 재평가되므로 출시 후에 공개된 취약점도 놓치지 않습니다. 조직 수준의 뷰는 어떤 빌드와 리포지토리가 취약한 종속성을 공유하는지 보여 주며, 보안 팀은 각 발견 사항을 분류해 수정을 담당하는 팀에 보낼 수 있습니다. 서드파티 공급업체의 SBOM도 추가할 수 있으므로, 외부에서 구매한 구성 요소도 자체 빌드가 가져오는 구성 요소와 함께 모니터링됩니다.

Using SBOMs for improved cybersecurity

빌드 시점 SBOM이 출시 후 취약점 모니터링으로 이어지는 방식으로, CRACI의 SBOM 생성과 취약점 추적이 하는 일입니다.

Kubernetes Community Days Helsinki 2026의 Petteri Pulkkinen 및 Erika Marttinen, SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains 중 22:11~23:27.

6. 공급망 추적: CRACI Digital Inventory

모든 빌드에는 SBOM과 연결 대상의 네트워크 추적이 있으며, CRACI API는 SBOM, 네트워크 추적, 출처 증명을 반환합니다. 새로운 취약점이나 침해된 패키지가 뉴스에 오르면, 어떤 빌드가 영향을 받는지 한곳에서 답할 수 있습니다.

A new vulnerability, traced back through build history Eight releases, v1.0 to v1.7, are built and recorded over time. Today a new advisory is published for example-lib 2.3.1. CRACI's build history shows that v1.2 and v1.3 contained it as a transitive dependency and v1.4 and v1.5 as a direct one, while v1.6 and v1.7 already shipped a fixed version. The exposure period is v1.2 to v1.5, answered from the recorded SBOMs without rescanning old code. Build history every build keeps its recorded SBOM New advisory today example-lib 2.3.1 today v1.0 v1.1 v1.2 v1.3 v1.4 v1.5 v1.6 v1.7 v1.2 transitive v1.3 transitive v1.4 direct v1.5 direct fixedfixed exposure period: v1.2 to v1.5 Answered from the recorded SBOMs, without rescanning old code
CRACI keeps re-evaluating the SBOMs of what you shipped. Build history follows your retention, 180 days by default.

7. 공급망 보고: CRACI Compliance Reporting

그 과정에서 수집된 증거는 이를 요청하는 고객, 공급업체, 당국에 전달됩니다. SBOM은 구성 요소에서 발견된 취약점을 포함해 CycloneDX 또는 SPDX로 내보낼 수 있고, API는 SBOM, 네트워크 추적, 출처 증명을 반환하며, CRACI가 귀사가 제출할 CRA 취약점 통지의 내용을 준비합니다.

그 배경에 있는 가장 잘 알려진 규정은 EU Cyber Resilience Act이지만, 유일한 규정은 아닙니다. 프레임워크가 달라도 요구 사항은 같습니다. 소프트웨어에 무엇이 들어 있는지 알고, 그 취약점을 찾아 처리하는 프로세스를 갖추는 것입니다.

  • EU Cyber Resilience Act: EU에서 판매되는 디지털 요소를 포함한 제품에 대한 SBOM과 취약점 처리, 2026년 9월부터 보고 의무 적용.
  • NIS2: 필수 기관과 중요 기관의 공급망 보안, 취약점 처리 및 공개.
  • ISO/IEC 27001: SBOM을 명시하지는 않지만, 부속서 A 통제는 자산 목록(5.9), ICT 공급망 보안(5.21), 기술적 취약점 관리(8.8)를 요구합니다. 빌드 시점 SBOM과 지속적인 모니터링은 세 가지 모두의 증거가 됩니다. 컴플라이언스 증거로서의 SBOM을 참조하세요.
  • US FDA: 커넥티드 의료기기의 시판 전 제출 자료에 SBOM 포함, 출시 후 취약점을 모니터링하고 대응하는 계획.
  • US Executive Order 14028: 연방 정부에 판매하는 공급업체를 위한 소프트웨어 공급망 지침에서 제품별 SBOM과 취약점 공개 프로세스.

CRACI는 이들 프레임워크가 기대하는 SBOM과 지속적인 취약점 모니터링, 그리고 컴플라이언스 주장을 뒷받침하는 증거를 제공합니다. 각 프레임워크를 충족하는 일은 여전히 귀사의 프로세스이며, CRACI는 그중 증거 부분을 자동화합니다.

8. 배포: 스테이징과 프로덕션

스테이징과 프로덕션에 도달하는 것은 네트워크 정책 아래에서 빌드되었고, 빌드 중에 SBOM이 기록되었으며, 출시 후에도 새로운 취약점을 모니터링하는 소프트웨어입니다.

더 알아보기

귀사의 파이프라인에서 CRACI를 확인해 보세요

데모를 예약하시면 귀사의 빌드, SBOM, 컴플라이언스 증거를 함께 살펴봅니다.

데모 예약