金融業界のオープンソースガバナンス：中国五当局「意見」から実装フレームワークへ

金融機関は中国におけるオープンソースの最大級のエンタープライズユーザーであり、同時に規制要求が最も明確な業界でもある。2021 年 10 月、中国人民銀行など五当局は「金融業のオープンソース技術の応用と発展の規範化に関する意見」を共同で発布し、「オープンソースをどう使うか」をエンジニアリングのベストプラクティスから監督上の期待事項へと引き上げた。3 年余りが経ち、多くの機関は制度を整備したが、制度とエンジニアリングの間の落差は依然として常態である。

規制文書の 4 つのキーワード

資産の全容把握。金融機関はオープンソース技術の利用状況を全面的に把握しなければならない——エンジニアリングの言葉に訳せば、どのシステムがどのコンポーネントをどのバージョン・どのライセンスで使っているか、常時照会可能で継続更新される台帳を持つということだ。手作業の Excel 台帳では「全面的」を満たせない。オープンソースがシステムに入り込む経路は依存宣言だけではないからだ。外部委託の納品物、コピー＆ペースト、ベンダーのブラックボックス内の静的リンク——いずれも台帳の盲点である。

導入前評価。セキュリティ・コンプライアンス・持続可能性を導入前に評価する。既知の脆弱性の有無だけでなく、ライセンス義務がビジネス形態と衝突しないか、コミュニティは健全か、供給停止・開発停止のリスクはないかを見る。

全ライフサイクル管理。導入・利用・更新・退役のすべてに管理アクションを設け、とりわけ脆弱性とバージョン状態を継続的に追跡する。今日安全なコンポーネントが明日には重大ニュースになりうる。

緊急対応と出口。緊急対応メカニズムを構築し、高リスク依存には代替案を用意する。Log4Shell の夜、「影響を受けるシステムはどれか」に 1 時間で答えられた機関と 2 週間の調査を要した機関の差は、対応計画書の出来ではなく、台帳とツールの日常的な蓄積だった。

実装フレームワーク：台帳・アドミッション・監視・対応の四位一体

台帳レイヤー：SCA プラットフォームで全コード資産（内製・委託・購買）からコンポーネント台帳と SBOM を自動生成する。スニペットレベル検出がコピーや改名コードをカバーし、ソースのないベンダーシステムはバイナリ成分分析で補完する。金融機関の基幹システムの多くはベンダー製であり、この一環を欠けば台帳は資産の半分しか覆えない。

アドミッションレイヤー：評価を「専門家レビュー会議」からスキャンゲートへ工業化する。ライセンスポリシーマトリクス（ライセンス種別 × 利用形態 × 許可/審査/禁止）、脆弱性閾値、コミュニティ健全性指標をツールに設定し、通常案件は自動判定、専門家は境界事例だけを扱う。

監視レイヤー：台帳は年次文書ではなくリアルタイムビューである。新しい脆弱性インテリジェンス（CVE/CNVD/CNNVD と早期予警）を利用中コンポーネントに自動照合し、命中すれば影響範囲つきで警報する——「継続的追跡」のエンジニアリング上の意味はこれだ。

対応レイヤー：対応計画の中核資産は「影響範囲に分単位で答える能力」である。年 1 回以上のオープンソース緊急演習を推奨する。重大 CVE を無作為に選び、情報到達から全影響システム特定までの所要時間を測る——この数字は計画書のページ数よりはるかに正直だ。

よくある 2 つの誤り

ベンダーのコンプライアンス約束を自らのコンプライアンスと見なすこと。規制義務は金融機関自身に課される。ベンダー契約のオープンソース条項（SBOM 提供、ライセンス保証、対応 SLA）は必要だが、検収時にツールで納品物を検証して初めてループが閉じる。当社が金融プロジェクトの監査で発見したライセンス問題は、まさに「GPL 不使用を保証する」と契約に書かれた納品物の中にあった。

ガバナンスを制限と同一視すること。規制の方向性は「規範化された利用＋参加の奨励」であり、オープンソースの一律禁止は非現実的であるうえ規制適合でもない。成熟したガバナンスとは、明確な境界の中でエンジニアリングチームが自由に使える状態を作ることだ。境界が明確で自動化されているほど、利用効率はむしろ上がる。

金融業界のオープンソースガバナンスに神秘はない。真実の台帳が一冊、自動化されたゲートが一つ、リアルタイムの監視が一式、年次演習が一回。規制文書は方向を示した。残るはエンジニアリングの実行力である。