数十年にわたって、ソフトウェアの再利用は実際よりも頻繁に議論されてきました。 今日、状況は反対です。開発者は、他の人のプログラムをソフトウェアの依存関係の形で毎日再利用し、問題自体はほとんど未調査のままです。



私自身の経験には、依存関係が優先概念として設定されているGoogleの内部リポジトリでの 10年間の作業と、Goプログラミング言語の依存関係システムの開発が含まれています 。



依存関係には、見過ごされがちな深刻なリスクが伴います。 ソフトウェアの最小部分の単純な再利用への移行は非常に迅速に行われたため、依存関係の効果的な選択と使用のためのベストプラクティスをまだ開発していません。 それらが適切であるときとそうでないときを決定することさえ。 この記事の目的は、リスクを評価し、この分野でのソリューションの検索を促進することです。

中毒とは何ですか？

現代の開発では、 依存関係はプログラムから呼び出される追加のコードです。 依存関係を追加することで、特定のコード単位の設計、作成、テスト、デバッグ、サポートなど、すでに行われている作業の繰り返しを回避できます。 一部のシステムでは、パッケージの代わりにライブラリやモジュールなどの他の用語が使用されますが、このコードユニットをパッケージと呼びます。



外部依存関係を受け入れることは古い習慣です。ほとんどのプログラマーは、CのPCREまたはzlib、C ++のBoostまたはQt、JavaのJodaTimeまたはJunitなど、必要なライブラリをダウンロードしてインストールしました。 これらのパッケージには、作成にかなりの経験が必要な高品質のデバッグされたコードが含まれています。 プログラムがこのようなパッケージの機能を必要とする場合、この機能をゼロから開発するよりも、パッケージを手動でダウンロード、インストール、および更新する方がはるかに簡単です。 しかし、大きな初期費用は、手動での再利用が高価であることを意味します。小さなパッケージは自分で書くのが簡単です。



依存関係マネージャー （パッケージマネージャーとも呼ばれます）は、依存関係パッケージのダウンロードとインストールを自動化します。 依存関係マネージャーを使用すると、個々のパッケージを簡単にダウンロードおよびインストールできるため、固定コストを削減することで、小さなパッケージの発行と再利用が経済的になります。



たとえば、NPMと呼ばれるNode.js依存関係マネージャーは、750,000を超えるパッケージへのアクセスを提供します。 その1つであるescape-string-regexp



