| layout | title | level | type | tags | pitch |
|---|---|---|---|---|---|
col-sidebar |
OWASP Top 10 Risks for Open Source Software |
2 |
documentation |
top-10, open source, security, operations |
Top-10 security and operational risks related to using OSS. |
OWASP Top 10 Risks for Open Source Software / index.md の翻訳。 ライセンスは原文書のCC BY-SA 4.0。
ソフトウェアサプライチェーンにおいてはOSSへの依存度が高いにも関わらず、OSSのリスクについて理解したり測定する貯めの方法はありません。 OSSのリスク管理はライセンスの管理から始まりその後CVEの管理へと進化しましたが、セキュリティ、法律、運用を含む包括的なリスク管理はまだ不足しています。このドキュメントによって、業界の専門家やリーダーと協力し、それが作られることを期待しています。
この10年のOSSへの依存により、CVEの充てられている既知(公知)の脆弱性がセキュリティの重要な指標となってきました。 これらCVEが充てられた公知の脆弱性は重要なシグナルではありますが、一般的には善意の開発者によるミスを補足しています。 これらのミスは攻撃者により悪用される可能性があり修正されなければなりませんが、OSSに依存することに含まれるリスクの全てというわけではありません。
古いソフトウェアやメンテナンスされていないソフトウェアによってもたらされるリスクや、名称を混乱させることによる直近のサプライチェーン攻撃などの運用リスクは、CVEでは捉えることができません。 これらのリスクは、最近の Synopsys による オープンソースセキュリティとリスク分析レポート でも強調されるように、重大なものです：
- コードベースの89%には４年以上前の古いものが含まれています
- コードベースの91%には２年以上新しく開発が行われていないコンポーネントが含まれています
Endor LabsのStation 9研究チームによる 依存関係管理の現状 では、脆弱性の95%が従属的な依存関係(開発者が選択したOSSによって自動的に導入されるソフトウェアパッケージ群)に存在すると明らかにしました。 そしてそれらの多くは実際には連絡が取れないか、更新された場合には非互換性による破壊的な影響を与える可能性があります。 20人以上のCISOとCTOからの査読と協力を得たこのリストにより、運用とセキュリティの両方でセキュリティチームと開発チームが備えるべき上位のリスクを見つけようとしました。
OSSに関するトップ10のリスク:
- OSS-RISK-1 既知の脆弱性: コンポーネントのバージョンには、そのコンポーネントの開発者によって誤って導入された脆弱なコードが含まれている可能性があります。脆弱性の詳細は、CVE、GitHub Security Advisoriesやその他の非公式なコミュニケーションチャネルなどを通じて公開されます。エクスプロイトコードとパッチは利用できる場合とできない場合があります。
- OSS-RISK-2 正規パッケージの侵害: 攻撃者は、悪意のあるコードをコンポーネントに注入するために、既存の正規のプロジェクトの一部やコード配布システムなどのリソースを侵害する可能性があります。 例えば正規のプロジェクトメンテナーのアカウントを乗っ取ったり、パッケージリポジトリの脆弱性を悪用することなどが考えられます。
- OSS-RISK-3 名前の混乱による攻撃: 正規のOSSやシステムコンポーネントによく似た名前のコンポーネントを作成したり(タイポスクワッティング)、信頼できる作者のように示唆したり(ブランドジャッキング)、異なる言語やエコシステムでの一般的な命名パターンを利用する(コンボスクワッティング)などが考えられます。
- OSS-RISK-4 メンテナンスされていないソフトウェア: コンポーネントやそれらの特定のバージョンが積極的に開発されなくなっている可能性があり、そのため、元のOSSプロジェクトから機能的、非機能的いずれのバグもパッチがタイムリーに提供されない(あるいは全く提供されない)可能性があります。
- OSS-RISK-5 古いソフトウェア: プロジェクトに古いバージョンのコンポーネント(新しいバージョンが存在するにも関わらず)が使われている可能性があります。
- OSS-RISK-6 追跡されていない依存関係: 例えば、それが上流コンポーネントのSBOMの一部ではない、SCAツールが実行されていない、SCAツールで検出されない、パッケージマネージャーを用いての依存関係の確立ができていないなどによって、 プロジェクト開発者がコンポーネントの依存関係に全く気づいていない可能性があります。
- OSS-RISK-7 ライセンスのリスク: コンポーネントやプロジェクトにライセンスが全くない、意図している使用方法と互換性がない、要件を満たしていない、満たせない可能性がある。
- OSS-RISK-8 未成熟なソフトウェア: オープンソースのプロジェクトでは、 例えば標準的なバージョン管理スキームを使っていない、レグレッションのテスト群やレビューガイド、ドキュメントがないなど、開発のベストプラクティスが用いられていないことがあります。結果的に、コンポーネントが確実、セキュアに動作しない可能性があります。
- OSS-RISK-9 未承認の変更: 例えば、ダウンロードリンクがバージョン管理されていないリソースを使用していたり、バージョン管理されたリソースでも変更や改ざんが行われていたり、安全でないデータ転送が行われたり等により、 開発者が変更に気づいたりレビューや承認したりできないままコンポーネントが変更される可能性があります。
- OSS-RISK-10 過大/過小な依存関係: コンポーネントは非常に少ない機能(例: npmマイクロパッケージ)を提供することや、多くの機能(一部の機能だけが使用される場合もある)を提供することもあります。
To better understand how these risks may affect us, let us quickly review some basic concepts of dependency management using a simple example. Just skip this section if you're familiar with dependency management.
The root node of the dependency graph displayed below represents the example project. The child nodes of the root represent 9 open source components the project "directly" depends on. Those components, however, depend on other components as well, all of which become "transitive" or "indirect" dependencies from the perspective of the top-level project.
Direct dependencies are consciously selected by the project developers, e.g., through the declaration in a manifest file such as package.json (Node.js/npm) or pom.xml (Java/Maven) file. Package managers take care of downloading and installing those direct dependencies from 3rd party package repositories to the developers workstation or a CI/CD system. When doing so, package managers also identify transitive dependencies, resolve potential version conflicts and install them locally. In other words, plenty of components are downloaded in an automated fashion in order to make sure all code required by the example project (and more) is present on the developer machine.
This high degree of automation boosted the reuse of open source components in today's software development. As a result, large portions of modern software have not been specifically developed for an application at hand, but come from generic open source projects. Looking again at the dependency graph, it is not surprising that the ratio of code written for the project itself (the root node) to the code of open source components is 1:4 or less. And we haven't even touched upon IDEs, build tools etc.