最近のSonarSourceのセキュリティ研究者による調査結果では、Pip、Yarn、Composerなどの一般的なパッケージマネージャに複数のセキュリティ脆弱性があることが判明している。しかし、パッケージマネージャは、オープンソースのセキュリティチェーンにおける唯一の弱点ではない。InfoQは、SonatypeのCTOであるBrian Foxに話を聞いた。
SonarSource社の脆弱性研究者であるPaul Gerste氏は、悪意のあるパッケージをインストールさせることによって、ハッカーが開発者のマシンを危険にさらすことができる多くの攻撃について説明している。Gerste氏は、Composerにコマンドインジェクションの脆弱性、BundlerとPoetryに引数インジェクションの脆弱性、Yarn、Pip、Composerなどに信頼されない検索パスの脆弱性を発見している。
SonarSourceの調査によると、ソフトウェアのサプライチェーンは多くの企業にとって重要なコンポーネントであり、その安全な運用に不可欠であることが確認されている。
この記事の執筆時点で、PipとPipenvを除くほとんどのパッケージマネージャはすでにパッチが適用されているが、セキュリティについて真剣に考えるなら、アップデートして終わりではない、とGerste氏は言う。
すべてのツールを定期的にアップデートし、未知のソースからのファイルを扱うときは慎重になることを忘れないでください。スクリプトの実行を無効にするなどのセキュリティ機能を備えていても、信頼できないコードベースのパッケージマネージャを使用しないことを強くお勧めします。
今年初め、colorsとfakerという非常に人気のあるJavaScriptパッケージのメンテナが自身のファイルを破損させ、数千のアプリと数百万のユーザに影響を与えたことを考えると、Gersteのアドバイスは真剣に検討する価値がある。Marak Squiresは、自分の破壊行為について、多くの企業がなぜか当然のように行っている無償の仕事の搾取に対する抗議であると説明している。これは、オープンソースソフトウェア上に構築された開発パイプラインの本質的な脆弱性を思い起こさせるものであった。
InfoQは、オープンソースとサプライチェーンセキュリティの関係をより深く理解するために、DevSecOps企業SonatypeのCTOであるBrian Fox氏に話を伺った。
InfoQ：オープンソースは、ソフトウェアの開発方法を変えた大きな成功例であり、ソフトウェア業界の大部分がそれに依存するようになったほどです。最近のnpmライブラリの "colors "と "faker "がメンテナによって破壊された問題は、オープンソースが、ひいてはソフトウェア業界全体が、土足で入る巨人であることを明らかにしているように思います。ここには持続可能性の問題があるのでしょうか？
Brian Fox氏： オープンソースの人気プロジェクトの多くは、実は非常に経験豊富な開発者たちによる大規模なチームで構成されています。しかし、colorsやfakerのように、たった一人でメンテナンスしている小さなプロジェクトもたくさんあります。
その理由は2つあります。1つは、あらゆる規模のプロジェクトにおいて、ソフトウェアを消費するだけで関与しないユーザーやフリーライダーが多く存在することです。第二に、開発者がどのようなプロジェクトを選択すべきかを指示するのに役立つ、組織における十分な可視性とコントロールがないことです。
これは、私たちがプロジェクトのHygiene（衛生状態）と呼ぶことの多いものです。Apache Software Foundation、Eclipse、The Linux Foundationのような財団がスポンサーになっていますか？もしそうなら、持続可能性を確保するための監視が行われている可能性が高いです。そのプロジェクトには、高品質のソフトウェアの実績がありますか？コミュニティはどの程度活発でしょうか？
このような属性を可視化し、ポリシーを定めることで、開発者がよりリスクの低いコンポーネントを選択することができるようになります。
InfoQ：Squiresの行動は決して合理的な抗議の方法とは言えませんが、オープンソースコミュニティの一部には、彼の動機にある程度共感できる部分があることは否定できないでしょう。メンテナの燃え尽き症候群を減らすために、何が貢献できるでしょうか？
Fox氏：確かに、コミュニティの中には彼の動機に共感する人もいますね。先月Apache Software Foundationは、Log4jをきっかけに、積極的に貢献せずに利益を得るダウンストリームビジネスを呼びかけました。最近、コミュニティで起きたもう一つの火種です。
彼らが提案し、私も同意するのは、すでに仕事をしているメンテナにさらなる負担を強いないようにすることです。できる最善の方法は、彼らに手を差し伸べることです。それはコミュニティにお返しをする良い方法であり、その企業はもっと尊敬を集めるでしょう。
InfoQ：企業が、悪意のあるパッケージや脆弱なパッケージによってCIパイプラインが中断されるリスク、あるいはさらに悪いことに悪意のある/脆弱な依存関係が本番環境に流れてしまうリスクを最小限に抑えるために、どのような効果的なプラクティスがあるでしょうか？
Fox氏：ソフトウェア部品表を作成して継続的に更新し、ソフトウェア構成分析（SCA）を含むツールで作業します。SCAとは、プロジェクトに含まれるすべてのコンポーネントを調べ、それらのコンポーネントから潜在的なリスクを判断することです。SCA（Sonatypeを含む）は、アプリケーションのリスクを発見し、特定するためのものです。
これらのツールは、ソフトウェア開発ライフサイクル全体にわたってコンポーネントを監視するために自動化されている必要があります。多くの企業がLog4jのインシデントへの対応があまりにも遅かったという事実は、多くの企業が基本的なことに対応できていないことを思い知らされます。
情報開示に迅速に対応するために、組織内で使用されているコンポーネントを確実に把握することは最優先事項ですが、意図的に悪意を持った新しい脅威をいち早く認識することも不可欠です。この種のコンポーネントは、直ちに害を及ぼすように設計されており、通常、開発者がそれを組み込んでも、コンパイルやテストが通ることさえありません。そのため、悪意のあるコンポーネントは、従来のアプリケーション・セキュリティ・スキャンで発見できるようなコードのチェックインやリリースの前に置き換えられることが多いのです。
このようなコンポーネントを早期に有害と認識できない場合、現在のスキャンや修正プロトコルでは解決できない大きなリスクが生じます。例えば、開発者が誤って悪いコンポーネントを掴んでしまい、バックドアやデータの流出が発生し、その後「問題を修正」してから次に進みますが、すでにダメージを受けていることに気づかないということがあります。