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 等第三方提出報告。建置結果也會送入 CRACI Attack Prevention。Attack Prevention 與 Digital Inventory 都通往預備環境與正式環境的部署。Vulnerability Analysis 也會將研判後的發現轉給您的團隊，由團隊進行修正；修正後的版本會回到 GitHub，重新建置並受到追蹤。
CRACI 平台，由左至右。 開啟完整尺寸的架構圖.

重點摘要

多數資安工具是在事後檢視您的程式碼或 manifest，推測建置可能包含了什麼。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 執行器上的隔離虛擬機器中執行。執行器可從 1 擴充至 32 個運算單位（每單位 1 vCPU 與 3 GB RAM），支援原生 x86-64 與 ARM64，並可使用與 GitHub 相容的 Ubuntu 映像檔或 CRACI 的精簡映像檔。用量按秒計費。

在 CRACI 上的建置速度約為 GitHub 標準託管執行器的兩倍，每分鐘的成本也更低：標準 2 vCPU Linux 執行器每分鐘 $0.004，GitHub 則為 $0.006（約便宜 33%）。兩者相加，在 GitHub 上需要 10 分鐘的建置，在 CRACI 上約 5 分鐘即可完成，成本約低 67%。CRACI 也按秒計費，而不是將每個作業無條件進位至整分鐘，因此由許多短作業組成的管線省得更多。 查看與 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 工具的差別。其他工具讀取 lockfile 或建置輸出，再推算出放進了什麼。CRACI 看得到流量，因此也會記錄任何 lockfile 都沒有列出的隱藏相依套件：npm install hook 下載的程式碼、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

記錄流量的同一層也負責控管流量。對外連線（egress）政策決定作業可以連線到哪些主機，可選擇預設拒絕或預設允許，並提供常見軟體來源的內建預設與適用您自有來源的自訂規則。政策會在作業開始前驗證，並採取失效即封鎖（fail closed），違規時 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 產生與漏洞追蹤所負責的工作。

Petteri Pulkkinen和Erika Marttinen 於 Kubernetes Community Days Helsinki 2026，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 漏洞通報的內容，供您提交。

Cyber Resilience Act（CRA）是其中最知名的法規，但不是唯一的一項。各框架的要求都相同：掌握您的軟體中有什麼，並建立找出與處理其漏洞的流程。

  • EU Cyber Resilience Act：要求在歐盟銷售的具數位元素產品具備 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 與法規遵循佐證資料。

預約示範