Microsoft SDLをもとに開発ライフサイクルを整理する
ソフトウェアの脆弱性は、サイバー攻撃でシステム侵害を試みる際に狙われる格好の標的の1つだ。シノプシスが毎年発行する「オープンソースセキュリティ＆リスク分析レポート」（2020年版）によると、17業種の1,546の商⽤コードベースを監査したところ、84％のコードベースに1つ以上の脆弱性が含まれており、中には2年以上前に公表された脆弱性が対応されないまま残っているものもあるという。
リリース前にはバグや脆弱性の有無をセキュリティテストで検証するなど、多くの開発現場はセキュアなソフトウェア開発に取り組んでいるが、かなりの取りこぼしが発生しているのは明らかだ。
日本シノプシスの松岡正人氏は、ソフトウェアのセキュリティ強度を高めるには、テストツールを導入するだけではダメだと指摘する。「開発に関わる人やプロセス、技術をうまく組み合わせて最適化し、開発ライフサイクルの全フェーズでセキュリティリスクに対処する、そんな機構を構築したい」（松岡氏）
松岡氏は参考として、多くの開発現場でリファレンスとして取り入れられているマイクロソフトの「Microsoft SDL（Software Development Lifecycle）」を紹介する。ソフトウェアの信頼性と安全性を高めるために同社が策定したガイドラインで、要件・設計・実装・検証・リリース・運用の開発ライフサイクルの各フェーズで求められるセキュリティテストが記載されている。
異なる制約下のサービスやプラットフォーム、サブシステムが連携し、OSSやサードパーティのライブラリなどを組み合わせたアプリケーションが動作する現代の複雑なシステムも、こうしたガイドラインに基づき、要件フェーズでセキュリティ要件の定義やリスク評価を実施。設計フェーズで攻撃面の分析や想定される脅威を洗い出し（脅威モデリング）、実装や検証フェーズで必要なセキュリティテストを組み込むことで、よりセキュアなシステムを開発運用できるようになる。
セキュリティテストの主なものとしては、静的解析（SAST）、動的解析（DAST/IAST）、ソフトウェアコンポジション解析（SCA）が挙げられる。
SASTはソースコードの静的解析テストで、SQLインジェクションやXSSなどの一般的な脆弱性を発見するのに最適だ。テストツールには、プロジェクトや組織で使用する言語、コーディング規約を確実にサポートし、業界標準を網羅、IDEとの連携や大規模開発環境に対応するものを選びたい。
DASTは、アプリケーションやコンポーネントが動作する開発環境および運用環境を動的解析し、構成や設定、認証処理、ビジネスロジックなどの欠陥をあぶり出すテストだ。IASTもDAST同様に動的解析の1つで、アプリケーションサーバーなどにインストールしたエージェントを介してコードおよびメモリを解析し、問題を洗い出す。いずれもテストツールであれば、解析結果から偽陽性を排除できる正確性や、新たに発見された脆弱性に関する詳細の分析報告をする機能など、自動化を視野に入れた機能だ。
そして最後のSCAは、コードに含まれるOSSやサードパーティのソフトウェアコンポーネントを解析し、脆弱性の有無をチェックするテストだ。特にこうしたコンポーネントは、開発者が使えると判断して利用しているもの、過去のコードから含まれていたもの、外部委託事業者の判断で含まれているものなど多様で、すべて把握できていない企業は多い。新たな脆弱性が公開されても、自社のコードに該当するものが存在することすら気付けないのが現状だ。
このような問題に対処するため、いま注目されているのが、ライブラリや各種機能などソフトウェアの構成要素を洗い出して管理するSBOM（ソフトウェア部品表）の考え方だ。ポイントは、開発側と運用側でSBOMを共有することだと松岡氏は言う。これにより、開発側はリリース時に既知の脆弱性がソフトウェアに含まれていないかを検証でき、運用側は新たに発見された脆弱なライブラリなどがないかを監視することができる。2021年に米国で発令された14028大統領令では、政府機関が利用するソフトウェアの開発に関する安全性の確保について、ガイドライン策定をNISTに指示しているが、SBOMの活用についても強調されている。
このほか、NISTからはSP800-53 Rev5「組織と情報システムのためのセキュリティおよびプライバシー管理策」のSA-11（付属書C）にもSASTや脅威モデリング、コードレビュー、セキュリティリスク評価、DAST/ファジング、IAST/APIセキュリティテストの一覧が掲載されている。NISTの各種ガイドラインは、IPA（独立行政法人 情報処理推進機構）が日本語版を公開している。
DevSecOpsを実現するための新たな仕組み：ASOC
マイクロサービスなどコンテナ化されたシステムについてはどうだろうか。
NIST SP800-190の「アプリケーションコンテナに関するセキュリティガイド」には、コンテナをセキュアに開発、運用するための論点がいくつかまとめられている。その中でソフトウェア開発について、コンテナに合ったセキュアな開発プロセスを用意することと、コンテナそのものの脆弱性を管理する必要があるとしている。
「コンテナでは、GitHubなどで公開されているイメージを利用するケースも多いが、これらに悪意のあるファイルが意図的に、または不注意で含まれていることがある」。そう述べる松岡氏は、InfoQが2021年に公開した調査レポートを取り上げ、400万近くのイメージを分析した結果、51％以上のイメージに悪用可能な脆弱性が見つかったほか、6432イメージにマルウェアが発見されたことに言及。2020年10月にDocker Hubが公開した脆弱性スキャン（有料オプション）などを活用して、コンテナ向けのセキュアな開発運用を心がけることが重要だ。
といっても、コンテナ開発のSDLCのフェーズがMicrosoft SDLのそれとやや異なるくらいで、組み込まれるセキュリティ施策は前述のものと変わりはない。たとえば、イメージをビルドする前にSAST/SCAなどのテストを実行。イメージビルド後には、IAST/DAST、ファジング、脆弱性スキャンを実行する。運用時は、IAST/DASTやファジング、ペンテストを実行するなどだ。Dockerではコンテナアプリケーション開発のベストプラクティスを公開しているので、そちらも合わせて参照してほしいと松岡氏は紹介する。
セキュリティテストを開発フェーズに組み込む際に課題となるスピードについては、ASOC（Application Security Orchestration and Correlation）で解決できると松岡氏は言う。ASOCは、ガートナーが提言する新しい仕組みで、セキュリティテストにオーケストレーションと相関付けを組み合わせてDevSecOpsの効率を向上させるというものだ。シノプシスでは、セキュリティテスト、オーケストレーション、相関付けでそれぞれ製品/ソリューションを提供している。
オーケストレーション製品「Intelligent Orchestration」は、DevOpsと協調したポリシー、アプリケーションのリスクプロファイル、コードの変更、SDLCイベントなどに基づき、適切なタイミングで最適なテストの組み合わせを自動実行するソリューションだ。IDEやパッケージマネージャ、CI、ワークフローなど、開発で利用する各種ツール群と連携するほか、マニュアルのコードレビューやペネトレーションテスト、脅威モデリングによるリスク分析などの結果も取り込み、セキュリティレポートツールに出力したり、SlackやTeamsなど各種コミュニケーションツールへリアルタイムにフィードバックしたりすることも可能だ。通常の開発パイプラインとは分離した形で構成するため、簡単に既存環境に組み込めるのが特長の1つだ。
一方の相関分析では、統合管理ダッシュボード「Code Dx」を提供する。Code Dxは、全テスト結果をもとに組織全体のセキュリティ状況やリスクの相関関係を整理し、網羅的に可視化。優先対応すべきリスクを提示し、対応の効率を上げる。
「ソフトウェア/アプリケーション/サービスの開発に求められるセキュリティテストは、マイクロサービスなどのコンテナ技術へ移行しても大きく変わらない。各種ガイドラインやベストプラクティスを参考に、それぞれの開発フェーズにセキュリティテストを組み込み、ASOCの考え方を取り入れたDevSecOpsを目指す。そして何よりも、セキュリティはビジネス課題であるという意識を組織全体で共有し、ソフトウェア品質の向上とビジネスリスクの軽減に取り組むこと。これがこれからますます重要になるだろう」（松岡氏）
日本シノプシスのブログには、開発に関わるガイドラインの解説やDevSecOpsの考え方などの記事を発信している。セキュア開発の一助になれば幸いと松岡氏は述べた。