には、入力データから正規表現演算子をエスケープする単一の関数が含まれています。 すべての実装：

 var matchOperatorsRe = /[|\\{}()[\]^$+*?.]/g; module.exports = function (str) { if (typeof str !== 'string') { throw new TypeError('Expected a string'); } return str.replace(matchOperatorsRe, '\\$&'); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

依存関係マネージャーが登場する前は、8行のライブラリを公開することは想像できませんでした。オーバーヘッドが多すぎて、利益が少なすぎます。 しかし、NPMはオーバーヘッドをほぼゼロに削減し、その結果、ほとんど些細な機能をパッケージ化して再利用することができました。 2019年1月末に、 escape-string-regexp



依存関係は、開発者が自分で使用するために作成し、パブリックドメインで公開しないすべてのパッケージは言うまでもなく、他のほぼ1000個のNPMパッケージに組み込まれました。



現在、ほとんどすべてのプログラミング言語に依存関係マネージャーが登場しています。 Maven Central（Java）、Nuget（.NET）、Packagist（PHP）、PyPI（Python）、RubyGems（Ruby）-それぞれに100,000を超えるパッケージがあります。 このような小さなパッケージの広範囲にわたる再利用の出現は、過去20年にわたるソフトウェア開発の最大の変化の1つです。 そして、もっと注意を怠ると、深刻な問題につながります。

何がおかしいのでしょうか？

この議論の文脈では、パッケージはインターネットからダウンロードされたコードです。 依存関係を追加すると、このコードの開発作業（設計、作成、テスト、デバッグ、およびサポート）が、通常は知らないインターネット上の他の誰かに委ねられます。 このコードを使用して、独自のプログラムを依存関係のすべてのクラッシュと欠点の影響にさらします。 ソフトウェアの実行は、文字通りインターネットからの見知らぬ人のコードに依存しています。 このように言えば、すべて非常に安全ではないように思えます。 なぜ誰もがこれに同意するのでしょうか？



私たちは同意します。それは簡単で、すべてがうまくいくように見えるからです。他の誰もがそれをやるからです。そして最も重要なことは、それが何世紀も昔から確立された慣行の自然な継続だからです しかし、無視する重要な違いがあります。



何十年も前、ほとんどの開発者は、オペレーティングシステムやコンパイラなど、依存しているプログラムを作成する他の開発者も信頼していました。 このソフトウェアは、よく知られているソースから購入されましたが、多くの場合、何らかのサポート契約があります。 エラーや完全な破壊の余地はまだあります。 しかし、私たちは少なくとも誰と取引しているかを知っており、原則として、影響力の商業的または法的手段を使用することができます。



インターネットを介して無料で配布されるオープンソースソフトウェアの現象は、ソフトウェアを購入するという従来の慣習に大きく取って代わりました。 再利用が依然として困難であったとき、そのような依存関係を導入したプロジェクトはほとんどありませんでした。 彼らのライセンスは通常、「特定の目的に対する商業的価値と適合性の保証」を放棄していましたが、プロジェクトは良い評判を築きました。 ユーザーは、意思決定を行う際にこの評判を大部分考慮しています。 商業的および法的介入の代わりに、評判のサポートが来ました。 その時代の多くの一般的なパッケージは今でも高い評価を得ています。たとえば、BLAS（1979年に公開）、Netlib（1987）、libjpeg（1991）、LAPACK（1992）、HP STL（1994）、zlib（1995）などです。



バッチマネージャーは、コードの再利用モデルを非常にシンプルに削減しました。開発者は、数十行の個々の関数と正確にコードを共有できるようになりました。 これは素晴らしい技術的成果です。 利用可能なパッケージは無数にあり、プロジェクトには多数のパッケージが含まれる場合がありますが、商業的、法的、または評判のコード信頼メカニズムは過去のものです。 より多くのコードを信頼しますが、信頼の理由はほとんどありません。



悪い中毒のコストは、各悪い結果の価格にその確率（リスク）を掛けた一連のすべての可能な悪い結果の合計と考えることができます。









悪い結果の価格は、依存関係が使用されるコンテキストに依存します。 スペクトルの一端には、ほとんどの悪い結果の価格がゼロに近い個人的な趣味のプロジェクトがあります。ただ楽しんでいるだけで、ミスはもう少しの時間を除いて本当の影響はありません。 したがって、リスクの確率はほとんど無関係です。ゼロを掛けます。 スペクトルのもう一方の端にある製品ソフトウェアは、何年もサポートする必要があります。 ここでは、依存関係のコストが非常に高くなる可能性があります。サーバーが落ちたり、機密データが開示されたり、顧客が苦しんだり、企業が破産したりする可能性もあります。 本番環境では、重大な障害のリスクを評価して最小化することがはるかに重要です。



予想される価格に関係なく、依存関係を追加するリスクを評価して削減するためのアプローチがいくつかあります。 パッケージマネージャーは、これらのリスクを減らすために最適化する必要がありますが、これまでのところ、ダウンロードとインストールのコストの削減に注力してきました。

依存性チェック

聞いたこともない、何も知らない開発者を雇うことはないでしょう。 最初に、あなたは彼について何かを学びます：リンクをチェックし、インタビューを行います。 インターネットで見つけたパッケージに依存する前に、このパッケージについて少し学ぶことも賢明です。



基本的なチェックにより、このコードを使用しようとするときに問題が発生する可能性を知ることができます。 検査中に軽微な問題が見つかった場合、それらを除去するための対策を講じることができます。 チェックで重大な問題が明らかになった場合は、パッケージを使用しない方が良い場合があります。より適切なパッケージを見つけるか、自分で開発する必要があるかもしれません。 オープンソースパッケージは、有用性を期待して作成者によって公開されていますが、使いやすさやサポートを保証するものではありません。 実稼働で障害が発生した場合、それをデバッグするのはユーザー次第です。 最初のGNU General Public Licenseが警告したように、「プログラムの品質とパフォーマンスに関連するすべてのリスクはあなたにあります。 プログラムに欠陥があることが判明した場合、すべての必要な保守、修理、または修正の費用を負担します。



次に、パッケージをチェックし、パッケージに依存するかどうかを決定するための考慮事項の概要を説明します。

設計

パッケージのドキュメントは明確ですか？ APIには明確な設計がありますか？ 著者がAPIとデザインを人にうまく説明できれば、ソースコードで実装をコンピュータにうまく説明できる可能性が高くなります。 明確で適切に設計されたAPIのコードを記述する方が簡単で、高速で、おそらくエラーが発生しにくいでしょう。 作成者は、将来の更新と互換性があるとクライアントコードに期待するものを文書化しましたか？ （例にはC ++およびGo互換性ドキュメントが含まれます）。

コード品質

コードはうまく書かれていますか？ いくつかのスニペットを読んでください。 著者は用心深く、誠実で、一貫しているように見えますか？ デバッグしたいコードのように見えますか？ これが必要になる場合があります。



コード品質を確認するための独自の体系的な方法を開発します。 重要なコンパイラ警告をオンにしてCまたはC ++でコンパイルする（たとえば-Wall



）など、単純なものは、開発者がさまざまな未定義の動作を回避するためにどれだけ真剣に取り組んだかを知ることができます。 Go、Rust、Swiftなどの最近の言語では、 unsafe



キーワードを使用して、型システムに違反するコードを示しています。 安全でないコードの量を確認してください。 InferやSpotBugsなどのより高度なセマンティックツールも役立ちます。 リンターはあまり有用ではありません。括弧スタイルなどのトピックに関する標準的なアドバイスを無視し、セマンティックの問題に焦点を合わせる必要があります。



あなたが慣れていないかもしれない開発方法を忘れないでください。 たとえば、SQLiteライブラリは、200,000個のコードと11,000行のヘッダーを持つ単一のファイルとして提供されます-複数のファイルをマージした結果です。 これらのファイルのサイズはすぐに赤字になりますが、より徹底的な調査により、開発の実際のソースコードにつながります。100を超えるソースCファイル、テスト、およびサポートスクリプトを含む従来のファイルツリーです。 単一ファイルの配布は、元のソースから自動的に構築されることがわかりました。これは、エンドユーザー、特に依存関係マネージャーを持たないユーザーにとって簡単です。 （コンパイラはより多くの最適化オプションを認識するため、コンパイルされたコードも高速に動作します）。

テスト中

コードにテストはありますか？ それらを制御できますか？ 彼らは通りますか？ テストは、コードの主な機能が正しいことを確立し、開発者が真剣にそれを維持しようとしていることを示します。 たとえば、SQLite開発ツリーには、30,000を超える個別のテストケースを持つ非常に詳細なテストスイートが含まれています。 テスト戦略を説明する開発者向けのドキュメントがあります 。 一方、テストがほとんどまたはまったくない場合、またはテストが失敗した場合、これは重大な危険フラグです。パッケージの将来の変更は、容易に検出できるリグレッションにつながる可能性があります。 コード内のテストを要求する場合（右？）、他の人に渡すコードのテストを提供する必要があります。



テストが存在、実行、および合格すると仮定すると、ツールを実行してコードカバレッジを分析し、 競合状態を検出し、メモリ割り当てを確認し、メモリリークを検出することにより、追加情報を収集できます。

デバッグ

このパッケージのバグトラッカーを見つけます。 多くのオープンエラーメッセージがありますか？ 彼らはどのくらい開いていますか？ 修正されたバグの数 最近修正されたバグはありますか？ 実際のバグ、特に長時間クローズされていないバグについて多くの未解決の質問がある場合、これは悪い兆候です。 一方、エラーがまれですぐに修正される場合、それは素晴らしいことです。

サポート

コミットの履歴を見てください。 コードはどのくらいアクティブに維持されていますか？ 現在積極的にサポートされていますか？ 長期間にわたって積極的にサポートされているパッケージは、引き続きサポートされる可能性があります。 パッケージで作業している人は何人ですか？ 多くのパッケージは、開発者が自由時間に娯楽のために作成する個人プロジェクトです。 その他は、有償の開発者グループが何千時間も作業した結果です。 一般に、2番目のタイプのパッケージは、通常、エラーをより迅速に修正し、新機能を着実に導入し、一般的にはより適切にサポートされます。



一方、一部のコードは本当に「完璧」です。 たとえば、NPMのescape-string-regexp



を再度変更する必要はありません。

使用する

このコードに依存するパッケージの数は？ 多くの場合、パッケージマネージャーはそのような統計情報を提供します。または、他の開発者がこのパッケージについて言及している頻度をインターネットで確認できます。 ユーザー数が多いということは、少なくとも多くのコードで非常にうまく機能するという事実を意味し、そのエラーはより迅速に認識されます。 広範な使用は、継続的なサービスの部分的な保証でもあります。広く使用されているパッケージがメンテナーを失った場合、関心のあるユーザーがその役割を引き受ける可能性が非常に高くなります。



たとえば、PCRE、Boost、JUnitなどのライブラリは非常に広く使用されています。 これにより、発生する可能性のあるエラーが確実に保証されるわけではありませんが、発生する可能性のあるエラーは、他のユーザーが前に発生したために既に修正されている可能性が高くなります。

安全性

このパッケージは安全でない入力でも動作しますか？ ある場合、悪意のあるデータに対する耐性はどの程度ですか？ 彼は、 National Vulnerability Database（NVD）で言及されているバグを持っていますか？



たとえば、2006年にJeff Deanと私がGoogle Code Search （公開コードベースのgrep



）に取り組み始めたとき、人気のある正規表現ライブラリPCREが明白な選択肢であるように思われました。 ただし、Googleセキュリティチームとの会話の中で、PCREには特にパーサーでのバッファオーバーフローなどの問題の長い歴史があることがわかりました。 私たち自身は、NVDでPCREを探すことでこれを確信しました。 この発見はすぐにPCREを放棄するようにはなりませんでしたが、テストと分離についてより慎重に考えるようになりました。

免許

コードは正しくライセンスされていますか？ 彼はライセンスさえ持っていますか？ ライセンスはプロジェクトまたは会社で受け入れられますか？ GitHubプロジェクトの驚くべき部分には明確なライセンスがありません。 プロジェクトまたは会社は、依存ライセンスに追加の制限を設ける場合があります。 たとえば、GoogleはAGPL（厳しすぎる）やWTFPL（曖昧すぎる）などのライセンスの下でのコードの使用を禁止しています。

依存関係

このパッケージには独自の依存関係がありますか？ 間接的な依存関係の欠陥は、直接的な依存関係の欠点と同じくらい有害です。 パッケージマネージャーは、特定のパッケージのすべての推移的な依存関係を一覧表示できます。また、理想的には、このセクションで説明するようにそれぞれをチェックする必要があります。 多くの依存関係を持つパッケージには、多くの作業が必要になります。



多くの開発者は、コードの推移的な依存関係の完全なリストを見たことがないため、依存関係がわかりません。 たとえば、2016年3月、NPMユーザーコミュニティは、Babel、Ember、Reactを含む多くの人気プロジェクトが、8行関数のleft-pad



と呼ばれる小さなパッケージに間接的に依存していることを発見しました。 彼らは、 left-pad



作者がNPMからパッケージを削除し、Node.jsユーザーのほとんどのアセンブリを不注意に破壊したときに、これを発見しました。 そして、この点でleft-pad



ほとんど例外的でleft-pad



ません。 たとえば、NPMの750,000パケットの30％は、少なくとも間接的にはescape-string-regexp



依存しています。 パッケージマネージャーは、レスリーランポートの分散システムの観察に合わせて、あなたの知らない存在でもパッケージ障害が発生すると、独自のコードが使用できなくなる状況を簡単に作成します。

中毒テスト

検証プロセスには、独自のパッケージテストの実行を含める必要があります。 パッケージがテストに合格し、プロジェクトをそれに依存させることにした場合、次のステップは、アプリケーションの機能に特化した新しいテストを作成することです。 多くの場合、これらのテストは短いスタンドアロンプ​​ログラムとして開始され、パッケージAPIを理解できること、およびパッケージAPIが意図したとおりに動作することを確認します（理解できない場合、または必要なことを実行できない場合は、すぐに停止してください） その後、これらのプログラムを、パッケージの新しいバージョンで実行される自動化されたテストに変換するのに余分な努力をする価値があります。 間違いを見つけて潜在的な修正がある場合は、特定のプロジェクトのこれらのテストを簡単に再起動し、修正が他の何かを壊さないことを確認できます。



ベースラインレビュー中に特定された問題領域には、特に注意を払う必要があります。 コード検索の場合、過去の経験から、特定の正規表現の実行にPCREが時間がかかることがあることがわかっていました。 最初の計画は、「単純な」正規表現と「複雑な」正規表現用に別々のスレッドプールを作成することでした。 最初のテストの1つは、 pcregrep



を他のいくつかのgrep



実装と比較するベンチマークでした。 pcregrep



が1つの基本的なテストケースの最速grep



よりも70倍遅いことがわかったとき、PCREの使用計画を再考し始めました。 最終的にPCREを完全に放棄したという事実にもかかわらず、このテストは今日もコードベースに残っています。

依存関係の抽象化

パッケージの依存関係は、将来オプトアウトできるソリューションです。 おそらく更新により、パッケージは新しい方向に進むでしょう。 重大なセキュリティ問題が見つかる場合があります。 おそらく最良のオプションが表示されます。 これらすべての理由から、プロジェクトの新しい依存関係への移行を簡素化する価値はあります。



プロジェクトソースコードの多くの場所からパッケージが呼び出される場合、これらすべての異なる場所を変更して、新しい依存関係に切り替える必要があります。さらに悪いことに、パッケージが独自のプロジェクトのAPIで提示されている場合、新しい依存関係に移行するには、APIを呼び出すすべてのコードを変更する必要があり、これはすでに制御できない可能性があります。このようなコストを回避するには、依存関係を使用してこのインターフェイスを実装するシンラッパーと共に独自のインターフェイスを定義するのが理にかなっています。ラッパーには、依存関係が提供するものすべてではなく、プロジェクトが依存関係から要求するもののみを含める必要があることに注意してください。理想的には、これにより、後で適切な別の依存関係を置き換え、ラッパーのみを変更できるようになります。新しいインターフェイスを使用するために各プロジェクトのテストを移行すると、インターフェイスとラッパーの実装がチェックされ、依存関係の潜在的な置換のテストも簡素化されます。



コード検索用に、Regexp



正規表現エンジンに必要なコード検索インターフェイスを定義する抽象クラスを開発しました。次に、このインターフェイスを実装するPCREの周りに薄いラッパーを作成しました。この方法により、代替ライブラリのテストが容易になり、PCREの内部コンポーネントの知識がソースツリーの残りに偶発的に注入されるのを防ぎました。これにより、必要に応じて別の依存関係に簡単に切り替えることができます。

依存関係の分離

また、エラーによって引き起こされる可能性のある損害を制限するために、実行時に依存関係を分離することも適切です。たとえば、Google Chromeを使用すると、ユーザーはブラウザに依存関係（拡張コード）を追加できます。 Chromeが2008年に初めて起動したとき、オペレーティングシステムの個別のプロセスで実行されているサンドボックス内の各拡張機能を分離するための重要な機能（現在はすべてのブラウザーで標準）が導入されました。不完全に記述された拡張機能の潜在的な悪用は、ブラウザ自体のメモリ全体への自動アクセスを持っていませんでした不適切なシステムコールを行うことはできませんでした。コード検索では、PCREを完全に削除するまで、少なくとも同じようなサンドボックスでPCREパーサーを分離する計画でした。現在、別のオプションはgVisorなどの軽量のハイパーバイザーベースのサンドボックスです。依存関係の分離により、このコードの実行に関連するリスクが軽減されます。



これらの例や他の既製のオプションを使用しても、実行時に疑わしいコードを分離することは依然として複雑すぎて、めったに実行されません。真の分離には、型指定されていないコードにクラッシュすることなく、完全にメモリセーフな言語が必要です。これらは、CやC ++などの完全に安全でない言語だけでなく、JNIがオンになっているときのJavaや、安全でない機能をオンにしたときのGo、Rust、Swiftなどの制限された安全でない操作を提供する言語でも複雑です。 JavaScriptのようなメモリセーフな言語であっても、コードは必要以上にアクセスできることがよくあります。 2018年11月に、最新バージョンのnpmパッケージevent-stream



（JavaScriptイベント用の機能的なストリーミングAPI）に混乱を招く悪意のあるコードが含まれていることが判明しました2か月半前に追加されました。コードはCopayモバイルアプリケーションのユーザーからビットコインウォレットを収集し、イベントフローの処理とはまったく関係のないシステムリソースへのアクセスを取得しました。これらの種類の問題から保護する多くの可能な方法の1つは、より良い依存関係の分離です。

中毒の放棄

中毒があまりに危険であると思われ、それを分離できない場合、最良の選択肢はそれを完全に放棄するか、少なくとも最も問題のある部分を除外することです。



たとえば、PCREのリスクをよりよく理解すると、Google Code Searchの計画は「PCREライブラリを直接使用する」から「PCREを使用するが、パーサーをサンドボックスに入れる」、「新しい正規表現パーサーを作成するが、PCREエンジンを保存する」に変更され、次に、「新しいパーサーを記述し、それを別のより効率的なオープンソースエンジンに接続します。」後に、Jeff Deanと私もエンジンを書き直したので、依存関係は残っていませんでした。結果はRE2でした。



依存関係のごく一部しか必要ない場合、最も簡単な方法は、必要なもののコピーを作成することです（もちろん、関連する著作権およびその他の法的通知を保持することです）。エラー修正、メンテナンスなどの責任を負いますが、より大きなリスクから完全に隔離されます。Go開発者コミュニティには、「ちょっとしたコピーは、ちょっとした依存関係よりも優れている」という格言があります。

依存関係の更新

長い間、ソフトウェアで一般に受け入れられていた知恵は次のとおりでした。「機能する場合は、何も触らないでください。」更新には、新しいエラーが発生するリスクが伴います。報酬なし-新しい機能が必要ない場合、なぜリスクを取るのですか？このアプローチは2つの側面を無視します。まず、段階的なアップグレードのコスト。ソフトウェアでは、コードを変更する複雑さは直線的にスケーリングしません。10個の小さな変更は、対応する1つの大きな変更よりも作業が少なく簡単です。第二に、すでに修正されたエラーの検出の難しさ。特に、既知のエラーが積極的に悪用されるセキュリティコンテキストでは、更新なしで毎日攻撃者が古いコードのバグを利用できるリスクが増加します。



たとえば、エクイファックスの2017年のストーリーを考えてみましょう。幹部は議会での証言で詳しく述べています。 3月7日、Apache Strutsの新しい脆弱性が発見され、パッチが適用されたバージョンがリリースされました。 3月8日、Equifaxは、Apache Strutsの使用を更新する必要があるというUS-CERT通知を受け取りました。 Equifaxは、それぞれ3月9日と15日にソースコードとネットワークのスキャンを開始しました。脆弱なWebサーバーがインターネット上で開かれていることを検出したスキャンは1つではありません。 5月13日、攻撃者は、Equifaxの専門家が見つけられなかったサーバーを見つけました。彼らは、Apache Strutsの脆弱性を使用してEquifaxネットワークをハッキングし、今後2か月で1億4800万人に関する詳細な個人情報および財務情報を盗みました。最後に、7月29日に、Equifaxはハッキングに気づき、9月4日にそれを公表しました。 9月末までに、EquifaxのCEOとCIOおよびCSOは辞任し、議会で調査が開始されました。



Equifaxの経験により、パッケージマネージャーはビルド中に使用するバージョンを知っていますが、実稼働環境での展開中にこの情報を追跡する他のメカニズムが必要です。 Go言語の場合、展開プロセスが更新を必要とする依存関係についてバイナリをスキャンできるように、各バイナリにマニフェストマニフェストを自動的に含める実験を行っています。また、Goは実行時にこの情報を利用できるようにします。これにより、サーバーは既知のエラーのデータベースにアクセスし、更新が必要な場合に監視システムに個別に報告できます。



迅速な更新は重要ですが、更新とはプロジェクトに新しいコードを追加することを意味します。つまり、新しいバージョンに基づいて依存関係の使用のリスク評価を更新する必要があります。少なくとも、現在のバージョンから更新されたバージョンに加えられた変更を示す違いを確認するか、少なくともリリースノートを読んで、更新されたコードで最も可能性の高い問題領域を特定します。多くのコードが変更され、その違いを理解するのが難しい場合、これもリスク評価の更新に含めることができる情報です。



さらに、プロジェクト専用に作成されたテストを再実行して、更新されたパッケージが少なくとも以前のバージョンと同じプロジェクトに適していることを確認する必要があります。また、独自のパッケージテストを再実行することも理にかなっています。パッケージに独自の依存関係がある場合、プロジェクト構成では、パッケージの作成者が使用するバージョンとは異なるバージョン（より古いまたはより新しい）の依存関係を使用する可能性があります。独自のパッケージテストを実行すると、構成に固有の問題をすばやく特定できます。



繰り返しますが、更新は完全に自動である必要はありません。更新されたバージョンを展開する前に、それらが環境に適していることを確認してください。



アップグレードプロセスに、すでに作成された統合および認定テストの再実行が含まれる場合、ほとんどの場合、更新の遅延は迅速な更新よりもリスクが高くなります。



重要なセキュリティ更新のウィンドウは特に小さくなります。Equifaxがハッキングされた後、フォレンジックセキュリティチームは、公開されてからわずか3日後の3月10日に、攻撃者（おそらく異なる）が影響を受けるサーバーのApache Struts脆弱性を悪用した証拠を見つけました。しかし、彼らはそこに1つのチームだけを立ち上げましたwhoami



。

あなたの中毒を見ます

結局のところ、作業は完了していません。依存関係の監視を継続し、場合によってはそれらを破棄することも重要です。



最初に、パッケージの特定のバージョンを引き続き使用するようにしてください。ほとんどのパッケージマネージャーでは、特定のバージョンのパッケージに必要なソースコードの暗号化ハッシュを簡単に、または自動的に記録し、パッケージを別のコンピューターまたはテスト環境に再ダウンロードするときにこのハッシュを検証できます。これにより、テストおよびテストしたものと同じ依存関係ソースコードがビルドで使用されます。このようなチェックにより、攻撃者は防御されましたevent-stream



、既にリリースされたバージョン3.3.5に悪意のあるコードを自動的に挿入します。代わりに、攻撃者は新しいバージョン3.3.6を作成し、人々が更新するのを待つ必要がありました（変更を注意深く見ないで）。



また、新しい間接的な依存関係の出現を監視することも重要です。更新により、新しいパッケージが簡単に導入される可能性があります。これにより、プロジェクトの成功が左右されます。彼らもあなたの注意に値します。この場合、event-stream



悪意のあるコードは別のパッケージに隠されていましたflatMap-stream



。これevent-stream



は、新しいバージョンの新しい依存関係として追加されました。



依存関係のクリープは、プロジェクトのサイズにも影響する可能性があります。Google Sawzallの開発中-JITログ処理言語-さまざまな時点で、著者はメインインタープリターバイナリにJIT Sawzallだけでなく、（未使用の）PostScript、Python、およびJavaScriptインタープリターも含まれていることを発見しました。毎回、犯人は、Sawzallライブラリーによって宣言された未使用の依存関係であることが判明し、Googleビルドシステムが新しい依存関係を完全に自動的に使用したという事実と組み合わされました。これが、Goコンパイラが未使用のパッケージをインポートするときにエラーをスローする理由です。



更新は、変化する依存関係を使用する決定を確認するための自然な時間です。また、そうでない中毒を定期的に確認することも重要です変化しています。セキュリティ上の問題や修正すべき他のエラーがないと考えられますか？プロジェクトは放棄されていますか？たぶん、この依存関係の代替を計画する時です。



また、各依存関係のセキュリティログを再確認することも重要です。たとえば、Apache Strutsは2016年、2017年、2018年に深刻なリモートコード実行の脆弱性を明らかにしました。起動してすぐに更新するサーバーが多数ある場合でも、そのような実績は、使用する価値があるかどうかを示唆しています。

おわりに

ソフトウェアの再利用の時代がようやく到来しました。私は利点を軽視したくありません。それは開発者に非常に前向きな変化をもたらしました。ただし、潜在的な結果を十分に考慮せずに、この変換を採用しました。依存関係を信頼する以前の理由は、依存関係がこれまで以上に多くなると、同時に関連性を失います。



この記事で説明した特定の依存関係の重要な分析は、かなりの量の作業を表しており、ルールではなく例外のままです。しかし、私はすべての可能な新しい中毒のためにこれを行うために本当に一生懸命に働いている開発者がいることを疑います。私は自分の依存関係のいくつかについて、この作業の一部のみを行いました。基本的に、ソリューション全体は次のようになります。「何が起こるか見てみましょう。」あまりにも頻繁に、もっと何かがあまりにも多くの努力のようです。



しかし、CopayおよびEquifax攻撃は、今日のソフトウェア依存関係の使用方法における実際の問題の明確な警告です。警告を無視してはなりません。 3つの一般的な推奨事項を示します。

1. . , , , . , .
2. . , , . , , . , , , .
3. . . . , . , , . , , API. .

良いソフトウェアがたくさんあります。一緒に作業して、安全に使用する方法を見つけましょう。