AIが書いたコードの中身、 把握できていますか？ ― CRA対応をGitLabで

GitLab EPIC Tour Japan 2026（2026年10月9日）のCommunity LTで使用した資料です。

AIがコードを書く時代、生成されたコードの中身を把握し、脆弱性に素早く対応できる体制は、規制の対象かどうかに関係なく必要になっています。本資料では、EUサイバー
レジリエンス法（CRA）の報告義務（24時間以内の早期警告ほか）を手がかりに、攻撃の速度と規制の時間軸を整理します。そのうえで、GitLabで実装・検証した結果と、す
ぐに始められる第一歩を紹介します。

■ 内容
・AI生成コードの脆弱性と、急増するCVE公開件数
・PoC公開から48時間以内に進む悪用と、CRAの「24時間」
・まず始めたいSecret Detection（Freeプランでも利用可能）
・GitLabでタグを打つと、SBOM・VEX・ビルドプロヴェナンスなどの証跡がリリースページに自動で集約される仕組み
・自動化してはいけない領域（VEXの影響判定）と、AIと人の役割分担
・Secret DetectionからDASTまで、ひとつのパイプラインで網羅するGitLabのセキュリティ機能

■ 検証の詳細（ブログ記事）
https://blog.cloud-partner.jp/cra-gitlab-ultimate-release-evidence/

Transcript

