米国防総省、ソフトウェア調達で「OSS」を第一優先とする指針を発表：公務の一環としてOSSに貢献できる

米国防総省（DoD）は、オープンソースソフトウェアコミュニティーへのDoDの参加、貢献、交流に関するガイダンスを示した覚書「ソフトウェア開発とオープンソースソフトウェア」を発表した。OSSを利用するだけでなく、政府職員が公務の一環として、既存のOSSプロジェクトに貢献できるとした。

[＠IT]

印刷

見るPost

Shareシェア

はてなブックマーク

SharePocket Button

　米国防総省（DoD）は、「Software Development and Open Source Software」（ソフトウェア開発とオープンソースソフトウェア）と題する2022年1月24日付の覚書を発表した。

　DoDのCIO（最高情報責任者）、ジョン・B・シャーマン氏が署名したこの覚書は、DoD上層部に宛てたもので、DoDがオープンソースソフトウェア（OSS）コミュニティーにいつ、どこで、どのように参加、貢献、交流するのかを明確にすることを目的に、ソフトウェア開発とOSSに関するガイダンスを提供している。

　DoDは「2018 Department of Defense Cyber Strategy」（2018年米国防総省サイバー戦略）により、可能なときはOSSの使用を増やし、（新規開発よりも）商用の既製ツールを使用する方針を打ち出している。また、近く発表する「Software Modernization Strategy」（ソフトウェアモダナイゼーション戦略）では、適切なスピードでレジリエント（復元力のある、強靭《きょうじん》な）ソフトウェア機能を提供することを中心に据えている。

　「OSSは、ソフトウェア定義型ソリューションの基盤を形成しており、ソフトウェアをより早く提供するために不可欠だ」との認識から、DoDはこの覚書を出した。

懸念事項が2つある

　ただし、DoDは覚書の中で、OSSにはDoDにとって根本的な懸念事項が2つあると指摘している。その1つは、外部でメンテナンスされているコードをDoDの基幹システムに使うと、敵対者が悪意あるコードをDoDシステムに混入する経路ができてしまう可能性があることだ。

続きを読む

　DoDは、「この懸念を解消するには、OSSのサプライチェーンリスク管理（SCRM）を慎重に行う必要がある。また、OSSは他の製品と同様に、SCRMとサイバー脅威テストの厳密な基準を満たす必要がある」との見解を示している。

　もう1つの懸念事項は、DoDのシステムのために開発されたコードを軽率に共有すると、重要なイノベーションが公開されてしまい、敵対者の利益になる可能性があることだ。

　このリスクに対しては、モジュールオープンシステムアプローチ（MOSA）による管理で対応するとDoDは記している。これは、システムがOSSの恩恵を受けられるようにするとともに、重要で革新的なコンポーネントを別個のモジュールとして保護するものだ。

　さらにDoDは、覚書の付属資料2「Guidance on Software Development and Open Source Software」（ソフトウェア開発とOSSに関するガイダンス）で、幅広いOSSコミュニティーへのDoDの参加、貢献、交流に関する詳細なガイダンスを提供している。

ガイダンスには何が書かれているのか

　ガイダンスは4部構成になっている。

（1）概要
（2）オープンソースソフトウェアの使用
（3）オープンソース開発アプローチの使用
（4）オープンソースソフトウェアプロジェクトへの貢献

（1）概要

　この付属資料はOSSと、DoDのソフトウェア開発へのOSSの影響に関するガイダンスを提供する。一般に、カスタムソフトウェアは既存コンポーネントから構築される。既製のOSSコンポーネントは何百万にも上るため、DoDがOSSをどのように使用するかは、DoDのソフトウェア開発全体に大きな影響を与える。

（2）オープンソースソフトウェアの使用

・「採用、購入、開発」のアプローチ

　DoDはソフトウェアに関して、「採用、購入、開発」のアプローチを取らなければならない。これは、プロプライエタリな製品を購入する前に、政府やOSSの既存ソリューションを優先的に採用し、既製ソリューションが適切でない場合にのみ、非商用ソフトウェアを新たに開発するというものだ。

・プログラムマネジャーの役割

　プログラムマネジャーは、プログラムで使用される既製コンポーネントの適合性について最終的な責任を負う。この責任には、既製コンポーネントの使用に伴うリスクを許容範囲内に収めるように管理することが含まれる。コンポーネントの選択と適合性の評価がシステムインテグレーターに委託されている場合、プログラムマネジャーは契約の文言、了解覚書（MOU：memorandum of understanding）、合意覚書（MOA：memorandum of agreement）、政府インテグレーターに対する指示ガイダンスを通じて、これらに関する説明責任を確立する必要がある。

・OSSコンポーネントに固有の課題

　OSS開発は共同作業であるため、サプライチェーンのリスク管理においては、OSSコンポーネントに固有の課題がある。プログラムマネジャーは、サポートエンジニアや上級幹部、組織のCIOと協議し、これらの課題を考慮した上で、OSSの適合性を判断する必要がある。こうしたOSSコンポーネントに固有の課題には次のようなものがある。

・長期的なサポート
・信頼できるソース
・依存関係
・コンポーネントのセキュリティ
・コンポーネントの完全性
・外国政府の影響

（3）オープンソース開発アプローチの使用

・カスタム開発ソフトウェアのOSSとしての公開

　カスタム開発された（つまり、非商用の）ソフトウェアをOSSとして公開するには、DoDはまず、そのソフトウェアのソースコードの提供を受ける必要がある。連邦ソースコードポリシーと公法により、DoDは一部のカスタム開発ソフトウェアをOSSとして公開することを義務付けられている。同様に、合衆国法典に基づき、非商用コンピュータソフトウェアを調達する計画では、ソフトウェアのソースコードと関連資料について、最大限に調達し、提供を受けなければならない。

・非商用ソフトウェアのソースコードなどの取得

　プログラムマネジャーは、非商用ソフトウェアのライフサイクル全体で開発やテスト、運用、メンテナンスのために必要となる、非商用ソフトウェアのソースコードや関連データ、関連ライセンス権の取得を計画しなければならない。

・重要な技術を実装するソフトウェア開発の分離

　政府のソフトウェア開発プロジェクトのマネジャーは、重要な技術を実装するソフトウェアの開発と、ビジネスプロセスや同様の機能の日常的な自動化とを分離する必要がある。

　重要技術のソフトウェア実装と日常的な自動化の分離は、合衆国法典で定義されているMOSAに反映されなければならない。一般に、プログラム全体を重要技術として保護すべきではなく、実際に新規の進歩を遂げたコンポーネントのみを保護すべきだ。

（4）オープンソースソフトウェアプロジェクトへの貢献

・職員と契約業者の貢献

　DoDが使用するOSSプロジェクトへの職員の参加は、多くの場合、政府の利益になる。また、一般に政府が当該ソフトウェアを直接、政府システムの構成要素として、または政府インフラの構成要素として使用する場合、政府のリソースの正当な使用となる。

　例えば、政府職員は最初に上司と相談して、運用セキュリティ（OPSEC）を維持し、政府の利益を促進する貢献のために常識的なアプローチで取り組む限り、公務の一環として、既存のOSSプロジェクトに貢献できる（主要メンテナとしての貢献を含む）。

　また、契約業者は政府の業務監督者が、契約の範囲と規定に従い、当該活動が政府の利益になると認めた場合、政府の費用でOSSプロジェクトに貢献できる。

・OSSプロジェクトのDoDバージョンの回避

　どんな理由でも、OSSプロジェクトの独立したDoD固有のバージョンを作成することは、サポートのリスクを増大させるため、可能な限り回避しなければならない。