よりセキュアなコードのリリースは、開発の最終段階でセキュリティチェックを行うのではなく、初期段階から対策を行える開発プロセスを構築することと、開発者がセキュリティの修正を行いやすい環境を整えることが重要です。本ブログでは、GitHubのセキュリティ担当プロダクトマネージャーのMaya Kaczorowskiが依存関係について詳しく説明し、依存関係を最新の状態に保つべき理由と、最も重要なときに迅速かつ確実にパッチを適用できるようにする方法を説明します。
私たちの中で、ソフトウェアアップデートを無視したり、漠然と「後で通知する」をクリックしアップデートを実行せずに放置したことがある人はいったい何人いるでしょうか。残念ながら、これはかなりよくあることです。このような放置は、最新の機能が手に入らないだけでなく、新しいセキュリティの問題が見つかった場合には自分自身をリスクにさらしてしまうことになります。
コード内の依存関係についても同様です。依存関係のアップデートを遅らせることは、後で対処するのがさらに難しくなるだけです。アップデートにセキュリティパッチが含まれていなければ、アップデートを遅らせても問題ないというわけではなく、アップデートが既知の脆弱性に対処するものでなくても、依存関係を定期的にアップデートすることでセキュリティが向上します。
セキュリティパッチは通常、最新バージョンのパッケージにのみ適用可能
セキュリティを確保するために定期的にアップデートすべき主な理由は、パッチが緊急の問題に対応するために一番上のレイヤーに貼られる「ばんそうこう」に過ぎないためです。通常、パッチは、プロジェクトの最新バージョンまたはサポート対象バージョン向けにのみリリースされ、非常に重大な修正であっても、パッチが古いバージョンに適用されることはめったにありません。このようなパッチの作成は、メンテナーにとって大変な作業になるためです。メンテナーは、パッチが適用されるすべてのバージョンについて、パッチが実際にセキュリティの問題を解決することを検証し、パッチによってその他の問題が引き起こされないことをテストで確認する必要があります。
まれに一部のパッチが既存のバージョンに適用できず、アップグレードが必要になることがあります。このようなことは、たとえば重大なセキュリティホールを塞ぐために、互換性を破る変更を機能に加えた場合などに起きる可能性があります。この場合、セキュリティを担保するにはアップグレードが必要になります。
一部の企業では、環境内のあらゆるコンポーネントを、それらのコンポーネントに対するアップデートを含めて検証することがありますが、これは良い慣行と言えます。そのような場合は、重大なセキュリティの問題があるときだけでなく、定期的にコンポーネントに対するアップデートをレビューします。
依存関係を定期的にアップデートすることで、常に最新のバージョンを使用できます。こうすることで、パッチがリリースされたときに、それを環境に適用できるということが分かります。これは、段階的に変更を適用するというサイト信頼性エンジニアリング(SRE)原則と同様です。重要なセキュリティパッチを1つ適用するほうが、そのパッチを取得するために以前に適用を怠った直近7つのアップデートを適用するよりもずっと簡単です。システムに対する変更が小さいと、環境に悪影響を及ぼす可能性が低くなります。
定期的なアップデートは「アップデートが必須なときに、実際にアップデートできる」ことを意味する
セキュリティパッチを適用することに関して、他にどのような良い点があるでしょうか。それは、セキュリティパッチを適用すれば良いため、ロールバックする必要がないということです。
段階的な変更の概念を超えて考えた場合、環境を継続的にアップデートすることは、継続的に変更する能力を得ているというだけでなく、継続的に変更しているという安心感も得られます。環境に対する変更を定期的に、所定の手続きに従ってロールアウトできるということが分かっていれば、重要なセキュリティパッチなど、変更が本当に必要なときにその変更を行うことができるという安心感が得られます。
多くの慣行に加えて、ここで重要なのはテストです。DORAによるDevOps状況レポートから分かったことは、開発者は継続的インテグレーションとテストの自動化があれば、より迅速に作業できるということです。DevOpsでは、これはシステム停止後の対応における平均復旧時間(MTTR)に関して特に重要となります。また、DevSecOpsでは、平均修復時間(便宜上こちらもMTTR)に関して重要です。重大なゼロデイ脆弱性に対処するには、修復速度も重要です。数日ではなく、数時間で対応できなければなりません。十分なテスト体制を整備しておけば、修正プログラムによって環境が破壊されないことを信頼しながら、その修正プログラムを迅速にデプロイすることができます。
残念ながら、セキュリティの脆弱性は常に公開されるとは限らない
最後に、セキュリティパッチが存在する場合にのみアップデートすると、一部のセキュリティ脆弱性を見逃してしまうことになります。幸いなことに、多くの大規模なオープンソースプロジェクトには、新たに見つかった脆弱性に対処したり、それを修正したり、対応するパッチをリリースしたりするための確立されたセキュリティプロセスがあります。
ただし、次のような場合には、そのプロセスが意図したとおりに機能しないことがあります。
- セキュリティパッチが、(マイナーアップデートやメジャーアップデートのように)比較的大規模なアップデートの一部としてリリースされる。この場合にパッチを入手するには、とにかく新しいバージョンにアップデートする必要があります。これは、以前に述べたように、パッチに後方互換性がない場合に起きる可能性があります。
- セキュリティの脆弱性が公開されない、または後で明らかになる。この場合は、バグが当初はセキュリティに影響を及ぼすものであると認識されていなかった可能性があります。または、メンテナーがセキュリティの問題を具体的に指摘する方法を認識していません。このような状況では、リリースノートを読むことが役立ちます。
- セキュリティパッチは公開されていないないが、リスクを軽減するワークアラウンドがある場合。この場合は、問題全体に対処する修正プログラムは必ずしも必要ではありませんが、新しいフラグや機能、またはリスクを制限するために実行できるその他のアクションがある可能性があります。これは厳密にはセキュリティパッチではないため、セキュリティパッチとしてマークされるとは限りません。
アップデートで明示的な情報公開なしにセキュリティパッチが提供されることはほとんどありません。オープンソースプロジェクトに対するアップデートがリリースされると、誰でもそのアップデートを検証し、自分でバグを見つけることができるからです。
GitHubのDependabotでアップデートを実行する
GitHubが提供するDependabotは、依存関係にセキュリティの脆弱性がある場合に、プロジェクトにPull Requestを送信し、依存関係をアップデートするよう促す便利なボットです。Dependabotセキュリティアップデートは、2019年11月、GitHubでネイティブに利用できるようになりました。また最近、Dependabotのパッケージに対するサポートが追加されました。Dependabotは、設定されたスケジュールで依存関係の新しいバージョンをチェックし、アップデートを推奨します。
Dependabotを有効にするには、dependabot.yml設定ファイルをリポジトリにチェックインします。この設定を行うことで、依存関係を最新の状態に保つことが、Pull Requestのレビューやマージと同じくらい簡単になります。
依存関係を定期的にアップデートすれば、最新のセキュリティパッチを適用でき、重要なときに重要な変更を環境に加えられるという安心感が得られ、セキュリティに影響を及ぼす可能性があるバグにも確実に対処できるようになります。GitHubでDependabotを利用し、既知の脆弱性がある依存関係にパッチを適用しましょう。また、Dependabotを利用してパッケージを常に最新の状態に保ち、セキュリティを向上させることもできるようになりました。
安全なソフトウェア開発のために
本ブログで紹介した各機能は、以下のサイトで詳細を確認することができます。
GitHubでは、企業における安全なソフトウェア開発を進めるためのソリューションを提供しています。ご相談がある場合は、GitHub営業担当にお問い合わせください。