1. GitLab EPIC Tour Japan 2026 ｜ Community LT AIが書いたコードの中身、 把握できていますか？ ― CRA対応をGitLabで 規制対象でなくても、構成管理と脆弱性対応フローは必要です。 GitLabで実装・検証した結果と、手軽な第一歩を話します。 2026年10月9日（金） 中山 桂一 ｜ 株式会社キャラウェブ クラウドパートナーグループ 株式会社キャラウェブ ｜ Cloud Partner
2. 自己紹介 GitLab Champion 2026 Japan AWS Top Engineers 2026 / 2024 Tech Blog AWS Community Builder blog.cloud-partner.jp 中山 桂一 株式会社キャラウェブ クラウドパートナーグループ 副部長 認定スクラムマスター AWS・GitLab・スクラムによる クラウドインテグレーションを担当 GitLab公式ブログ寄稿 Agile Planning X @k1nakayama 株式会社キャラウェブ ｜ Cloud Partner 2
3. AIが書いたコードの中身、把握できていますか？ 44% AIによるコード生成タスクのうち 危険なセキュリティ脆弱性を含む コードを生成した割合 ほぼ100% 56% 31% 構文的に正しいコード （構文は解決済み） セキュリティ合格率 （前回55%で横ばい） 侵入経路の1位は ソフトウェア脆弱性 動くコード ≠ 信頼できるコード。AIが書いた中身を、誰かが把握しておく必要がある 出典: Veracode "2026 GenAI Code Security Report"（2026年7月28日）／ Verizon "2026 Data Breach Investigations Report" 株式会社キャラウェブ ｜ Cloud Partner 3
4. 脆弱性の母数が爆発している 7.4分に1件 CVE公開件数（年間） 96,000 2026年上半期のCVE公開 35,364件 （2025年同期 23,656件比 +49.5%） 67,000 40,000 48,185 NVDが全件分析を断念 2024年 2025年 2026年 2026年 9/18時点 年末予測 NISTは2026年4月15日、NVDをリスクベー ス運用へ移行。KEV掲載などの3カテゴリ 以外は即時には処理せず、3月1日以前の バックログは「Not Scheduled」へ 国の公式DBですら全件を捌けない ＝ 自社製品の中身は、自分で把握するしかない 出典: Jerry Gamblin "2026 Mid-Year CVE Data Review" ／ CVEForecast.org（SC World経由、2026年9月18日時点・年末予測）／ NIST "NIST Updates NVD Operations to Address Record CVE Growth"（2026年4月15日）※2024年は約40,000件、9/18時点は67,000件超 株式会社キャラウェブ ｜ Cloud Partner 4
5. 攻撃は48時間で来る 24h以内 88% 中国系アクターが重大なWebアプリ 脆弱性の公開から攻撃を開始 公開PoCがある脆弱性の悪用のうち PoC公開から48時間以内の割合 24h 48h 0h 公開 ≈ 月次パッチ運用 最大 約720h（30日） 事例: CVE-2026-31431（Linux LPE）は4月29日に公開、翌日にはPoCベースの大規模な展開を検知 月次パッチ運用では間に合わない時間軸で、攻撃は始まっている 出典: CrowdStrike "2026 Threat Hunting Report"（2026年8月3日）。88%は2026年1〜6月、公開PoCが存在する脆弱性の悪用が対象 株式会社キャラウェブ ｜ Cloud Partner 5
6. まず、ここから ― Secret Detection # .gitlab-ci.yml include: - template: Jobs/Secret-Detection.gitlab-ci.yml 1 追加はこの数行だけ 2 Freeプランでも使える 3 コミットに含まれたAPIキー・トークン等の認証情報を検知 Ultimateでなくても今日から入れられる MRで止める マージ前に気づければ、ローテーションの手間も被害も最小で済む CRAとか言う前に、 まずこれが入っていない 現場が多い 最初の一歩は Secret Detection。include 数行で、認証情報の混入を検知できる 参考: GitLab Docs "Pipeline secret detection"（Tier: Free / Premium / Ultimate） 株式会社キャラウェブ ｜ Cloud Partner 6
7. ところで、CRAとは EUサイバーレジリエンス法（CRA） Regulation (EU) 2024/2847。EU市場に出す「デジタル要素を含む製品」にサイバーセキュリティ要件を課す法律 悪用中の脆弱性を認識してからの報告義務（Article 14） 24時間以内 72時間以内 14日以内 早期警告 通知 最終報告 ※ 2026年9月11日 発効済み Article 14 報告義務 発効（既に流通している製品も対象） 2027年12月11日 全面適用（セキュアバイデザイン、CEマーキング等） EUに製品を出していない方も、次の1枚だけ見てください ※ 最終報告は是正措置の提供後14日以内。出典: Regulation (EU) 2024/2847（Cyber Resilience Act）。本資料は情報提供を目的としたもので、法的助言ではありません 株式会社キャラウェブ ｜ Cloud Partner 7
8. なぜ24時間なのか 中国系アクターが 攻撃開始 攻撃側 早期警告 CRA 同じ時間軸 PoC悪用の 88%が実行済み 0h 24h 通知 48h 72h 規制が厳しいのではなく、攻撃の速度に合わせただけ。構成情報と証跡は“事前に”揃える ※ 起点は異なる（攻撃側：脆弱性／PoCの公開、CRA：悪用中の脆弱性を認識した時点）が、求められる時間のオーダーは同じ 出典: CrowdStrike "2026 Threat Hunting Report"（2026年8月3日）／ Regulation (EU) 2024/2847 Article 14 株式会社キャラウェブ ｜ Cloud Partner 8
9. GitLabでタグを打つと、証跡が揃う build test sbom evidence release タグ v1.0.0 を打つと、リリースページに自動集約されるもの ✓ SBOM（CycloneDX統合版） ✓ 修正済み脆弱性アドバイザリ ✓ VEX（影響表明） ✓ ビルドプロヴェナンス ✓ Release Evidence ✓ セキュリティスキャン結果 ✓ 技術文書 実際のリリースページ（アセット欄・検証環境） CI設定 数十行で、リリースごとの証跡集約までは実際に動く 出典: Cloud Partner Tech Blog「CRA対応をGitLab Ultimateで試してみた ― リリースごとの証跡自動集約と、その限界」（2026年8月11日） 株式会社キャラウェブ ｜ Cloud Partner 9
10. ただし、自動化してはいけない領域がある 自動化で完結（GitLab） 人が判断する • SBOMの統合（自動検出＋台帳） • 修正済み脆弱性アドバイザリ • VEXの影響判定（not_affected / affected） • そのOSSはビルド時ツールか、出荷物に 組み込まれるか • ビルドプロヴェナンス • Release Evidence KEV / CVE比 1.4% 2026年上半期 CVE +45% に対し KEV（悪用確認済）+10% • スキャン結果の集約 AIが 一次分析 人が 最終承認 増えたのは攻撃でなく “仕分けコスト” 影響判定は人の仕事。AIで一次分析を速め、最終承認は人が担う 出典: VulnCheck "State of Exploitation 1H-2026"（2026年7月28日）／ Cloud Partner Tech Blog（2026年8月11日） 株式会社キャラウェブ ｜ Cloud Partner 10
11. GitLabなら、ここまで網羅できる 動くアプリまで Freeで今日から Secret Detection Dependency Scanning Advanced SAST DAST コミットされた 認証情報を検知 依存OSSの 既知脆弱性を検出 SBOMの素にもなる 自分たち（とAI）が 書いたコードの 脆弱性を検出 動いているアプリに 外から当てて 脆弱性を検出 落とし穴: Advanced SAST C/C++ は compile_commands.json が必要 Dependency Scanning V2 は既定でMRのみ。タグでも走らせるなら rules を上書き Secret Detectionを入口に、DASTまで同じパイプラインで広げていける ※ Secret Detection（Free以上）以外は GitLab Ultimate の機能 株式会社キャラウェブ ｜ Cloud Partner 11
12. まとめ 1 AIが書く時代、構成管理と脆弱性対応フローは 2 GitLabなら、タグを打つだけで 3 規制対象かどうかに関係なく全員に必要 証跡の集約までは実際に動く 本丸は細かい技術論ではなく 体制の確立とレスポンス対応 検証の詳細は ブログ記事へ 株式会社キャラウェブ クラウドパートナーグループ cloud-partner.jp inquiry@cloud-partner.jp ／ 03-6670-2560 株式会社キャラウェブ ｜ Cloud Partner