自社のオープンソースセキュリティポリシーを策定するための方法：品質の向上、技術的負債の減少などのメリットを得るためには

オープンソースソフトウェアを使用すると、セキュリティと知的財産に関する懸念が持ち上がる。本稿では、適切な決定を下し、後悔する事態に陥らない方法を考える。

[George Lawton，TechTarget]

　オープンソースソフトウェア（OSS）のライブラリは、開発チームが新しいアプリケーションを迅速に展開するのに役立つ。だが、その利用によって引き起こされる可能性のあるリスクについても認識しておく必要がある。そのためには、脆弱（ぜいじゃく）性の解決に必要な労力を減らし、データ損失にまつわる問題を軽減することを目的に適切なポリシーを策定する。

　「OSSを利用することは、基本的には自社の製品やサービスに他人のコードを組み込むことに他ならない」と話すのは、Synopsys Software Integrity Groupでソフトウェアサプライチェーンリスク戦略部門の責任者を務めるティム・マッキー氏だ。

　オープンソースのコードには、オープンソースライセンスの形式で権利と義務が伴う。だが、OSSの作成、テスト、管理手法にまつわるリスクも存在する。オープンソースのコンポーネントを利用する際のポリシーを明確に定めておかないと、知的財産やサイバーセキュリティに対する懸念が持ち上がる。

　オープンソースポリシーでは、ソフトウェア開発プロセスのセキュリティを確保し、効率を高めるために、オープンソースの用途、ワークフロー、役割を明確にする。「オープンソースセキュリティポリシーは、ソフトウェア開発ライフサイクル全体にわたってオープンソースコンポーネントを選定、利用、監視、更新、削除するに当たっての開発者の指針になる」と話すのは、OSSとソフトウェアのサプライチェーンのセキュリティ確保を目的とするプラットフォームを開発するEndor Labsでセキュリティ研究者として働くヘンリック・プレート氏だ。個々の開発メンバーがオープンソースを場当たり的に調整なく利用するのとは対照的に、ポリシーはオープンソースの利用についての構造的かつ系統的なアプローチを表す。多種多様な高レベルの目標を確実に実現するため、ポリシーではオープンソースの利用に関する要件、規則、条件を定める必要がある。

　また、自社の核となる事業目標を達成するのに役立つ一連の指針も規定する。プレート氏は、「オープンソースを利用する際の指針となる原則と、それを可能にする実践方法にチーム全員が従うことで、自社にメリットがもたらされる」と話す。

オープンソースセキュリティポリシーに盛り込む項目

　オープンソースポリシーでは、OSSの利用者がオープンソースのコンポーネントを使用するライフサイクル全般にわたって適切な判断を下すのに役立つ枠組みを確立する。ポリシーでは、オープンソースのライフサイクルにおける選定、使用、廃棄という3つのフェーズそれぞれに対応することをプレート氏は推奨する。

　選定フェーズでは、どのタイプのOSSを利用するかを検討する。使用フェーズでは、ソフトウェアの総保有コストを検討する。例えば、ライブラリに対して社内でメンテナンスを実施する必要があるかどうかを検討する。ライブラリのメンテナンスを実施する活発なコミュニティーがなければ、メンテナンスコストは自社で負担することになる。使用するOSSが公開されてから最低でも90日以上経過していることも確認しておきたい。廃止フェーズでは、既知のセキュリティの脆弱性にコミュニティーが対処していない場合など、オープンソースコンポーネントの使用を中止するタイミングを定めることも重要だ。

　優れたポリシーは、OSSの用途や対象範囲が変化することで生じるリスクを抑えるのにも役立つ。「開発当初はOSSを社内の用途のみに使用する計画を立てても、その後新たな事業モデルを生み出す目的で商用化が決められるケースをよく見かける」と語るのは、インドのIT企業Tata Consultancy Servicesでサイバーセキュリティプラクティス部門のセキュリティツールおよびエンジニアリングセンターオブエクセレンスの責任者を務めるプラシャント・デオ氏だ。商用化によって知的財産やセキュリティに影響が生じる可能性があるため、OSSの用途、変更、配布を規制するポリシーを用意することが重要になる。

　デオ氏は、オープンソースのセキュリティポリシーでは以下の要素に対処することを推奨する。

• IT担当、アプリケーション開発セキュリティ担当、リスクとコンプライアンス担当など、各関係者の役割と責任
• オープンソースの全コンポーネントとそのアップデートに関係する脆弱性を継続的に監視するプロセス
• ソースコードリポジトリメンテナンスのセキュリティ確保、チェックインとチェックアウトのセキュリティ確保、変更管理、リリース管理といったソフトウェア管理のベストプラクティス
• ソフトウェア部品表（SBOM）を最新状態に保つと同時に、ライフサイクル全体（取得、使用、配布、保管、更新、廃棄）にわたってソフトウェア資産を追跡するメカニズム
• 全てのコンポーネントに潜む可能性のあるセキュリティの課題の可視性を高めることを目的とするソフトウェア構成分析など、オープンソースコンポーネントのセキュリティを検証するプロセス

セキュリティとコンプライアンスの優先順位を効果的に設定する

　オープンソースの全てのコンポーネントにポリシーを適用する管理を組み込むことも重要だ。Sonatypeでフィールド最高技術責任者（CTO）を務めるイルッカ・トゥルネン氏は、SBOMを作成し、存在するコンポーネントをカタログにすることをチームに推奨する。ポリシーの要件に照らしてこのSBOMを分析し、潜在的に機密度が高いユースケースやその他のプライバシーリスクを特定する。

　トゥルネン氏によると、オープンソースセキュリティポリシーの最大のメリットは、開発チームに可視性をもたらし、採用するオープンソースを先を見越して適切に選定できるようになることだという。また、アプリケーションの品質も向上し、技術的負債の量も減少する。技術的負債は、管理対象外の依存関係が導入されることで徐々にメンテナンスが制御不能になっていくことで生じる。

　ただし、チームはポリシーの導入作業を慎重に進め、開発者に新たな問題を持ち込んだり、開発プロセスに摩擦が生じたりすることがないようにする必要がある。「文化が変わるのと同じで、ポリシーがない状態からポリシーが適用される状態に移る際には痛みを伴う可能性がある」とトゥルネン氏は語る。例えば、新たなポリシー適用ツールを稼働させると、多数のセキュリティアラートが生成され、これに対応するための新たなプロセスが開発者に求められる。プロジェクトを開始するには、適切な意図と透明性の高い期待値が不可欠だ。

　結局のところ、ポリシーを作成することは、オープンソースを採用する際に開発者個人と開発チームが下す必要のある決定を形式化することにほかならない。また、チームが新たに生まれる問題を解決することではなく、価値を生み出すことに専念できるように、採用のプロセスを自動化できる機会を探すことも重要だ。

　「こうしたことがうまくできている開発チームは、その作業に1日何時間も費やすのではなく、日常のエンジニアリングプロセスの一環としてうまく組み込んでいる。セキュリティ脆弱性の問題は、脆弱性の存在ではなく、その脆弱性にいかに素早く対応するかにある。悪用される脆弱性の大半は、数年以上前から存在している」（トゥルネン氏）