米国政府機関間でのソースコード共有を義務化する法案が成立
(fedscoop.com)- ジョー・バイデン大統領が12月23日に SHARE IT Act に署名し、米連邦政府機関は重複した開発契約を減らすため、カスタムソースコードを相互に共有しなければならなくなった
- 連邦政府が毎年ソフトウェア購入に費やしていると推定される 約120億ドル を削減するため、機関ごとのカスタムコードを公開リスト化し、再利用可能にすることが中核となる
- 法の適用対象からは 機密コード、国家安全保障システム、共有時に個人情報リスクがあるコードが除外される
- 各機関のCIOは施行後 180日以内 に、ベストプラクティス準拠、メタデータ公開、標準化された報告手順を含む実施ポリシーを策定しなければならない
- Atlassian と GitLab Inc. が法案を支持し、法案は12月に上下両院で記録投票なしに可決された
SHARE IT Actのコード共有義務
- Source Code Harmonization And Reuse in Information Technology Act、または SHARE IT Act は、連邦政府機関がカスタム開発したソースコードを他機関と共有することを求める法律
- すでに他機関向けに開発されたコードを知らずに再び契約して作る 重複開発 を減らすことに焦点を当てている
- 各機関はカスタムコードを公開で一覧化し、他機関がそのコードを活用できるようにしなければならない
予算削減目標と適用除外
- 法案の支援者らは、連邦政府が毎年ソフトウェア購入に 約120億ドル を支出していると見積もっている
- SHARE IT Act は、カスタムコードの再利用を通じてこのコストを削減しようとする法案
- 次のコードは法の適用対象から除外される
- 機密コード
- 国家安全保障システム
- 共有した場合に個人情報リスクが生じる可能性のあるコード
各機関CIOの180日以内のポリシー策定義務
- 各機関の最高情報責任者（CIO）は、法律施行後 180日以内 に SHARE IT Act の実施ポリシーを策定しなければならない
- ポリシーには次の手順が含まれなければならない
- カスタム開発コードが ベストプラクティス に適合することを保証する手順
- カスタムコードのメタデータを公開で提供する手順
- 標準化された 報告手順
公開すべきメタデータ
- 法律でいうメタデータには、カスタムコードの開発・共有状況を確認できる情報が含まれる
- 含まれる項目は次のとおり
- カスタムコードが契約に基づいて開発されたかどうか
- コードがリポジトリで共有されたかどうか
- 契約番号
- コードが共有されたリポジトリへの ハイパーリンク
立法の経過と業界の支持
- 法案は上院で Ted Cruz と Gary Peters、下院で Nicholas Langworthy と William Timmons が提出者となった
- 上下両院は12月に記録された賛否投票なしで法案を可決した
- Langworthy による9月の下院提出発表によれば、Atlassian と GitLab Inc. が法案を支持した
- Atlassian の法務責任者 Stan Shepard は、カスタムコードの協業と共有拡大が、連邦組織全体のオープン性、効率性、イノベーションを促進するとみている
1件のコメント
Hacker News の意見
政府での経験がないと、これがなぜこれほど難しいのか実感しにくいかもしれない。軍は内部ソフトウェアにアレルギーがあり、軍のITは世界最高レベルの国家支援を受けた侵入者たちから毎日攻撃される、まったく別世界である。
スタートアップはこうしたことを経験しないし、Facebookのような大企業でさえ重要度の面でようやく似たレベルを経験する程度で、民間でそれに比較的近いのは大手金融機関くらいだ。米軍は地球上で最大の単一雇用主でもあり、Walmart 4.5社分の規模でもある。
そのため軍は複数のレイヤーであらゆるものを監視し、レイヤーごとの承認済みソフトウェアリストで強固にロックダウンしている。セキュリティポリシーを書いたり監視したりしている人たちは、熟練したソフトウェアディレクターではない可能性が高く、NPMやMavenを見ると、セキュリティを知らない人々が作った無制限の攻撃ベクトルだと見なすが、それも間違いとは言い切れない。
民間・請負業者の領域ではコードの所有権も複雑だ。政府の資金で作るなら政府所有であるべきだが、請負会社は政府とは別の自社資産として持っていかなければ、再び課金できないと考える。下請けが主契約者の財務目標と合わなければ、さらに複雑になる。個人的には政府にすべて渡せばよいと思うが、人々が何層にも障壁を築くのは奇妙だ。政府側のインフラはセキュリティ認証レベルがはるかに高いので、一般には制約もより少ない。
米軍の一部領域では、説明されたような脅威とセキュリティの高度さに直面しているかもしれないが、全体としては現代的な解決策やベストプラクティスを統合しにくいレガシーシステムが多い。こうした古いシステム・業務フロー・官僚制は、優れたセキュリティよりも非効率と脆弱性を生みやすい。
米軍が侵害されたという話を聞かないのは、そうしたことがないからではなく、発生すると機密扱いにされるからだ。公開の恥を避けることが機密指定の第一の用途なので、有能だという信念が生まれる。自分ならいつでもFacebookのセキュリティを米軍より上に置くし、その差も小さくないと思う。Facebookは決済処理業者でもある。
AWSの重要性を考えれば、Amazonも同様の脅威を受けているのは明らかだ。
(A) 一般条項—この法律は、機密ソースコード、または40 U.S.C. 11103で定義される国家安全保障システムで主に使用するために開発されたソースコードには適用されない。
(B) 国家安全保障—第3条の要件免除は、機密ソースコード、または次のソースコードに適用される: (i) 国家安全保障システムで主に使用するために開発されたコード、または (ii) 1947年国家安全保障法3(4)で定義される情報コミュニティ構成機関またはその一部が開発したコード。
そのとき、政府契約という商売がどのような構造なのか、なぜ仕事が必要以上に何年も長引くのか理解した。
私たちの税金で払っているお金なのに、なぜ皆の懐から金を抜き取って、会社の一部の大物や営業担当者を大いに裕福にする側を応援するのか、と問いたくなる。
「政府にすべてを渡すつもりはない」という立場なら、合理的な方法は、政府が望む形で成果物を使用する権利を与えつつ、非機密のコンポーネントとその派生物を民間に自由に販売できるようにする程度だと思う。
この法律は、各機関のCIOに施行後180日以内にポリシーを作成することを求めており、そのポリシーでは、カスタム開発コードがベストプラクティスに沿うようにし、カスタムコードのメタデータを公開する手順と標準的な報告手順を定める必要がある
新法におけるメタデータには、カスタムコードが契約により開発されたものか、リポジトリで共有されたか、契約番号、コードが共有されたリポジトリへのリンクが含まれる
残念ながら、各機関にコードを公開オープンソース化することを求める法律ではなく、機関間での共有のみを求めるものに見える。公開共有が求められるのは「メタデータ」だけである。法案の全文は https://www.congress.gov/bill/118th-congress/house-bill/9566... にある
例外はあるが、他の契約業者もソースコードを修正し、同様に公開しない能力を保持する必要がある、という論理もあった。おそらく防衛分野のためだと推測している
金銭的な理由で非公開に保つには基準が高かったが、それ以外のどんな理由でも非公開にすることは常に可能だった。DOE Codeはオープンソースソフトウェアを追跡するプログラムで、通常はGitHub組織を通じて管理されている。OSTIはすべての知的財産と研究を追跡する部署だ
オープンソース開発モデルはLLNLにとっても利益になり、単独で開発していた場合よりはるかに優れたコードベースを得ることになった
NASA IKOSのように、すでに公開されているものもある: https://github.com/NASA-SW-VnV/ikos
このプロジェクトは、第三者から受けるべき注目に比べて、はるかに注目されていない。マルチスレッディングを扱う汎用の健全な静的解析器へと発展できれば、他の多くのプロジェクトの改善に役立つだろう
「公的予算なら、そのお金から生まれた成果を大衆が見るべきだ」という考えで、完全なオープンソースモデルを推進してみたことがある: https://web.archive.org/web/20200920095030/http://oss4gov.or...
政府ソフトウェアのデフォルトは、大臣級の承認による例外がない限りオープンソースであるべきだと考えていた。ただし当時は若く、世間知らずだった
Ghidraは良い例で、このソフトウェアが無料になったことはセキュリティコミュニティにとって大きな利益となった
私たちはオープンソースソフトウェアを作り、政府機関に採用または利用してもらおうとしているが、これらの機関がオープンソースアレルギーを示す度合いには驚かされる
ある機関は他人のコードを使うよりも、CSVアップロードや壊れたパーサーのようなレガシーな方法で自作し、予測可能なバグや欠陥まで一緒に作り込んでしまう
提案依頼書に応答する際も、オープンソースのほうがクローズドなシステムより強い審査を受ける。公開されていれば、それが良いものだと証明しなければならないが、クローズドならベンダーが「はい、完璧です」と言えば、機関はそれで済ませられる。機関も職員も、いかなる責任も負いたがっていないように感じる。それでも無能を理由に政府の職を失った人は見たことがない
私は政府で働いており、実際に経験している。文化は非常に有害で壊れている。ElonとTrumpのチームがどのような変化を提案するのか期待している
米国国防総省にはオープンソースソフトウェアFAQがある: http://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx および https://github.com/risacher/DoD-OSS-FAQ
このバージョンは、政府の政策文書に対する公的参加のためのコラボレーションツール実験としてGitHubに公開されたもので、軍・民間の職員、契約業者、一般市民がpull requestで変更や追加提案を提出できるとされている
2010年の動画: https://www.youtube.com/watch?v=WWt0YiXcEkE
DoD CIO室のDan Risacherとオープンソースセキュリティ専門家のDavid A. Wheelerが、国防総省がオープンソースを実行可能な商用ソフトウェアの一形態とみなす立場を明確にした最近のDoDメモの経緯と影響を説明している
2024年の資料: https://openssf.org/press-release/2024/10/29/openssf-expands...
Linux FoundationのOpenSSFはセキュリティ教育の必要性を認めているとし、OpenSSFのオープンソースサプライチェーンセキュリティ担当ディレクターDavid A. Wheelerによれば、コース開始以降25,000人以上がこの教材に登録している
意図は良いが、実際には契約業者1の潜在的な競合が差を縮めたり、既存契約のコード品質を根拠に攻撃したりする以外には、あまり何も起きない気がする。コードを読むことはコードを書くことより難しい
既存契約のコード品質を根拠に攻撃するなら、それはコードレビューであり、何らかの形でコード品質の改善につながる。ここで何が問題なのか分からない
素晴らしいことだ。同じ組織の中でさえ、コードを読めずに苦労した記憶がある。こうした変化は、トップダウン型のメンタルモデルを作る人たちの仕事を楽にしてくれそうだ
一般に、納税者のお金で支払われたものはすべて公開されるべきだ。Public Monies Public Goodsが絶対的な基本原則であるべきだ
とはいえ、不道徳な契約業者がコードに著作権を設定し、ライセンス料を取ることを防げてはいない。DoEのコードの大半がそうで、NWCHEMのような例外もある。なぜ訴訟にならなかったのかいつも不思議だったが、おそらく誰も大して気にしていないからなのだろう
一方では、他地域がその地域の納税者が費用を負担した条例体系にただ乗りしている、と見るのも理解はできる。その法律が主にその地域の地方政府に適用されるものならなおさらだ。他方で、法律が著作権で制限されるというのは奇妙に感じる
自宅で誰かに仕事を頼んだとき、最終成果物以外に正確に何を所有することになるのかも考えてみるべきだ
素晴らしい方向性だ。政府チームと仕事をする中で、このやり方が推奨プラクティスとして示されているところを見たことがある: https://www.forgov.qld.gov.au/information-and-communication-...
ただし多くの場合、その勧告を実際に従わせるには、要件として法制化する段階が依然として必要だ。特に公共サービスでは、オープンソースコミュニティに参加したことのない人が珍しくないため、なおさらだ
他の人たちが強調しているように、公的予算は公共の利益につながるべきであり、オープンソースはその利益を拡大する良い方法だ
「新法は、機密コード、国家安全保障システム、共有した場合にプライバシーリスクを生じさせるコードには適用されない」という文言がある
共有するとプライバシーリスクを生じさせるコードとは、いったいどんな種類なのだろうか？ コードとデータがかなりひどく混ざり合っているという意味のように聞こえる
政府契約業者は、自分たちのコードがひどいもので、概して隠蔽によるセキュリティに依存していることを、行間で喜んで認めている。情報委員会も何度か彼らの主張を認めた
たとえばExcelの数式から何が見えるかを考えてみればよい