GitHubが、静的解析ツール CodeQL を大きくアップデートしました。今回のポイントはひとことで言うと、セキュリティのルールをコードでゴリゴリ書くのではなく、YAMLベースの「models-as-data」で宣言的に定義できるようになったことです。
これ、地味に見えてかなり重要です。なぜなら、セキュリティ分析は「精度を上げたい」と思うほど設定が複雑になりがちで、結局“わかる人しか触れない仕組み”になりやすいからです。GitHubはそこを、もっと扱いやすく、もっと広く使える形に寄せてきたわけです。
CodeQLは、ざっくり言うとソースコードを解析して、脆弱性の入り口や危険なデータの流れを見つけるための仕組みです。
人間が全部目で探すのは無理なので、「このデータはどこから来て、どこを通って、どこで危険になるのか」を追いかけます。
ここで出てくる taint tracking は、「怪しいデータの流れを追跡する」考え方です。
たとえば、ユーザー入力がそのままSQLやコマンドに流れたら危ないですよね。CodeQLはそういう流れを見つけてくれます。
ただし、現実のアプリはそんなに単純ではありません。
途中で sanitize（無害化する処理）したり、validate（正しい値か確認）したりします。
この「ここで安全になった」と判断できるかどうかが、静的解析ではとても大事です。
今回のアップデートの肝は、sanitizer と validator を、より宣言的に扱えるようになったことです。
これまでは、こうした処理をCodeQLに理解させるために、かなり専門的なクエリを書く必要があったとのことです。
つまり、「セキュリティ分析を拡張したい」だけなのに、CodeQLのクエリ言語に深く精通している必要があったわけです。これは正直、ハードルが高い。
今回の変更では、そうした知識を YAMLベースのデータ拡張 として記述できるようになりました。
GitHubはこれを models-as-data と呼んでいます。名前は少しかっこつけ感がありますが、やっていることはかなり実用的です。
要するに、コードでロジックを組むより、設定データとして安全ルールを持てるようにした、ということです。
記事では、新しく barrierModel と barrierGuardModel という拡張可能な predicate が導入されたと説明されています。
ここでの predicate は、ざっくり言えば「真偽を判定するルール」くらいに考えるとわかりやすいです。
つまり、CodeQLに「この関数は安全化ポイントですよ」と教える仕組みです。
個人的には、こういう“現場の知識をツールに渡せる”方向性はかなり良いと思います。ツールは万能ではないので、現場の文脈をどううまく注入するかが勝負だからです。
これが最大のメリットです。
従来は、CodeQLを細かく使いこなすために、かなりの専門性が必要でした。
でも今回は、宣言的に定義できるので、導入の敷居が下がります。
どの会社にも、独自のライブラリやフレームワーク、入力チェックの作法があります。
標準ルールだけでは拾えない部分を、自社の知識としてモデル化できるのは強いです。
たとえば、
こうしたものをCodeQLに教えられるようになると、誤検知を減らしつつ、本当に危ないところを見つけやすくなるはずです。
記事によると、この機能はかなり多くの言語に対応しています。
今どきの開発現場は、1つの言語だけで完結しないことが多いです。
フロントはTypeScript、APIはJava、バッチはPython、基盤はGo……みたいな構成も珍しくありません。
そういう環境で、似た安全ルールを言語ごとにバラバラ管理しなくていいのはかなり現実的です。
今回の更新は、単なる機能追加というより、セキュリティ運用の考え方の変化として見ると面白いです。
これまでのやり方は、必要なたびにロジックを書き足す「コード中心」でした。
でも今は、設定やルールをデータとして持ち、バージョン管理し、共有し、再利用する「データ駆動」に寄ってきています。
この流れ、すごく今っぽいです。
インフラがコード化され、ポリシーがコード化され、ついにはセキュリティの知識までデータ化される。
便利な反面、ツールの複雑さを人間が抱え込まなくて済む方向に進んでいるのは素直に歓迎したいところです。
ここは冷静に見ておきたいポイントです。
models-as-data が便利になっても、「ルールを登録したら全部解決」ではないはずです。
なぜなら、サニタイズやバリデーションの意味は、実装だけでなく文脈にも左右されるからです。
同じ関数名でも、呼び出し方や前提条件で安全性が変わることがあります。
なので、こうしたモデルは確かに強力ですが、最終的には人間の判断とセットで使うものだと思います。
ただ、その前提を踏まえても、今回の方向性はかなり良いです。
少なくとも、「高度すぎて使いこなせないセキュリティ基盤」から、「現場が持っている知識を載せやすい基盤」へ近づいているのは確かでしょう。
記事では、GitLab、Snyk、Semgrep などにも触れています。
ざっくり言うと、
この中で今回のCodeQLは、高度さを保ったまま、カスタマイズの敷居を下げる方向に進んだと言えそうです。
個人的には、ここがかなり面白いです。深い解析は強いけど難しい、というCodeQLの弱点にちゃんと手を入れてきた印象があります。
GitHubのCodeQLアップデートは、派手な見た目の機能ではないものの、セキュリティ分析を現場で使いやすくする大きな一歩です。
特に、custom sanitizers や validators を models-as-data で定義できるようになったのは、実務ではかなり効くはずです。
「難しいセキュリティツールを、一部の専門家だけのものにしない」
この方向性は、かなり健全だと思います。
そして何より、自社のコードのクセをツールに理解させやすくなるのは、誤検知に疲れた開発者にとって朗報ではないでしょうか。
参考: GitHub Enhances CodeQL with Declarative Security Modeling for Faster, More Flexible Analysis
