【ITニュース解説】A security checklist my coding agent has to run

システムエンジニアを目指す上で、ソフトウェアのセキュリティは避けて通れない重要なテーマだ。しかし、これまでのセキュリティチェックリストには、開発者が実際にセキュリティ対策を講じるのを妨げる大きな問題点があった。それは、ほとんどのチェックリストが「～であるべきだ」という理想的な状態を宣言する形で書かれていたことだ。例えば、「パスワードが変更されたらセッションは無効化されるべきだ」という項目があったとする。これは正しい内容だが、これを読んだ開発者は「なるほど、そうあるべきだ」と理解し、納得するだけで、実際にその機能が正しく実装されているかを確認する具体的な行動を促されなかった。開発者は項目に同意するだけで、チェックボックスに印をつけて先に進んでしまいがちだ。しかし、この「同意」は、本当にシステムが安全であることの保証にはならない。もし実装に問題があったとしても、それに気づかないまま開発が進んでしまうという根本的な失敗のパターンがそこにはあった。

この状況を改善するため、ある開発者が全く異なるアプローチでチェックリストを書き換えた。新しいチェックリストは、「～であるべきだ」という宣言的な記述ではなく、「～という手順を実行し、その結果が～であることを確認する」という、具体的な検証ステップと期待される結果を明記する形式になっている。これにより、単なる「確認事項のリスト」ではなく、実際に「テスト」として機能するツールに生まれ変わったのだ。この変更がもたらす最も重要な違いは、実際にその手順を実行することで、期待通りの結果が得られるか、あるいは失敗する可能性があることだ。失敗する可能性があるということは、そこに問題が存在し、それを発見できるということになる。

具体例を見てみよう。一般的なチェックリストにあった「パスワード変更時にセッションが無効化されることを検証する」という項目は、次のように書き換えられた。「パスワードが変更またはリセットされた際には、現在のセッションだけでなく、ユーザーが持つすべての有効なセッションを強制的に終了させる必要がある。これは、既に有効なセッションを持っている可能性のある攻撃者をシステムから確実に排除するためだ。この機能を実現するために、システムは各ユーザーの『セッション有効開始日時』を記録し、この日時よりも前に発行されたセッションはすべて無効と判断して拒否するように実装する。そして、この機能を検証するためには、二つの異なるブラウザで同じアカウントを使ってログインし、そのうちの一つのブラウザでパスワードを変更する。パスワード変更後、もう一方のブラウザをリロードし、そのブラウザのセッションが強制的に無効化され、アクセス拒否（HTTPステータスコード401など）が発生することを確認する。」

この新しい記述は、開発者が何をすべきか、そしてその結果として何が起こるべきかを明確に示している。この手順はわずか数十秒で実行でき、パスワード変更時のセッション無効化機能が実際に動作しているかをテストできる。もし二つ目のブラウザがまだログイン状態のままであれば、その機能は正しく実装されていないとすぐに判明するだろう。このように「実行して、期待する結果が得られない（つまり失敗する）可能性がある」という点が、従来のチェックリストと、この新しい「テスト」としてのチェックリストの決定的な違いなのだ。

このアプローチは、すべてのセキュリティ項目に適用されている。各コントロールには例外なく一つの検証ステップが伴い、そのステップが実行され、約束された結果を返すまで、コントロールは完了したとは見なされない。例えば、「セキュリティプロトコル」というカテゴリには44個のセキュリティコントロールがあり、それぞれに44個の検証ステップが用意されている。これらの数の一致は、自動化されたスクリプトによって常にチェックされる。もしコントロールの数と検証ステップの数が一致しない場合や、一つのコントロールに複数のステップがあるなどの不整合があれば、システムはエラーを報告する。この自動チェックは、開発者がGitHubのようなコード管理システムに新しい変更を提案する際（プルリクエスト時）に実行され、問題があればその変更は承認されない仕組みになっている。

この新しいチェックリストは、単なる「ドキュメント」としてではなく、「スキル」として位置づけられている。ドキュメントは、通常、コードがある程度書かれた後や、問題が発覚したときに初めて読まれることが多い。しかし、その段階でセキュリティ上の問題が見つかると、コードの書き直しが必要となり、開発の締め切りに影響を与えるなど、大きなコストがかかってしまう。これに対し、コードを一行も書く前に同じセキュリティ上の問題が考慮されれば、それは設計段階での「決定」として扱われ、ほとんどコストをかけずに対応できる。

