セキュリティ制御は、それが保護すべきソフトウェアサプライチェーンほどのスピードでは進化しません。部分的な自動化は、チームやリリースパイプラインごとに不均一なポリシー適用を生み出し、そのばらつきが完全性の低下を招きます。

デジサートのState of Software Supply Chain Security 2026レポートは、明確な傾向を示しています。多くの組織は自らを成熟していると感じているものの、完全性を証明するための制御は依然として一貫性がなく、手作業に依存しています。コード署名を完全に自動化している組織はわずか 13% であり、すべてのプロジェクトでセキュリティチェックを完全自動化している組織も 13% に過ぎません。

これは、より大きなストーリーの次の章です。ポリシーや意図は重要です。しかし、セキュリティをリリーススピードに対応した形で現実のものにするのは自動化です。

なぜ部分的な自動化は成熟の証ではなくセキュリティ上の問題なのか

部分的な自動化は進歩しているように見えます。しかし実際には、不均一なポリシー適用を生み出します。

あるパイプラインでは定期的にコード署名が行われる一方で、別のパイプラインでは署名なしでリリースが行われます。ある製品ラインではビルドごとに SAST、DAST、SCA が実行される一方で、別の製品ラインでは「時間があるときだけ」実施されます。あるコンテナワークフローではイメージ署名がデフォルトで行われますが、別のワークフローでは担当者の経験や知識に依存しています。

State of SSC レポートは、この現実を数値で示しています。71% の組織が、セキュリティチェックは部分的な自動化またはアドホックな運用に留まっていると回答しています。

これは単なるツールの問題ではありません。ポリシー適用の問題です。攻撃者はすべてのパイプラインへ侵入する必要はありません。最も脆弱な1つを見つければ十分です。

自動化はポリシーと証明を結ぶ架け橋

自動化は標準をデフォルト動作へ変えます。セキュリティは次のようになります。

• パイプラインによって自動的に適用されることで一貫性を持つ
• プロセスが自動的に証跡を生成することで監査可能になる
• 個人の行動に依存しなくなることでスケールする

そのため、自動化は本レポートでも中心的な推奨事項として位置付けられています。署名、脆弱性スキャン、SBOM 生成の自動化を含め、規制要件が発効する前に自動化ギャップを解消する必要性が明示されています。

ポリシーは何が行われるべきかを定義します。自動化は、それが常に実行されることを保証します。

自動コード署名を「中核となる制御」にする

完全性を支える自動化投資を1つ選ぶなら、まず署名から始めるべきです。コード署名は単なるチェックボックスではありません。来歴を証明し、改ざんリスクを低減する重要な制御です。

しかしレポートによると、完全実装は依然としてまれです。コード署名を完全自動化している組織はわずか 13% であり、89% の組織には強制適用される正式なコード署名ポリシーが存在しません。その結果、署名されていないリリースや鍵管理ミスが発生する可能性が高まっています。

現実的なアプローチは次のとおりです。

• まず署名ポリシーを定義する。 一貫性のない状態を自動化してはいけません。
• CI/CD において署名を必須にする。 リリースゲートとして扱います。
• 鍵を保護する。 HSM やマネージド KMS、シークレットボルトに格納します。
• ワークフローを計測する。 監査対応に必要な証跡を自動収集します。

DigiCert Software Trust Manager のようなツールは、CI/CD と整合性の取れた形で、証明書、鍵、ポリシー適用を管理しながら署名ワークフローの運用を支援します。

1つではなくチェーン全体を自動化する

自動コード署名は中核となる制御です。しかし、他のセキュリティ工程にばらつきがあると完全性は損なわれます。

State of SSC レポートは、周辺制御にも同様の不整合が存在することを示しています。

• セキュリティチェック： 完全自動化は 13%、71% は部分的またはアドホック
• SBOM： 現在積極的に提供しているのはわずか 11%
• SBOM 署名： 常に署名しているのは 17%
• コンテナ署名： 常にコンテナイメージへ署名しているのは 12%

これらは独立したギャップではなく、相互に影響します。署名されていない成果物は信頼しにくく、署名されていない SBOM は検証しにくくなります。そして「署名されているかもしれない」リリースは、監査で防御することが困難です。

真の障壁は実行上の摩擦である

多くの組織を阻んでいるのは意図ではなく実行です。State of SSC レポートでは次の課題が挙げられています。

• 55%：予算不足
• 55%：社内専門知識の不足
• 53%：統合の複雑さ
• 41%：開発者の抵抗

これらは現実的な制約です。同時に、「部分的な自動化」が標準状態になっている理由でもあります。興味深いのは、38% の組織が自動化や統合機能の改善によってセキュリティ態勢が向上すると回答している点です。これは、ダッシュボードの追加ではなく、手作業の削減が求められていることを示しています。

リリースを妨げない現実的な自動化チェックリスト

リリースサイクルを遅らせることなくポリシー適用を強化したい場合は、次の順序で進めてください。

1. ポリシーに基づく制御を1つ導入する： 自動コード署名をデフォルトのリリース要件にする。
2. セキュリティチェックを一貫して自動化する： 「一部のプロジェクト」から「すべてのパイプライン」へ移行する。
3. CI/CD における SBOM 生成を自動化する： 手作業を減らし、一貫性を向上させる。
4. SBOM 署名を必須にする： 完全性には主張ではなく証明が必要です。
5. コンテナにも署名を拡張する： 現代的なデリバリーにおいて、現代的な完全性制御を欠かさない。
6. 自動化カバレッジを測定する： 後付けではなく先行指標として扱う。

このアプローチは、レポートが示す「リーダー企業と後進企業」の違いとも一致します。リーダー企業は包括的な自動化、鍵保護、開発ワークフローへのセキュリティ組み込みを実現しています。一方、後進企業は取り残されます。

自動化こそが完全性を再現可能にする

多くの組織は、ガバナンス、脆弱性管理、コンプライアンス対応を優先しています。これらはすべて重要です。しかし State of SSC レポートは、CI/CD セキュリティ自動化の優先順位が、その重要性に比べて低いことも示しています。

プログラムが善意や努力に依存している限り、その結果は常に不均一になります。プログラムが自動化に依存しているなら、一貫性は自然についてきます。

調査結果と推奨事項の詳細については、デジサートのState of Software Supply Chain Security 2026レポートをご覧ください。