ソフトウェア構成分析ツールによるPython Poetryパッケージマネージャーとセキュリティの統合

パッケージマネージャーは、脆弱な依存関係との戦いにおける究極の武器になり得ると、私は常々考えてきました。パッケージマネージャーを活用して脆弱な依存関係をスキャンできれば、脆弱性がビルドプロセスに入り込んでしまう前に、開発者は依存関係に潜む脆弱性をより簡単かつ迅速に特定し、修正できるようになります。

ただし、これを実現するには、ソリューションが次の条件を満たす必要があります。

1. シンプル — とても簡単に使えること

2. 統合されている — 開発者のワークフローや、対象のパッケージマネージャーと連携して動作すること

最近、PythonのPoetryパッケージ管理システムを使い始めました。構成や、掲げている目標を実現する方法がとても気に入っています。そのため、Poetryに統合できるセキュリティスキャン機能があればいいなと思っていました。

そんな折、SnykがPoetryパッケージマネージャーとpoetry lock syntaxをサポートする新機能を導入したと聞き、うれしく思いました。これがどのように機能するのか詳しく確認するため、新しく作成したSnykのテストアカウントにサインインし、意図的に脆弱な依存関係をいくつか含む新しいプロジェクトを作成しました。

Play Video: DevSecOps with Poetry and Source Composition Analysis

Poetry snykという新しいプロジェクトを作成するコマンドを入力すると、「poetry snyk」というディレクトリとpoetry_snyk というパッケージが作成されました。基本的なひな形とTOMLパッケージが用意されます。

poetry_snykに移動してtree,を実行すると、ルートパッケージ名poetry_snykが記載されたREADMEが表示されます。TOMLファイルはPoetryの設定ファイルで、ひな形のテストも含まれています。つまり、作成された簡単なテストです。

TOMLプロジェクトを見ると、Python 3.7を使っています（少し古いバージョンであることは認めますが、依存関係の都合で、ローカルではこのPythonバージョンを使用しています）。また、テスト用の開発依存関係としてpi testを使っています。この場合はpi test 5.2 versionです（3.7はpi core Pythonのバージョンで、これにはビルドもありますが、私は使っていません）。

Poetryについて知っておきたいのは、TOMLファイルが、従来必要だったrequirements.txtとsetup.pyの代わりになるということです。つまりPoetryでは、依存関係の設定と追跡だけでなく、パッケージをビルドしてPythonチーズショップに公開することもできます。TOMLファイル1つでsetup.pyとrequirements.txtの両方を置き換えられるのは、とても興味深い点です。

以前のパッケージマネージャーと比べてPoetryの気に入っている点は、継ぎはぎのソリューションではなく、統合されたソリューションとして使えることです。

以前使っていたパッケージマネージャーの多くは、Pipenvも含めて、不完全だと感じていました。pipパッケージマネージャーのコードベースに機能を追加した、単なるラッパーのようなものだったからです。Poetryは、npmの優れた点である設定ファイルとロックファイルを、RustのCargoパッケージ管理システムと組み合わせることで、問題を捉え直し、さらに一歩進めていると思います。RustのCargoパッケージマネージャーには、ドキュメントとテストが最初から用意されています。Poetryはこの2つを組み合わせ、そのアプローチを実現しようとしているのだと思います。

新しいPoetryプロジェクトpoetry_snykを作成し、プロジェクトの設定もできましたが、ライブラリをインストールして動作させる必要があります。Snykと連携して使うため、以前から知られている脆弱なライブラリを使ってテストし、スキャン時にSnykが検出できるか確認したいと思います。Snykが動作するには2つのファイルが必要です。次のコードで、プロジェクトに依存関係を追加してみましょう。

これはdocx project python.xプロジェクトで、docxファイルの解析と作成ができます。XML外部実体に関する脆弱性があります。かなり深刻な脆弱性で、トレーニングセッションでも何度かデモを行っています。

悪意のあるWord文書に、/etc/passwdのような値を設定したXMLエンティティ変数が含まれていると、docxライブラリがそのエンティティを解決し、ローカルファイルインクルージョンにつながります。さらに、リモートコード実行のエクスプロイトに発展する可能性もあります。ここではこれをインストールします。すると依存関係と、その入れ子になった依存関係が解決されます。TOMLファイルも更新され、poetry.lockファイルが追加されます。このpoetry.lockには、最上位の依存関係に含まれるすべての依存関係が記録されます。

スキャンツール、特にSnykをはじめとする多くのソースコード分析ツールやパッケージ分析ツールが、入れ子になった依存関係を分析するには、必要な依存関係がすべて記録されていることが重要です。

入れ子になった依存関係だけでなく、使用するバージョンとハッシュ値も記録されるため、依存関係を正確に固定できます。これはPythonエコシステムの大きな課題でした。デフォルトのPython依存関係マネージャーであるpipは、これらの詳細をすべて提供せず、依存関係を列挙するだけで、バージョンを正確に固定していませんでした。そのため、サブ依存関係を適切に管理できていませんでした。

Poetryで別のパッケージをインストールするとします。ここでは、脆弱なPythonパッケージpyyamlをもう1つインストールします。安全でないデシリアライゼーションの脆弱性があるバージョン3.13を使います。この脆弱性が悪用されると、攻撃者が対象アプリケーションの環境でリモートコードを実行できる可能性があります。これをインストールすると、TOMLファイルとロックファイルも更新されるはずです。

次のコードを入力して、Snykで監視してみましょう。

すべての依存関係が分析されたようです。これが私のSnykプロジェクト、つまりSnyk組織です。作成したすべてのプロジェクトが一覧表示されており、今作成したプロジェクトも確認できます。

ご覧のとおり、問題が検出されており、いずれも重大度の高いものです。pyyamlの安全でないデシリアライゼーション、pyyamlにおける同じリモートコード実行（よく知られた深刻なエクスプロイトです）、そしてpython-docxのXML外部実体インジェクションも検出されています。包括的なデータベースとシンプルな統合のおかげで、Snykはこのプロジェクトで使用している依存関係の脆弱性をすべて検出できました。

利用を開始する

このインテグレーションを使い始めるには、Poetryプロジェクトをインストールするだけです。そうすればSnykがその時点でプロジェクトを追跡できます。依存関係についてメール通知も届くので、とても便利です。

Poetryプロジェクトをすぐに設定し、Snykでセキュリティ上の問題をスキャンして、その影響について詳しいレポートを確認できました。

このインテグレーションを動作させるには、ロックファイルとTOMLファイルの両方が必要です。