DevSecOps、シフトレフト、GitOpsに関するMayaの投稿をお読みになった方は、「このようなセキュリティ原則を実際に取り入れるするにはどうすればいいのか？」と疑問に思われているかもしれません。ここで実例を詳しく見てみましょう。静的分析を開発者ワークフローに統合するには、どうすればよいでしょうか。
静的分析とは？そして、それを開発者ワークフローに統合する理由
静的分析セキュリティテスト(SAST)は、脆弱性に対応するために開発者やチームが作成したコードを分析します。これはCode Scanningとも呼ばれる方法で、コードをクエリ可能な形式に変換してから、脆弱性のパターンを探します。サニタイズされていないユーザーデータをデータベース呼び出しに送信するような仕組みです。静的分析ツールは、改良を加えた文法チェッカーのようなものとして考えることができます(ただし、文法チェッカーに手を加えると害を与えてしまうことになります。ファイルや機能の境界をまたぐデータフローをモデル化するのは困難だからです)。
静的分析セキュリティテストは、開発サイクル後半のセキュリティレビューの一環として行われる傾向があります。このテストを開発者のメインワークフローに移動して、すべてのPull Requestに対して静的分析を実施することが、“セキュリティのシフトレフト”の最たる例です。
では、静的分析を開発者ワークフローに組み込むと、どのようなメリットがあるのでしょうか。DevSecOpsのアプローチについてMayaの投稿で取り上げた、すべての理由が当てはまります。適切に統合することで、日々のコードレビューの中でセキュリティの問題点を見つけ出し、実稼働前に余裕をもって修正することができます。
静的分析のシフトレフトに伴う課題とその解決方法
静的分析を開発者ワークフローに統合することによって多くのメリットが得られるにもかかわらず、幅広く取り入れられていないのはなぜでしょうか。そこには困難が伴い、間違ってしまうと大変なことになりかねないからです。では、課題とその解決方法をいくつか見てみましょう。
Pull Requestワークフローに統合するツールは、高速でなくてはなりません。低速の静的分析ツールを導入すると、エンジニアリングチームがCIを待つ時間が長くなり、開発者の生産性が確実に損なわれます。コンテキストの切り替えが増える一方で、満足度が下がり、アウトプットが低下します。このような運命をたどらないようにするには(あるいは、プロジェクトのシフトレフトが頓挫するような憂き目にあわないようにするためには)、新しい分析がCI時間に及ぼす影響を慎重に監視し、低速のクエリやツールを主要なCIループから外して、(従来の)スケジュールに組み込みます。
Pull Requestワークフローのツールには、正確性も求められます。ノイズの多い静的分析ツールを導入すると、エンジニアリングチームはすぐに、自動化されたセキュリティの調査結果を完全に無視するようになるでしょう。業界のベストプラクティスとしては、Pull Requestの結果に示される偽陽性を10%以下に抑えることをターゲットにしていますが、これだけ低い割合に抑えることは困難です。では、どのような解決策があるでしょうか。それは、「すべての」セキュリティスキャンをシフトレフトしないことです。ノイズの多いチェックは従来どおりセキュリティチームにレビューを任せることにして、精度の高いチェックを開発者ワークフローに移行します。優れた統計分析ツールがあれば、クエリを反復的に改善することも容易になります。
最後に、Pull Requestワークフローに統合したツールは、セキュリティチームではなく開発者がレビューできるように設計する必要があります。静的分析セキュリティテストは結果を明らかにしますが、少なくとも現時点では、人間の手で修正しなくてはなりません。Pull Requestで提案された変更に起因する新しい調査結果のみを、Pull Requestレビューのコンテキストに表示するべきです。セキュリティ初心者の開発者でも個々の結果が重要か否かを判断できるように、明確に記述する必要があります。また、偽陽性として却下した結果についても、後からセキュリティチームがその理由を確認しやすくするべきです。
静的分析の構成をコードとして定義する
Mayaの投稿では、特にGitリポジトリに格納した構成をコードとして定義するメリットについても取り上げています。静的分析を実例として見てみましょう。
どの静的分析ツールにも、構成が必要です。分析を実行するタイミング(プッシュごと、Pull Requestごと、毎日など)、プロジェクトの分析方法(コンパイル済みの言語では、多くの場合ビルド方法の詳細が必要になります)、実行する分析(実行するクエリ、無視するパスなど)を指定する必要があります。
この構成を格納するのは、分析対象のリポジトリにコミットされるファイルが最適です。リポジトリにアクセス権を持つユーザーには即座に表示されるうえに、スキャン対象のソフトウェアと同じバージョン管理および変更管理が行われるからです。
GitHub Code Scanning
上記のことを念頭に置きつつ、セキュリティをシフトレフトできるようGitHub Code Scanningを構築しました。
Code Scanningでは、どの段階でも開発者のエクスペリエンスが優先されます。その中核にある静的分析エンジン(CoreQL)は高速でパワフルなので、実際のセキュリティの問題をノイズなく検出できます。このエンジンで実行されるクエリは正確かつ構成可能であるうえに、オープンソースコミュニティが常に改良を加えています。結果は、詳細の説明や修正案とともに、インラインのPull Requestコメントに表示されます。すべての構成は、GitHub Actionsのワークフローファイルでコードとして行われます。
GitHub.comだけでなく、オプレミス版のGitHub Enterprise Server 3.0でもCode Scanningが使えるようになりました。ぜひ、お試しください。
