既知の脆弱性を有するコンポーネントの使用
ほとんどのアプリケーションは大量のサードパーティ製コンポーネントを利用しています。これらのコンポーネントは、ログ記録からモデル作成、データベースアクセスに至るまで、あらゆる機能を提供します。
ソフトウェア開発を大幅に容易にし、多くの時間を節約できます。しかし、これらのコンポーネントも人間によって作成されており、必然的に脆弱性を含むものもあります。これは、悪用される可能性のある脆弱性に知らずにさらされる可能性があることを意味します。
コンポーネントの更新
一般的に、フレームワーク、ライブラリ、その他のコンポーネントを定期的に更新することを強く推奨します。これにはいくつかの方法があります：
- 多くのソースコード管理ソフトウェアは、リポジトリを分析し、依存関係に脆弱性が発見された場合に警告を発することができます。
- 多くのパッケージ管理ツールはアプリケーションを分析し、脆弱な依存関係を特定できます
- ソフトウェア構成分析（SCA）ソリューションは数多く存在し、脆弱な依存関係を特定することが可能です。
技術的負債のリスクを軽減する
ライブラリのアップグレードに関連する、かなり厄介な問題の一つは、コードの変更が生じる可能性があることです。こうした変更は多くの場合文書化されていますが、文書化されていない変更も存在し、本番環境でコードが実行されるまで表面化しない場合があります。
アプリケーションが最新版から大幅に古いバージョンを実行している場合、最新バージョンへのアップグレードには多大な労力を要する可能性があります。時間依存の脆弱性が発見された場合、アップグレードに数日を要することを避けるため、サードパーティ製コンポーネントに関しては比較的最新の状態に保つことが不可欠です。
また、少なくともリリースノートを読まずにパッケージを盲目的に更新することも推奨されません。なぜなら、リリースノートには、一見して明らかではないがアプリケーションの動作に影響を与える可能性のある変更に関する重要な情報が含まれている場合があるからです。
アップデートによって不安定になる可能性はありますか？
まれではあるが、脆弱性が以下を引き起こす可能性がある：
- 以前のバージョンには存在しません
- 脆弱性の修正時に提示される
これらの事例は、パッケージの定期的な更新が必ずしも望ましくないと思わせるかもしれない。もちろん、この考え方は可能な限り避けるべきである。なぜなら、技術的負債の蓄積につながるからである。
このシナリオが比較的稀であることを考慮すると、パッケージの頻繁な更新による利点は、新たに導入された脆弱性の可能性をはるかに上回ります。いずれにせよ、定期的に更新を続けることで、そのような脆弱性は容易に軽減されるはずです。
また、ベンダーが脆弱性を黙って修正し、一切開示しないという前提にも立っている。残念ながら、これは依然として非常に一般的なことである。
顕著な例
以下に、最近おそらく耳にしたことがあるであろう注目すべき事例をいくつか挙げます。ライブラリを参照し、常に最新の状態を保つことの重要性が、その方法と理由とともに理解できるでしょう。