Flow-Wiser、メンテナンス終了のFlowiseを引き継ぎ、公式Dockerタグと実際のパッケージバージョンが一致しない可能性を指摘

Flowiseが積極的な開発を終了し、上流リポジトリをアーカイブした後、コミュニティフォークのFlow-Wiserは3.1.4-fw10をリリースし、再配布可能でセルフホストできる後継版の提供を試みている。このフォークは、元のプロジェクトで商用ライセンスが適用されていたエンタープライズモジュールを削除し、ローカルのユーザー名・パスワード認証、SSO、TOTP MFA、拒否を優先する82項目の権限、組織およびワークスペースの分離、監査、AES-256-GCMとHKDFによるデータ暗号化を独自に実装した。ビルドプロセスには、ライセンスファイルのスキャン、パッケージバージョンのアサーション、CIゲートも追加された。メンテナーによると、リリースコミットは974件のテスト、lint、コンパイル、Cypressを通過したという。ただし、現時点でこれらの数値は主にプロジェクト自身の報告に基づいており、独立した監査はまだ行われていない。

セルフホスト運用チームがさらに注意すべきなのは、コンテナのサプライチェーン問題だ。Flow-Wiserのメンテナーは調査の結果、公式に3.1.3および3.1.4とタグ付けされたDockerイメージでも、内部の`flowise`サーバーは依然として3.1.2だと主張している。原因として考えられるのは、Dockerfileがバージョンを指定せずに`npm install -g flowise`を実行しており、そのレイヤーがキャッシュされたまま、タグの更新時に更新されなかったことだ。Docker Hubでは、これらのタグとイメージが実際に存在することは確認できるが、公開メタデータだけではコンテナ内部のパッケージバージョンを検証できない。そのため、この発見についてはユーザー自身による再現確認が必要となる。エンジニアリングチームは`/api/v1/version`を呼び出し、イメージのdigestを照合するとともに、CIでコンテナ内の`package.json`を検査すべきだ。タグをパッチ適用の証明と見なしてはならない。

Flow-Wiserへの移行も、リスクのない置き換えではない。新しいコミュニティによって保守されており、元のベンダーやFlowiseを買収したWorkdayとは無関係だ。また、コードの実行は現在も非推奨となった`vm2`に依存している。設定によって既知のエスケープ経路は遮断されているものの、強固なセキュリティ境界ではない。今後は、旧イメージのバージョン不一致を第三者が再現できるか、新しい認証機能とテナント分離に対するセキュリティレビューが実施されるか、そしてこのフォークが継続的なリリース体制と脆弱性対応プロセスを確立できるかを注視する必要がある。