CVE公表数は1ヵ月に1万件──フロンティアAI時代のセキュリティ課題にデジタル庁はどう向き合うか

【GitLab Epic Tour Japan 2026】デジタル庁 GCAS DevStack：フロンティア AI 時代のセキュリティ課題に応える能動的ガバナンス

インフラはクラウドで守り、アプリケーションは自分たちで守る

　山本氏が示した方向は、守る層を二つに分ける構造だった。インフラ層はクラウドで保護し、アプリケーション層はGitLabで統制する。

　インフラについての提案は率直だ。まずクラウドに上げて、パッチ管理から解放されること。クラウド事業者は、脆弱性が公表されるタイミング、あるいはその前のタイミングでパッチを当てているからこそ、人手では手が届かない攻撃を防ぐこともある。

インフラ層はクラウドで保護し、アプリケーション層はGitLabで統制する二層構造

　一方で、アプリケーションは自分たちで開発し運用する以上、自分たちで守るしかない。そのための仕組みがGCAS DevStackである。4年前に始まったガバメントクラウドのサービス群のうち、開発と運用のフェーズを担う。

　中身はGitLabのレポジトリとCI/CDパイプラインだ。設計の要点は、そのパイプラインの中でガバメントクラウドチーム側から強制的にセキュリティチェックをかけられること、そしてそれが「レポジトリのオーナー、GitLabプロジェクトのオーナーでも解除できない形」になっていることだ。ソフトウェア部品表であるSBOMの生成も同じように標準適用される。

「運用ルール」ではなく「システム設定」として自動適用

　技術的ガバナンスの3本柱は「ソースコードの一元管理と変更追跡」「継続的検査とShift-Left」「インフラのコード化と一体管理」だ。

　1本目の「ソースコードの一元管理と変更追跡」は、作業ブランチで開発しmainには直接プッシュさせず、マージのタイミングで必ずレビューと承認を入れる設計で構築している。重要な点は、これらを「運用ルール」ではなく「システム設定」として自動適用する点だ。一部、現在は自動適用までは至っていない項目があるものの、「必須化は今後の検討課題」と山本氏は意欲を示す。

CI/CDパイプラインに組み込む継続的検査とShift-Left

　2本目の柱である「Shift-Left」では、マージリクエストを作るとチェックが走り、セキュリティ上の指摘がマージリクエストの中に出てくる。ただし現在のところ、マージとデプロイのブロックまでは踏み込めていない。この点は、利用者と相談しながら最適な形を探る姿勢だ。

CI/CDパイプラインに組み込む継続的検査とShift-Left

　指摘が出た後は、AIコーティングと接続し迅速な修正が走る。具体的には、GitLabの画面でセキュリティ項目を開くとIssueを作成するボタンが現れ、そのIssueをAIに参照させて修正を指示すると修正コードが出てくる。これを繰り返せば、リリース前に指摘項目を潰し込める。このスピード感は、脆弱性の公開後すぐに攻撃が始まるようになったAI時代に必要なものだ。

　依存関係リストも同じタイミングで自動生成され、公開済みの脆弱性に該当するライブラリとバージョンが使われていればリスクが表示される。ただし、この仕組みには議論が必要だと山本氏自身は指摘する。

　この仕組みを構築した際、リリース頻度は月1回程度を想定していた。メンテナンスなどで月1回はチェックが回り、その間に公開された脆弱性は反映される。そう考えて組んでいたのだ。しかし、状況は変わっている。「ここ最近では、1カ月も待っていられない状況になってきました」。依存関係リストの生成をどの頻度で回すか。利用者が設定すれば変えられるが、管理側としても再考が必要だと山本氏は話した。

　3本目のIaCも同じ仕組みに乗っている。TerraformやCDKでインフラを構成していれば、アプリケーションと同じ承認フローと同じ検査を通すことが可能だ。実際に、山本氏自身も1ユーザーとしてDevStackを使った際には、例えばバケットのログが取れていないといった指摘を受け取った。