サードパーティ製プログラミング・ライブラリの脆弱性対応について

ほとんどすべてのソフトウェアは、何層ものサードパーティーライブラリを呼び出しています。例えば、あるJavaプログラムが、標準ライブラリの関数を呼び出して、日付の書式を設定したとします。その関数は、次にカレンダーを理解する別のライブラリの関数を呼び出すかもしれません。そして、その関数がまた別の関数を呼び出す、というように。
このように深くネストされたライブラリの1つにセキュリティ上の欠陥があるとしたらどうでしょう？あなたのプログラムは危険にさらされ、悪意のある侵入者は、あなたのプログラムが動作しているサーバーに侵入することができるのです。
依存関係の脆弱性を発見するためのスキャナーはたくさんありますが、その扱いには微妙なところがあります。この記事では、そのプロセスについて見ていきます。
不具合に関する情報源
私たちは皆、遠く離れたセキュリティ専門家のネットワークによって守られている。彼らは、危険な欠陥を明らかにするためにあらゆる種類の拷問的なテストをソフトウェアに課し、その欠陥を開発者に報告する。彼らのテストは、ある関数に通常とは異なる入力を投げかけて、その関数が混乱して侵入者にプログラムを乗っ取られてしまうかどうかを確認するような、基本的なものであるかもしれません。ファジング」と呼ばれる興味深い分野では、ランダムに生成した文字を大量にプログラムに投入し、バグや脆弱性を発見するのに驚くほど効果的である。また、単体のコード（静的解析）や実行中のプログラム（動的解析）に疑わしい問題がないかを調べる総合的な解析ツールもある。
もちろん、あまり善意のない研究者も、政府機関やランサムウェアグループの顧客向けに悪意のあるエクスプロイトを作成する目的で、このような欠陥を探しているのです。まだ一般に知られていないセキュリティ上の欠陥（ゼロデイ・エクスプロイト）は危険ですが、ほとんどの攻撃は、一般に知られていて、被害者が自分のシステムに留めることを許している欠陥を利用しています。悪意のある行為者は、公開されている欠陥のリストを読んでいますので、ご安心ください。
一般に知られている欠陥は、セキュリティ組織が管理するデータベースで公開されており、特にCVE（Common Vulnerabilities and Exposures）データベースが有名です。米国標準技術局（NIST）は、ソフトウェアなどの標準化に関する米国政府の主要機関であり、CVEデータベースのエクスプロイトにさらに詳細を追加するNational Vulnerability Databaseを管理しています。また、フリーソフトウェア・ライブラリの既知の欠陥を収集する最近の取り組みとして、Open Source Vulnerabilities (OSV) データベースがあります。そして、いくつかのプロジェクトは、Python Packaging Advisory Databaseのような、関連する脆弱性の特定のコレクションを提供しています。
増え続ける脆弱性のリストをしつこく読む必要はありません。毎日発見されているので、追いつかないほどです。人気のあるプログラミング言語であれば、自動的にリストを検索し、あなたのアプリケーションが使っているすべてのライブラリについて何が発見されたかを教えてくれるツールを実行することができます。自動ツールの一覧は GitLab のサイトを参照ください。GitHubでも、Dependabotというサービスを通じて自動チェックを提供しています。
GitLab や GitHub が提供するツールを使えば、数回のクリックで開発サイクルの要所要所でチェックを実行させることができるので便利です。しかし、ツールを実行するためにGitLabやGitHubを利用する必要はありません。手動で開発サイクルに組み込むことができます。Javaや.NETのプログラムでも、OWASP Dependency-Checkツールを使用することができます。
ツールはいつ使うべき？もしチェックインにかかる時間を許容できるのであれば、できる限りすべてのチェックインで実行することをお勧めします。第一に、直近の編集でアプリケーションに新しいパッケージを追加したかもしれず、もしそのパッケージに欠陥があれば、すぐに知りたいでしょうから、その問題に対処するためにこの記事に記載されている手順を踏むことができます。第二に、新しい脆弱性は頻繁に発見されるため、以前は問題なかったパッケージに新しい問題が見つかることがあります。
少なくとも、品質保証やデプロイのようなライフサイクルの主要なステップの前には、自動脆弱性チェックを実行するようにしてください。脆弱性があるままライフサイクルの主要な段階に入るのは、その修正に多くの費用がかかるため、避けたいものです。
脆弱性スキャナを定期的に実行することは、アプリケーションのライフサイクルにセキュリティを統合するトレンドであるDevSecOpsの中心的な部分です。  CIAやFBIを含む一部の規制環境では、Security Content Automation Protocol (SCAP) に従ったスキャンを要求しています。SCAPはNISTによって開発され、Open SCAPと呼ばれるオープンソースの実装を有しています。
簡単な修正
脆弱性が見つかったのですね。うまくいけば、すぐに修正することができます。もしそのパッケージの開発者が修正を施した新しいバージョンをリリースしているなら、 あなたがすべきことは、修正されたバージョンを使ってアプリケーションを再構築することだけです。もちろん、パッケージへの変更は新たな問題を引き起こす可能性があるので、アップグレード後にリグレッションテストを実行する必要があります。
ソフトウェアビルドの洗練された傾向として、Project Thothがあります。これは、Pythonアプリケーションのための安全なライブラリを見つけるためにRed Hatが開発したオープンソースツールです。(Thoth は、アプリケーションが使用する各ライブラリの最新の安定版を単に取り込むのではなく、さまざまな公開データベースを参照し、欠陥なく一緒に動作するパッケージの組み合わせを推奨しようとします。同じようなアプローチは、他のプログラミング言語の開発者にも真似されている。
もしソフトウェアの脆弱性を修正した新しいバージョンがまだないのであれば、もしかしたら脆弱性を含まない古いバージョンのライブラリが見つかるかもしれません。もちろん、その古いバージョンに他の脆弱性がある場合は、あまり役に立ちません。また、古いバージョンがあなたのニーズを満たすように見えたとしても、新しいバージョンで追加された機能に依存しないようにしなければなりませんし、再び回帰テストを実行する必要があります。
欠陥の範囲の決定
前のセクションで提案された解決策が使えないとしましょう。あなたは、セキュリティ上の欠陥が確認されたライブラリを使ってプログラムを構築することから抜け出せないでいます。ここで、いくつかの微妙な調査と推論が必要になります。
侵入の引き金となりうる状況に目を向けてください。多くのエクスプロイトは、セキュリティ研究者が報告した時点では理論上のものですが、すぐに現実のものとなってしまいます。そこで、脆弱性報告書を読んで、攻撃者がリスクとなるための条件を確認します。彼らは、あなたのシステムに物理的にアクセスする必要がありますか？スーパーユーザー(root)になる必要があるか？一旦rootになれば、おそらく大惨事を引き起こすためにあなたの欠陥を悪用する必要はないでしょう。攻撃者があなたの特定の環境でエクスプロイトを実行できる可能性は低いと判断することもできます。
自動化された脆弱性スキャナの中には、公然と脆弱性を検出するものがあります。彼らは何かを問題視するかもしれませんが、あなたの場合、それは問題ではないと判断するかもしれません。
また、欠陥が悪用されないことを保証するために、より多くのチェックを挿入することができるかもしれません。脆弱性のある関数に渡される引数の1つがバッファの長さで、その引数が負の場合にのみ悪用される危険性があるとします。もちろん、バッファの長さは常にゼロか正であるべきです。あなたのプログラムは、その引数に負の値を持つ関数を正当に呼び出すことはありません。関数の各呼び出しの前にこれを追加することで、セキュリティを強化することができます。
    if (argument < 0)           exit; また、正規の入力では決して使われてはならない文字を注入することで、そのような文字を関数に渡す前にチェックすることができます。Perl で何年も前に導入された技術革新に倣って、危険な変数に「tainted」というマークを付けて、セキュリティ違反がないかをチェックしたことが分かるようにした言語もあります。 アプリケーション全体にそのようなチェックを入れるのではなく、アプリケーションプロキシや他のラッパーに危険な入力のチェックを追加する方が簡単かもしれません。 この回避策は一時的なものであるべきです。なぜなら、ライブラリのメンテナがすぐにこのバグを修正するはずだからです。 もし誰もこの回避策をコミュニティで共有していないのであれば、この不具合を報告した issue にコメントを追加し、あなたの解決策を他の人に提供してください。 ところで、報告された欠陥が、あなたが呼び出していない関数に影響すると判断することもあるでしょう。しかし、ライブラリ内の他の関数を呼び出すと、間接的に安全でない関数を呼び出してしまうかもしれないので、注意が必要です。アプリケーションの関数呼び出しの階層全体を見ることができるトレースやプロファイリングのツールがあるので、危険にさらされているかどうかを確認することができます。 もしかしたら、あなたは攻撃者から真っ向から狙われているかもしれません。回避できない欠陥のある関数を使用しているかもしれません。その欠陥のある関数は必要なのか？似たような機能を提供する代替ライブラリがある場合が多い。あるいは、その関数を使う特定の用途は、自分でコードを書くことができるほど単純なものかもしれません。しかし、その関数の独自のバージョンを書くことは悪い考えです。なぜなら、問題を解決するよりもバグを発生させる可能性の方が高いからです。結局のところ、あなたはライブラリのメンテナよりも安全なコーディングについて知識がないのです。(もしあなたが彼らより知識があるのなら、彼らがライブラリを修正するのを手伝ってあげてください!) また、自分のコーディング技術に自信があり、使用しているパッケージに十分精通していると感じて、バグフィックスを提供する可能性もあります。これはオープンソースのパッケージだけのオプションですが、できる限りオープンソースのパッケージを使ってほしいと思います。 最後に、深層防護が常に重要であることを思い出さずに終わりたくはありません。例えば、アプリケーションを内部で使用する場合、ファイアウォールルールや認証により、正当なユーザーとのみ通信することを保証する必要があります。一方、内部ユーザであっても、悪意のあるユーザであるかもしれませんし、外部の人間がサーバへの侵入経路と して利用することで危険にさらされるかもしれません。ですから、安全なアプリケーションが依然として必要なのです。 結論 ソフトウェア開発において、セキュリティ上の欠陥は常にリスクとなり、私たちの周りにも存在します。なぜなら、システムに侵入されると、ランサムウェアの攻撃、重要な顧客データの盗難、ボットネットでのシステムの悪用、その他の厄介な結果を引き起こす可能性があるからです。自分が被害者にならないように気をつけましょう。 しかし、あまりにも多くの欠陥があるため、欠陥が報告されているすべてのライブラリを排除するという態度をとることはできません。アップグレードが可能であれば、速やかにインストールしましょう。それ以外の場合でも、この記事があなたのセキュリティを守るための合理的な判断の一助となれば幸いです。