この「タイミング」の重要性から、このチェックリストは、Claude Codeのような「コーディングエージェント」（人工知能によるコード生成ツール）の「スキル」として提供されている。これは、エージェントが特定の種類のコード（例えば、認証機能、データベースアクセス、ファイルアップロード処理、APIエンドポイント、決済フローなど）を生成しようとするときに、このセキュリティスキルファイルを自動的に読み込み、それに従ってコードを生成するように設計されている。さらに、アプリケーションを公開する前には、エージェントがこのスキル全体を「監査」として実行し、各コントロールの検証結果をファイルに記録する。このレポートは、「すべて安全です」という曖昧な報告書よりも、どの項目がパスし、どれが失敗し、そしてどれがそもそもチェックされなかったのかを正直に伝えるため、はるかに信頼できる情報となる。エージェントは「すべて安全」という結果を報告することを禁じられており、「チェックされなかった」という状態も明確に報告することで、従来のチェックリストが形骸化する失敗を防いでいる。

このセキュリティスキルがカバーする範囲は非常に幅広い。パスワードやAPIキーなどの「秘密情報とキー」の安全な管理、データベースからのデータ取得時の「データアクセス」制御、ユーザー認証やセッション管理に関する「認証とセッション」、不正アクセスを防ぐための「レート制限」、ユーザーからの入力やシステムからの出力処理に関する「入出力」の検証、通信の暗号化や外部ライブラリの安全性に関する「通信とサプライチェーン」、外部からの攻撃を受けやすい「リクエスト表面」の防御、最近利用が増えている「AI機能」利用時のセキュリティ対策、自身の「コーディングエージェント」が安全であるかの確認、SQL以外の多様な「インジェクション」攻撃への対策、そしてシステムの運用における監査ログやバックアップ、アクセス権限といった「運用」上のセキュリティ確保、さらにはコード変更の承認プロセスや自動テストといった開発プロセス上の「ゲート」のセキュリティまで多岐にわたる。これらの項目は、開発の作業フェーズごとにグループ分けされており、開発者が今取り組んでいるフェーズに合わせて必要な項目を確認できるようになっている。

しかし、このスキルは万能ではない。これはあくまでアプリケーションの「ベースライン」となる一般的なセキュリティ要件を満たすことを目的としており、特定の製品のビジネスロジックに潜む脆弱性を特定する「脅威モデリング」そのものではない。これらのセキュリティ項目すべてをクリアしたからといって、アプリケーションが完全に安全になるわけではない。これは、44の特定かつ一般的な脆弱性が生じる可能性を低減するものであり、その価値は非常に高いが、これを過信してはならない。このスキルは、特定の製品の複雑なビジネスロジックの脆弱性、高度な暗号設計の問題、物理的なセキュリティや人的なセキュリティ、あるいは業界固有の厳しい規制などはカバーしない。これらの分野に関しては、それぞれの専門家や専門のプロセスに頼る必要がある。

このセキュリティスキルはすべてGitHub上で公開されており、MITライセンスの下で誰でも利用できる。全体を自身のプロジェクトに取り入れることも、特定のグループだけを参考にすることも、あるいは既存のバグを発見するのに役立つわずか二つの項目だけを利用することも可能だ。OWASP ASVS 5.0という主要なセキュリティ基準ともマッピングされているため、どこまでカバーされているかを確認することもできる。

もし、システムエンジニアを目指すあなたが、この解説から一つだけ実践する教訓を得るとするなら、それは前述の「二つのブラウザテスト」だ。二つの異なるブラウザで同じアカウントにログインし、そのうちの一つのブラウザでパスワードを変更した後、もう一方のブラウザをリロードしてみる。もし二つ目のブラウザがまだログイン状態のままであれば、あなたのアプリケーションのパスワードリセット機能は、不正にアクセスしている可能性のある人物を含む、誰もシステムから強制的に排除できていないことになる。これは、アプリケーションのセキュリティに直結する非常に重要なポイントなので、ぜひ自身の開発するアプリケーションで試してみてほしい。