2026年に報告されたCVEは、1日あたり前年比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などの第三者に報告します。ビルドはCRACI Attack Preventionにも渡ります。Attack PreventionとDigital Inventoryはどちらもステージング環境と本番環境へのデプロイにつながります。Vulnerability Analysisはトリアージした検出結果をお客様のチームにも振り分け、チームが修正を行います。修正済みのリリースはGitHubに戻り、再ビルドされて追跡されます。
CRACIプラットフォーム（左から右へ）。 図を原寸で開く.

要点

多くのセキュリティツールは、事後にコードやマニフェストを確認し、ビルドにおそらく含まれていたものを推測します。CRACIはビルドランナーそのものなので、ビルドが実際に取得したものを、取得したその瞬間に把握できます。その記録が、図にあるすべての要素、つまりパッケージ分析、攻撃防止、脆弱性分析、トレーサビリティ、コンプライアンスレポートの入力になります。

GitHubとGitHub Actionsはそのまま使えます。変更は各ワークフローの1行だけです。

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ランナー上の分離された仮想マシンで実行されます。ランナーは1〜32コンピュートユニット（1ユニットあたり1 vCPU、3 GBのRAM）でスケールし、ネイティブのx86-64とARM64に対応し、GitHub互換のUbuntuイメージまたはCRACIの軽量イメージを使用します。使用量は秒単位で計測されます。

CRACIでのビルドは、GitHubの標準ホストランナーと比べて約2倍の速さで実行されます。1分あたりのコストも低く、標準的な2 vCPUのLinuxランナーはGitHubの$0.006に対して1分あたり$0.004です（約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、ネットワークトレース、来歴を取得できます。新たな脆弱性や侵害されたパッケージがニュースになったとき、どのビルドが影響を受けているかを1か所で答えられます。

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、ネットワークトレース、来歴を取得でき、お客様が提出するCRAの脆弱性通知の内容をCRACIが準備します。

その背景にある規則として最もよく知られているのはCyber Resilience Actですが、それだけではありません。どのフレームワークでも求められることは同じです。ソフトウェアに何が含まれているかを把握し、その脆弱性を発見して対処するプロセスを持つことです。

  • 欧州サイバーレジリエンス法（CRA）：EUで販売されるデジタル要素を含む製品について、SBOMと脆弱性への対処を求め、2026年9月から報告義務が始まります。
  • NIS2：必須事業体および重要事業体に対し、サプライチェーンのセキュリティと、脆弱性の対処および開示を求めます。
  • ISO/IEC 27001：SBOMを名指ししてはいませんが、附属書Aの管理策は資産目録（5.9）、ICTサプライチェーンにおけるセキュリティ（5.21）、技術的脆弱性の管理（8.8）を求めています。ビルド時SBOMと継続的な監視は、この3つすべてのエビデンスになります。コンプライアンスのエビデンスとしてのSBOMをご覧ください。
  • 米国FDA：コネクテッド医療機器の市販前申請にSBOMを求め、リリース後に脆弱性を監視し対処する計画も求めています。
  • 米国大統領令14028：連邦政府に販売するベンダー向けのソフトウェアサプライチェーンに関するガイダンスで、製品ごとのSBOMと脆弱性開示プロセスを求めています。

CRACIは、これらのフレームワークが想定するSBOMと継続的な脆弱性監視、そしてコンプライアンス上の主張を裏付けるエビデンスを提供します。各フレームワークへの準拠は引き続きお客様のプロセスですが、そのうちエビデンスの部分はCRACIが自動化します。

8. デプロイ：ステージングと本番

ステージング環境と本番環境に届くものは、お客様のネットワークポリシーのもとでビルドされ、ビルド中に記録されたSBOMを持ち、リリース後も新たな脆弱性について監視されています。

さらに詳しく

自社のパイプラインでCRACIをご覧ください

デモをご予約いただければ、貴社のビルド、SBOM、コンプライアンスのエビデンスを一緒に確認します。

デモを予約