コードには何が隠されているのでしょうか?

単純なプロジェクトであっても急速に膨れ上がる傾向があり、既存のコードやノード ライブラリを簡単に組み込むことができるため、その傾向はさらに高まります。

そのコードを作成しているのが自分だけである場合はまだある程度管理可能ですが、通常の場合のように、コードが多数の開発者やチームによって作成されている場合はさらに難しくなります。

すべてのプル リクエストの承認を担当するチーム リーダーでさえ、コードのすべての行、すべての関数、すべての変数を把握しているわけではありません。

信頼の問題

これが、2020 年末に Orion アプリでマイナーなコード変更が行われた理由の XNUMX つです。 ソーラーウィンズ、 長い間検出されませんでした。変更全体はわずか数十行のコードであり、非常にうまくいきました。 元のクラス内に隠蔽される.

変更された製品は適切に署名されていたため、それを疑う理由はなく、開発チームはコードの所有者を信頼していました。

つい最近になって、故宮に「」という制度があったことを知りました。論理的欠陥」により、悪意のある攻撃者が不正なライブラリを正規のものとして偽装できるようになりました。基本的に、NPM では、ユーザーに通知したり同意を得ることなく、誰でもパッケージのメンテナーとして追加できました。 

これにより、マルウェアが混入したパッケージを作成し、信頼できる人気のあるメンテナに知らないうちにそれらのパッケージを割り当てることが可能になりました。信頼が間違っている場合は、コードに問題のある脆弱性が隠れている可能性があります。

考慮すべきもう 1 つの一般的な方法は、開発者が既存のライブラリまたは StackOverFlow からコードをコピーして貼り付けて、独自のコードで使用したり、新しいライブラリに再アップロードしたりすることです。そうすることで、現在は基本的に追跡されていない、安全でない脆弱なコードもコピーされる可能性が高まります。元のコードが CVE を受けて最終的に修復されたとしても、コピーした問題のある関数は目に見えず、今後何年にもわたってそれを使用するコードベースを汚染する可能性があります。 

カンザス大学で行われた最近の研究では (「フォークって何？ npm で隠されたコード クローンを見つける」）、研究者らは、十分に精査されたパッケージの使用であっても安全ではない可能性があることを説明しています。

あなたはそれについて何ができますか？

したがって、ベンダーの署名付き製品やアップデートは信頼できません。外部ライブラリやコードが組み込まれているため、独自のコードがすでに変更または追加されている可能性があります。では、システムに悪意のあるファイルがインストールされていないことを本当に確信するにはどうすればよいでしょうか?

あなたができることはいくつかあります：

1. 組み込む各ライブラリ所有者またはプログラム ベンダーに完全な SBOM を要求します。 SBOM は、ライブラリまたは製品内のすべての「成分」が何であるかを確認するのに役立ちます。さらに、SBOM にリストされていないものをライブラリまたは製品で見つけた場合、それは疑わしいと見なされます。 SBOM とは何かについて詳しく学ぶことができます こちら.
2. ベンダーまたはライブラリ所有者に、整合性チェックが行われ、期待どおりの結果が得られているという信頼できる証明書を要求します。ベンダー自身の保証だけを信頼する必要はありません。
   
3. パッケージをインストールするときは、npm CLI フラグを使用します --ignore-scripts インストール段階でサードパーティのパッケージからスクリプトが実行されるのを避けるため。
4. 使用 パッケージロック.json パッケージのバージョン番号をロックするファイル。を使用するときは、 パッケージロック.json 使用しているパッケージのバージョンをロックするだけでなく、その依存関係もロックすることになります。リスクは、さまざまなバグの修正が含まれる可能性のある自動パッケージ更新を取り込まないことです。ただし、特定のバージョンを検証するために労力を費やし、最初にそれを検証せずに他のものを含めたくない場合は、バージョン番号をロックすることが最善の選択肢です。

フォロー 新しい規制、ほとんどの人が近い将来 SBOM の使用を開始すると予想されます。 SBOM やその他の証明書を求める企業が増えれば増えるほど、準拠しなければならない組織や保守者も増えます。