AIサプライチェーンリスク （米国下院 科学・宇宙・技術委員会での証言から）(2022.05.11)
こんにちは、丸山満彦です。
米国下院のHouse Committee on Science, Space and Technology（科学・宇宙・技術委員会）で、オープンソースソフトウェアのサイバーセキュリティについての公聴会があり、そこでAIサプライチェーンリスクについての発表もあったようですね。。。
販売されているAIを利用しようとする場合、AIサプライチェーンリスクは通常のプログラムより深刻かも知れませんね。。。
機械学習によるアプリケーションはデータがある意味プログラムの一部であるわけで、そのAIがどのような学習をしてきたか（あるいは教育を受けてきたか）によって、意図的な判断を組み込むことができそうですし、かといって、その意図的な判断が組み込まれていることを見つけ出すことは難しいように思います。
例えば、マルウェア検出を人工知能で行うアプリケーションを考えてみても、特定のパターンのマルウェアについてはマルウェアと判別しないようにしていても、それに気づくことは難しいですよね。。。考えられる対策としては、アンドリュー氏は、政府による信頼できるAIのバージョンが提供される仕組みを作ることを提唱していますね。。。（政府に何ができるのかと言うことを考える場ですから、、、）
それ以外にも、ユーザサイドの対策としては、複数の同種のプログラムを利用して、その結果を利用することも考えられると思います。。。（多数決な感じ...）
いずれにしても、これからはアプリケーション等の作成に関わった主体の信頼性などの要素が重要となってくるように感じます。
米国の公聴会の議論も踏まえて政策を考えたら良いのでしょうね。。。（議論の質が高いものが多いように感じるし。。。）
しかし、下院の科学・宇宙・技術委員会の投資・監視小委員会の議長Bill Fosterさんは、フェルミ研究所出身なんですね。。。
● House Committee on Science, Space and Technology
・2022.05.11 SECURING THE DIGITAL COMMONS: OPEN-SOURCE SOFTWARE CYBERSECURITY
・[PDF] Dr. Andrew Lohn, Senior Fellow, Center for Security and Emerging Technology, Georgetown University
ビデオは、
44:50くらいから始まります。。。
本文...
| Chairman Foster, Chairwoman Stevens, Ranking Member Obernolte, Ranking Member Feenstra, and members of the Subcommittees, thank you for the opportunity to testify before you today. I am Andrew Lohn, Senior Fellow in the CyberAI Project of the Center for Security and Emerging Technology at Georgetown University. It is an honor to be here. During the next few minutes, I would like to discuss risks related to the artificial intelligence supply chain. | フォスター委員長、スティーブンス委員長、オバーノルテ委員、フィーンストラ委員、そして各小委員会の皆様、本日は証言の機会をいただき、ありがとうございます。私は、ジョージタウン大学安全保障・新技術センターのサイバーAIプロジェクトのシニアフェロー、アンドリュー・ローンと申します。この場にいることを光栄に思います。これから数分間、人工知能のサプライチェーンに関連するリスクについてお話したいと思います。 |
| A Culture of Sharing | 共有の文化 |
| The AI community has been particularly open to sharing. For example, it cost $500,000 and two and a half years to build the famous ImageNet dataset, but the professor who built it released it to everyone. Then Google and Facebook both released their powerful AI engines. Now thousands of the most powerful AI models are a quick download away. It is truly incredible given that these models often range from thousands to millions of dollars to build – and that’s in computing cost alone, without even considering the expertise to design them. | AIコミュニティは、特に共有に対してオープンです。例えば、有名なImageNetデータセットの構築には50万ドルと2年半の時間がかかりましたが、構築した教授はそれを皆に公開しました。その後、GoogleとFacebookが強力なAIエンジンを公開しました。今では、何千もの最も強力なAIモデルが、すぐにダウンロードできるようになりました。これらのモデルの構築には数千ドルから数百万ドルの費用がかかることが多く、しかもそれは設計の専門知識を考慮しない計算コストだけであることを考えると、本当に驚くべきことです。 |
| The AI Supply Chain | AIサプライチェーン |
| These datasets, models, and AI programming resources are the building blocks of today’s AI systems. In the same way that few bakers today grow their own grain and raise their own hens, most AI developers simply combine ready-made components and tweak them for their new applications. Sometimes the whole process only needs a few lines of code and surprisingly little expertise. This approach allowed Google Translate to improve performance in 2016 while trimming from 500,000 lines of code down to just 500. | これらのデータセット、モデル、AIプログラミングリソースは、今日のAIシステムの構成要素となっています。パン職人が自分で穀物を育てたり、鶏を飼ったりすることがほとんどないのと同じように、AI開発者の多くは既製の部品を組み合わせ、新しい用途に合わせて手を加えるだけです。その際、必要なのは数行のコードと驚くほど少ない専門知識だけだったりします。このアプローチにより、Google翻訳は2016年、50万行のコードをわずか500行に削減しながら、パフォーマンスを向上させることができました。 |
| Sharing has driven both scientific and economic progress, but it has also created an alluring target for attackers. | 共有は、科学と経済の両方の進歩を推進しましたが、攻撃者にとって魅力的なターゲットも生み出しています。 |
| Supply Chain Vulnerability | サプライチェーンの脆弱性 |
| For one, an attacker can subvert an AI system by altering the data. That could happen, for instance, by a nefarious online worker while they label the datasets or by a hacker who sneaks into the victim’s networks. Alternatively, if the attacker provides a fully trained model, then it can be very hard to find their manipulations. | 一つは、攻撃者がデータを改ざんすることで、AIシステムを破壊できることです。例えば、データセットにラベルを貼る際に悪意のあるオンラインワーカーによって、あるいは被害者のネットワークに忍び込むハッカーによって、そのようなことが起こる可能性があります。また、攻撃者が完全に訓練されたモデルを提供した場合、その操作を発見することは非常に困難です。 |
| There is no good way to know if a downloaded model has a backdoor, and it turns out that those backdoors can survive even after the system has been adapted for a new task. A poisoned computer vision system might mistakenly identify objects, or a poisoned language model might not detect terrorist messages or disinformation campaigns that use the attacker’s secret codewords. | ダウンロードしたモデルにバックドアがあるかどうかを知る良い方法はなく、バックドアはシステムが新しいタスクに適応された後でも生き残ることができます。毒されたコンピュータビジョンシステムが誤って物体を識別したり、毒された言語モデルが攻撃者の秘密のコードネームを使用したテロリストのメッセージや偽情報キャンペーンを検出しないかもしれません。 |
| The programming resources for building AI systems are also vulnerable. Such systems can have thousands of contributors from around the globe writing millions of lines of code. Some of that code has been exploitable in the past. And some of it prioritizes speed or efficiency over security. For example, vision systems need images at a specific size, but the code to resize images allows attackers to swap out one image for another. | AIシステムを構築するためのプログラミング資源もまた脆弱です。このようなシステムには、世界中から何千人もの貢献者が集まり、何百万行ものコードを書いていることがあります。その中には、過去に悪用されたことのあるコードもあります。また、セキュリティよりもスピードや効率を優先するコードもあります。例えば、画像処理システムは特定のサイズの画像を必要としますが、画像のサイズを変更するコードによって、攻撃者はある画像を別の画像に交換することができます。 |
| And lastly, these resources are only as secure as the organization or system that provides them. Today, the vast majority are hosted in the United States or its allies, but China is making a push to create state-of-the-art resources and the network infrastructure to provide them. If adversaries make the most capable models – or if they simply host them for download – then developers in the United States would face an unwelcome choice between capability and security. | そして最後に、これらのリソースは、それを提供する組織やシステムの安全性と同じだけ安全です。現在、その大半は米国やその同盟国でホストされていますが、中国は最先端のリソースとそれを提供するネットワーク・インフラを構築することを推進しています。もし敵対国が最も高性能なモデルを作成し、あるいは単にダウンロードできるようにホストするのであれば、米国内の開発者は性能とセキュリティの間で好ましくない選択に直面することになります。 |
| Recommendations | 提言 |
| There are a few things Congress can do now to help maximize the benefits of this sharing culture while limiting the security risks that come with it. One step is supporting efforts to provide trusted versions of these AI resources, such as through NIST or the National AI Research Resource. Funding is also needed to do the basic hygiene, cleanup, and audits that are important for security, but that attract few volunteers. | このような共有文化のメリットを最大限に生かしつつ、それに伴うセキュリティリスクを抑えるために、議会が今できることがいくつかあります。その一歩は、NISTやNational AI Research Resourceなどを通じて、これらのAIリソースの信頼できるバージョンを提供する取り組みを支援することです。また、セキュリティにとって重要でありながら、ボランティアがほとんど集まらない基本的な衛生管理、クリーンアップ、監査を行うための資金も必要です。 |
| Congress should consider requesting that organizations across the U.S. government create a prioritized list of AI systems and the resources used to build them. This list may be easier to create and maintain if these organizations are incentivized to collect a software bill of materials that lists the components in the software that the government buys or builds. | 議会は、米国政府全体の組織に対して、AIシステムとその構築に使用されるリソースの優先順位付けされたリストを作成するよう要請することを検討すべきです。もしこれらの組織が、政府が購入または構築するソフトウェアのコンポーネントをリストアップしたソフトウェア部品表を収集するよう奨励されれば、このリストの作成と維持はより容易になるかもしれません。 |
| And lastly, many of these AI systems are new, and so are the attacks on them. The government would benefit from augmenting their red and blue teams of defensive hackers and security specialists with AI expertise to help them discover security holes in our most important systems while also thinking of new, creative ways to subvert them before our adversaries do. | 最後に、これらのAIシステムの多くは新しいものであり、それに対する攻撃もまた新しいものです。政府は、防御的なハッカーやセキュリティの専門家からなるレッドチームとブルーチームにAIの専門知識を補強することで、最も重要なシステムのセキュリティホールを発見し、敵より先にそれを破壊する新しい創造的な方法を考えるのに役立つと思われます。 |
| Thank you for the opportunity to testify today, and I look forward to your questions. | 本日は証言の機会をいただき、ありがとうございました。 |
オープンソフトのセキュリティと言う意味では、他の証言も大変参考になるので、、、
↓
Opening Statement
・(1) [PDF] Chairman Bill Foster (D-IL) of the Subcommittee on Investigations and Ovesight
| Good morning, and welcome to our members and witnesses. Thank you for joining us for this important hearing on open-source software security. Cybersecurity is certainly an evergreen issue, and today we’re focusing on an important and often overlooked corner of the ecosystem. Open-source software is software that’s freely available for anyone to use or modify. It’s the hidden workhorse of the digital ecosystem, and it’s a part of software ranging from standalone browsers to complex commercial operating systems. | おはようございます、そしてメンバーの皆様、証人の皆様を歓迎いたします。オープンソースソフトウェアのセキュリティに関する重要な公聴会にお集まりいただき、ありがとうございます。サイバーセキュリティは確かに永遠の課題ですが、本日はエコシステムの重要かつ見過ごされがちな一角に焦点を当てます。オープンソースソフトウェアは、誰もが自由に使用または変更できるソフトウェアです。デジタルエコシステムの隠れた主力製品であり、スタンドアロンブラウザから複雑な商用オペレーティングシステムに至るまで、さまざまなソフトウェアの一部となっています。 |
| It’s also common in scientific research. For instance, Fermilab – where I worked for many years as a physicist – recently announced the development of open-source software to support the control electronics of quantum computers. Even if you’re not working with a quantum computer, it’s safe to say that anyone who has used a computer has relied on open-source software, whether they knew it or not. | また、科学的な研究にもよく使われています。例えば、私が物理学者として長年勤務していたフェルミ研究所は、最近、量子コンピュータの制御電子回路をサポートするオープンソースソフトウェアの開発を発表しています。量子コンピュータを扱っていない人でも、コンピュータを使ったことがある人なら、知ってか知らずかオープンソースのソフトウェアに頼ったことがあると言ってよいでしょう。 |
| And yet, despite its importance, open source only draws attention when something goes wrong. In 2014 the Heartbleed vulnerability in OpenSSL prompted a surge of concern and action to save open source on the part of industry and government alike. Good work was done in response to that vulnerability, but interest waned and, in many ways, we find ourselves in the same situation now that we were in back then. | しかし、その重要性とは裏腹に、オープンソースが注目されるのは、何か問題が起きたときだけです。2014年、OpenSSLの脆弱性「Heartbleed」をきっかけに、業界や政府を問わず、オープンソースを救おうとする懸念と行動が一気に高まりました。その脆弱性に対応するために良い仕事が行われましたが、関心は薄れ、多くの点で当時と同じ状況に今あることに気づきました。 |
| This past winter, the open source community was once more rocked by a dangerous vulnerability. The Log4j project and its vulnerability, called Log4Shell, reminded everyone of the dangers of neglecting open-source software. The sheer breadth of organizations affected by a vulnerability in a single piece of software drove home just how much everyone relies on open source. | この冬、オープンソースコミュニティは再び危険な脆弱性によって揺れ動きました。Log4jプロジェクトとLog4Shellと呼ばれるその脆弱性は、オープンソースソフトウェアを軽視することの危険性を皆に思い知らされました。たった1つのソフトウェアの脆弱性によって影響を受けた組織の広さは、誰もがいかにオープンソースに依存しているかを思い知らされることになったのです。 |
| This hearing is not meant to look back at the hows and whys of Log4j – others, including other Congressional committees, have already done an admirable job of that. Instead, this hearing will look forward. We will explore how industry and government can cooperate to make sure open source has resources commensurate with its importance. Those resources are not just financial, but also include technical capabilities, volunteer efforts, and administrative and organizational contributions. | この公聴会は、Log4jの経緯と理由を振り返ることを意図していません。他の議会委員会を含む他の人々は、すでにそのための立派な仕事をしています。その代わりに、この公聴会は前方を見ます。我々は、オープンソースがその重要性に見合ったリソースを持つことを確認するために、産業界と政府がどのように協力することができるかを探ります。それらのリソースは、金銭的なものだけでなく、技術的な能力、ボランティア活動、管理的・組織的な貢献も含まれます。 |
| This hearing is also an opportunity to look at some of the dangers of open source that are looming on the horizon. Open-source software is not just in traditional computers; it’s in our drones, our AI models, and yes, even quantum computers. We need to fully understand how open-source resources are used in developing technologies to properly assess the risks that those uses represent. | また、この公聴会は、オープンソースの危険性が迫ってきていることに目を向ける機会でもあります。オープンソースソフトウェアは、従来のコンピュータだけでなく、ドローンやAIモデル、そして量子コンピュータにも搭載されているのです。オープンソースのリソースがどのように技術開発に利用されているかを十分に理解し、その利用が意味するリスクを適切に評価する必要があります。 |
| It is important to remember that no software is ever completely secure. Just as, for instance, Windows and iOS will certainly be hacked in the future, there will also be other open-source software vulnerabilities. Rather than seeking perfection, our goal is instead to structure how we think about open source, how we identify the most critical pieces of open-source software, and how we secure that software against intrusion. | ここで重要なのは、どんなソフトウェアも完全に安全ということはないということです。例えば、WindowsやiOSが将来必ずハッキングされるように、オープンソースソフトウェアにも脆弱性は存在します。私たちの目標は、完璧を求めるのではなく、オープンソースについてどのように考え、オープンソースソフトウェアの最も重要な部分をどのように特定し、そのソフトウェアを侵入からどのように保護するかを構造化することにあります。 |
| If we do that, we will be able to mitigate both the risk of future vulnerabilities and the damage caused when vulnerabilities are exploited. | そうすれば、将来的な脆弱性のリスクと、脆弱性が悪用されたときの被害の両方を軽減することができるはずです。 |
| In a world where our technology so often comes with hidden drawbacks or motivations, opensource software is often a charmingly utopian exception. At its best, it is simply people creating software out of passion, and sharing out of a desire for others to benefit from the fruits of that labor. It empowers people of all backgrounds and levels of technical ability to build upon the work of others and find or make software suited to their needs. | 技術にはしばしば欠点や動機が隠されているものですが、オープンソースソフトウェアは魅力的なユートピア的例外と言えるでしょう。その最たるものは、人々が情熱を持ってソフトウェアを作成し、その成果から他の人々が利益を得ることを望んで共有することです。それは、あらゆる経歴や技術的能力を持つ人々が、他の人々の仕事の上に構築し、自分のニーズに合ったソフトウェアを見つけたり作ったりすることを可能にするものです。 |
| There is something wonderful about that. I hope that through our conversation with our witnesses here today we can contribute to the future of safe and secure open-source software. | これは素晴らしいことです。本日お集まりの証人の方々との会話を通じて、安全でセキュアなオープンソースソフトウェアの未来に貢献できることを願っています。 |
・(2) [PDF] Chairwoman Haley Stevens (D-MI) of the Subcommittee on Research and Technology
| Good morning and welcome to this joint hearing of the Subcommittee on Research and Technology and the Subcommittee on Investigations and Oversight. I would like B12:C21to thank my esteemed colleagues, Chairman Foster and Ranking Member Obernolte, for leading this timely and needed hearing. | 研究・技術小委員会と調査・監視小委員会の合同公聴会にようこそお越し下さいました。この時宜を得た必要な公聴会を主導している私の尊敬する同僚、フォスター委員長とオバーノルテ委員に感謝申し上げたい。 |
| A supply chain is only as strong as its weakest link – and the times when the weakest link happens to be cybersecurity, we see devastating ripple-effects and wide-ranging aftershocks. We can no longer operate off yesterday’s mindset and only view supply chain cybersecurity as an IT problem. In order to strengthen America’s collective cybersecurity, we must examine all the vulnerable links in the chain. I am proud to be here today to encourage Congress to explore various avenues the government can engage the open-source community to identify and remedy vulnerabilities. | サプライ・チェーンは最も弱い部分によってのみ強化されます。最も弱い部分がサイバー・セキュリティである場合、破壊的な波及効果と広範な余震を見ることになります。私たちはもはや、サプライチェーンのサイバーセキュリティをITの問題としてのみ捉えるような、昨日までの考え方で動くことはできません。米国全体のサイバーセキュリティを強化するためには、サプライチェーンの脆弱な部分をすべて検証する必要があります。私は今日ここに、政府が脆弱性を特定し是正するためにオープンソースコミュニティに参加できるさまざまな手段を模索するよう議会に奨励できることを誇りに思います。 |
| One year ago, President Biden released an Executive Order called “Improving the Nation’s Cybersecurity.” This executive order tasked the National Institute of Standards and Technology to create essential standards for critical software, software supply chain risk management, among other tasks. In the coming days, NIST is expected to publish its final piece of guidance required by the executive order, but the agency’s work to secure the Nation’s software is far from finished. | 1年前、バイデン大統領は 「国家サイバーセキュリティの改善」という大統領令を発表しました。この大統領令は、国立標準技術研究所に、重要なソフトウェア、ソフトウェアのサプライチェーンのリスク管理などに関する必須規格を作成するよう命じました。近日中に、NISTは大統領令が要求する最後のガイダンスを発表する予定ですが、国家のソフトウェアを保護するためのNISTの作業は、まだ終わっていません。 |
| One aspect of supply chain security we need to take an in-depth look at is the open-source vulnerability landscape. Many leading companies and organizations don’t recognize how many aspects of their critical infrastructure depend on open source. Open-source software code is available to the public, for anyone to use, modify, or inspect. Many elements of NIST’s software guidance can be applied to open-source software, such as the secure software development framework. However, they do not address many of the unique challenges inherent in the opensource software ecosystem, from inadequate resourcing to vulnerability detection and mitigation. | サプライチェーンセキュリティの一側面として、私たちはオープンソースの脆弱性状況について深く検討する必要があります。多くの大手企業や組織は、重要なインフラの多くの側面がオープンソースに依存していることを認識していません。オープンソースのソフトウェアコードは一般に公開されており、誰でも使用、変更、または検査することができます。NISTのソフトウェアガイダンスの多くの要素は、安全なソフトウェア開発フレームワークのように、オープンソースソフトウェアに適用することができます。しかし、人材不足から脆弱性の検出と緩和まで、オープンソースソフトウェアのエコシステムに固有の課題の多くには対応していません。 |
| A vibrant open-source ecosystem is an engine for U.S. competitiveness and growth. This ecosystem benefits Americans every day, including in my home state of Michigan. During the pandemic, open-source applications tracked open hospital beds and helped Michiganders access food for their families when schools were closed. But there is real risk if we leave critical opensource software vulnerable to attack. As both the Heartbleed and Log4J (pronounced log-4-J) incidents have revealed, open-source software issues can be a threat to our Federal agencies and businesses across the country. | 活気あるオープンソースのエコシステムは、米国の競争力と成長の原動力となります。このエコシステムは、私の故郷であるミシガン州を含め、毎日アメリカ人に利益をもたらしています。パンデミック時には、オープンソースのアプリケーションが病院の空きベッドを追跡し、学校が閉鎖されたときにミシガン州の人々が家族のために食糧を入手するのを助けました。しかし、重要なオープンソースソフトウェアを攻撃に対して脆弱なままにしておくと、本当に危険です。Heartbleed事件とLog4J事件が明らかにしたように、オープンソース・ソフトウェアの問題は、私たちの連邦機関や国中の企業にとって脅威となり得ます。 |
| There is good work underway, but still much more the U.S. scientific enterprise can do to secure open-source software repositories. Last year, I introduced the NIST for the Future Act, which is part of the America COMPETES Act that we will hopefully send to the President’s desk soon. This bill would require NIST to expand its current efforts by assigning severity metrics to vulnerabilities in open-source software and producing voluntary guidance to help entities that maintain this software to secure it. | 現在も良い取り組みが行われていますが、オープンソースソフトウェアのリポジトリを保護するために、米国の科学企業ができることはまだたくさんあります。昨年、私は「NISTの将来法」を提出しましたが、これは「アメリカ競争法」の一部であり、間もなく大統領の机上に送られることを期待しています。この法案は、オープンソースソフトウェアの脆弱性に重大度の指標を割り当て、このソフトウェアを保守する団体がセキュリティを確保できるよう、自主的なガイダンスを作成することによって、現在の取り組みを拡大するよう NIST に要求するものです。 |
| The National Science Foundation has played an important role in funding many open-source software and data repositories. NSF is planning to award grants to help secure elements of the open-source ecosystem as part of its new program “Pathways to Enable Open-Source Ecosystems,” or POSE. I am encouraged by these efforts, which will be further bolstered once we enact and fund the NSF for the Future Act that is also in COMPETES. | 全米科学財団は、多くのオープンソースソフトウェアやデータリポジトリへの資金提供において重要な役割を担ってきました。NSF は、その新しいプログラム "Pathways to Enable Open-Source Ecosystems" (POSE) の一環として、オープンソースエコシステムの要素を保護するための助成金を授与することを計画しています。COMPETES にも含まれる NSF for the Future Act を制定して資金を提供すれば、このような取り組みはさらに強化されるでしょう。 |
| Securing open-source software is fundamentally a resource problem. I believe the Federal government can play a role identifying vulnerabilities, providing resources where industry might not, and driving long-term structural security improvements throughout the open-source ecosystem. These efforts are most effective when done in coordination and collaboration with the private sector. | オープンソースソフトウェアのセキュリティは、基本的にリソースの問題です。連邦政府は、脆弱性を特定し、産業界が提供できないようなリソースを提供し、オープンソースのエコシステム全体で長期的な構造的セキュリティ改善を推進する役割を果たすことができると信じています。これらの取り組みは、民間企業との連携・協力のもとで行われる場合に最も効果的です。 |
| I welcome the recommendations of this expert panel on how to improve the coordination between the public and private sector on securing the open-source ecosystem, and any additional recommendations you may have for this Committee to consider. | 私は、オープンソースエコシステムのセキュリティ確保に関する官民の連携をどのように改善するかについて、この専門家委員会の提言を歓迎し、当委員会が検討すべきその他の提言があれば、それも歓迎します。 |
| I want to again thank the witnesses for being here today to help us tackle these challenging issues. I yield back. | このような困難な問題に取り組むために、本日お集まりいただいた証人の皆様に改めて感謝申し上げたいと思います。それでは、失礼します。 |
・(3) Chairwoman Eddie Bernice Johnson (D-TX)
| Good morning. Thank you everyone for joining us for this joint subcommittee hearing. I especially want to thank Chairs Foster and Stevens, as well as Ranking Members Obernolte and Feenstra, for their leadership on the important issue of open-source software cybersecurity. | おはようございます。この合同小委員会公聴会にお集まりいただき、ありがとうございます。 特に、オープンソースソフトウェアのサイバーセキュリティという重要な問題についてリーダーシップを発揮しているフォスター委員長とスティーブンス委員長、そしてオバーノルテ委員長とフィーンストラ委員に感謝したいと思います。 |
| Cybersecurity is a perennial problem. It is one we have frequently examined here in the Science Committee. Nearly one year ago, we held a hearing on ways to improve the cybersecurity of software supply chains. Our expert witnesses spoke of a need to improve the security of opensource software to protect the entire software supply chain. | サイバーセキュリティは長年の問題です。ここ科学委員会でも頻繁に検証してきた問題です。ほぼ1年前、私たちはソフトウェアのサプライチェーンのサイバーセキュリティを改善する方法についての公聴会を開きました。 専門家の証人たちは、ソフトウェアのサプライチェーン全体を保護するために、オープンソースソフトウェアのセキュリティを向上させる必要性を訴えました。 |
| Their foresight was astute. At the end of last year, a vulnerability called Log4Shell was found in a piece of crucial and widely used open-source software. Thousands of organizations and systems were affected, and the work of protecting those systems is still ongoing. One leading cyber company called this software exploit “the single biggest, most critical vulnerability ever.” It is clear that we must dedicate more resources to securing open-source software. | 彼らの先見性は鋭かった。 昨年末、重要で広く使われているオープンソースソフトウェアに「Log4Shell」と呼ばれる脆弱性が発見されました。 何千もの組織やシステムが影響を受け、それらのシステムを保護する作業は今もなお続いています。ある大手サイバー企業では、このソフトウェアの脆弱性を "史上最大かつ最も重大な脆弱性 "と呼んでいます。オープンソースソフトウェアの保護に、より多くのリソースを割かなければならないことは明らかです。 |
| Our government agencies have been working hard to support this goal. NIST, in particular, has released extensive guidance for the successful development of secure software. An executive order from last May pushed the agency to do even more. They have released a definition of critical software that can guide the focus to the most important pieces of open-source software. And just last week, NIST issued updated guidance on supply chain risk management, completing a two-and-a-half-year process for how best to handle software in the supply chain. | 私たちの政府機関は、この目標を支援するために懸命に働いています。 特に NIST は、安全なソフトウェアの開発を成功させるための広範なガイダンスを発表しています。 昨年5月の大統領令は、NISTにさらなる努力を促しました。 NIST は、オープンソースソフトウェアの最も重要な部分に焦点を合わせることができるよう、重要なソフトウェアの定義を発表しました。 そして先週、NIST はサプライチェーンのリスク管理に関する最新のガイダンスを発表し、サプライチェーンにおけるソフトウェアの最善の取り扱い方法に関する 2 年半のプロセスを完了させました。 |
| But NIST cannot solve this problem alone. This is a key moment for government to partner with industry. Our expert witnesses can provide perspectives on open source informed by their time spent working for industry, non-profits, the military, and the civilian government. Their insights will help us understand both the technical challenges and the underlying culture of the opensource community. | しかし、NISTだけではこの問題を解決することはできません。 今こそ、政府が産業界と協力する重要な瞬間です。専門家証人には、産業界、非営利団体、軍、および民間政府で働いた経験から得たオープンソースに関する視点を提供してもらうことができます。 彼らの洞察は、技術的な課題とオープンソースコミュニティの根底にある文化の両方を理解するのに役立ちます。 |
| Armed with that understanding, we can steer resources towards where they will do the most good. We can also map out the complex ecosystem of those who produce open-source software, and provide training and other resources to help make it secure. We can find more ways for agencies like NIST to collaborate with industry experts and other folks developing and maintaining open-source software across the country. | その理解に基づいて、私たちはリソースを最も効果的な場所に向けることができます。また、オープンソースソフトウェアを作成する人々の複雑なエコシステムをマップし、それを安全にするためのトレーニングやその他のリソースを提供することができます。 NISTのような機関が、国内のオープンソースソフトウェアを開発・保守する業界の専門家やその他の人々と協力する方法をもっと見つけることができます。 |
| We will also look to the future. Open source is a critical part of many developing technologies. It enables the growth of artificial intelligence and makes the technology accessible to a wider range of people. Yet the dangers posed by open-source software exist here as well. Bad actors will inevitably try to manipulate open-source datasets to control AI. This is a frightening possibility as AI becomes a bigger part of all our lives. | 私たちは将来にも目を向けています。 オープンソースは、多くの発展途上のテクノロジーに不可欠な要素です。 オープンソースは、人工知能の成長を可能にし、より多くの人々が技術にアクセスできるようにします。 しかし、オープンソースソフトウェアがもたらす危険は、ここにも存在します。 悪質な業者がオープンソースのデータセットを操作してAIをコントロールしようとするのは必至だ。 これは、AIが私たちの生活のすべてに大きな影響を与えるようになるにつれ、恐ろしい可能性をはらんでいます。 |
| The risks of open source should not outweigh its benefits. Properly resourced and made secure, open-source software can do a lot of good for a lot of people. | オープンソースのリスクは、その利点を上回ってはなりません。 適切に資金を調達し、安全性を高めたオープンソースソフトウェアは、多くの人々にとって多くの利益をもたらすことができます。 |
| I welcome the recommendations of our expert panel to guide us in that goal. | 私は、この目標に向けて私たちを導いてくれる専門家委員会の提言を歓迎します。 |
| Thank you, and with that I yield back. | ありがとうございました。それでは、失礼します。 |
Testimony
・(1) [PDF] Ms. Lauren Knausenberger, Chief Information Officer, Department of the Air Force
| Introduction & Strategic Implications | 序論と戦略的意義 |
| Less than five years passed from the formal establishment of the Manhattan Project to the operational use of a nuclear weapon, at the time an unprecedented acceleration of research, development, and operationalization of a new capability. A future conflict may be decided by features, updates, or fixes to software-intensive systems that take place in hours or even minutes, not days, much less years. In order to meet the strategic imperative this moment requires, the Air Force must lower the barrier to fielding new algorithms and systems while increasing the utilization of commercial software, including open-source investments, to diversify the innovation space for the Department. | マンハッタン計画が正式に発足してから核兵器が運用されるまで5年もかかりませんでした。当時は新しい能力の研究、開発、運用が前例のないほど加速された時代でした。将来の紛争は、ソフトウェア集約型システムの機能、更新、修正によって決定されるかもしれません。それは、数日、ましてや数年単位ではなく、数時間、数分単位で行われる。この瞬間に求められる戦略的要請に応えるため、空軍は新しいアルゴリズムとシステムの実戦配備の障壁を下げる一方で、オープンソース投資を含む商用ソフトウェアの利用を増やし、空軍のイノベーション空間を多様化する必要があります。 |
| Open-source software (OSS) is software that has the source code made publicly available, is licensed for broad public reuse, and is typically distributed free of charge. By leveraging open-source software, the development of large-scale software projects can be drastically accelerated due to the re-use of previously developed code and the open systems architectures that open-source software tends to drive. In order to take maximum advantage of the opportunities provided by open-source software, entities in charge of software development efforts should take steps to mitigate some of the risks associated with open-source software. | オープンソースソフトウェア（OSS）とは、ソースコードが公開され、広く一般に再利用が許可され、通常、無料で配布されているソフトウェアのことです。オープンソースソフトウェアを活用することで、以前に開発されたコードの再利用や、オープンソースソフトウェアが推進する傾向のあるオープンシステムアーキテクチャにより、大規模ソフトウェアプロジェクトの開発を劇的に加速させることが可能です。オープンソースソフトウェアが提供する機会を最大限に活用するために、ソフトウェア開発の担当者は、オープンソースソフトウェアに関連するいくつかのリスクを軽減するための措置を講じる必要があります。 |
| OSS should not be confused with so-called “shareware,” “freeware,” or “freemium” software products that are distributed free of charge but require the user to pay to unlock some additional functionality or to continue using the software after a trial period. That’s not to say that there are not successful business models built around open-source software: any software requires support and maintenance, and some companies have made a robust business in providing support services for free and open-source software. As an example, Red Hat Enterprise Linux (RHEL) is a free and open-source product for which Red Hat provides paid, enterprise-class support. | OSSは、いわゆる「シェアウェア」、「フリーウェア」、「フリーミアム」と呼ばれる、無料で配布されるものの、一部の追加機能を解除したり、試用期間後に継続して使用したりするためにユーザーに支払いを要求するソフトウェア製品と混同してはなりません。どんなソフトウェアでもサポートとメンテナンスが必要であり、フリーソフトウェアやオープンソースソフトウェアのサポートサービスを提供することで、強固なビジネスを構築している企業もあります。例えば、Red Hat Enterprise Linux (RHEL) はフリーでオープンソースの製品ですが、Red Hat は有償でエンタープライズクラスのサポートを提供しています。 |
| Background | 背景 |
| Software Life Cycle – Development, Distribution, and Maintenance | ソフトウェアのライフサイクル - 開発、配布、およびメンテナンス |
| The life cycle of an open-source software product can broadly be divided into development, distribution, and maintenance. Development refers to the specification of what the software should do and writing the code to implement the desired functionality; distribution refers to the process of packaging the software appropriately and providing it to the end users (which may be software developers in the case of software dependencies); and maintenance refers to the process of fixing errors (frequently referred to as “bugs”), updating software to maintain compatibility with other software and hardware systems, and incorporating any updates to the dependencies for that software. Due to the constantly evolving nature of modern agile software these life-cycle phases frequently overlap significantly, with features regularly being added to software that is continuously distributed and maintained. | オープンソースソフトウェア製品のライフサイクルは、大きく「開発」「配布」「保守」に分けられます。開発とは、ソフトウェアが何をすべきかを指定し、望ましい機能を実装するためのコードを書くこと、配布とは、ソフトウェアを適切にパッケージングし、エンドユーザー（ソフトウェア依存の場合はソフトウェア開発者）に提供すること、保守とは、エラー（しばしば「バグ」と呼ばれる）の修正、他のソフトウェアやハードウェアシステムとの互換性を維持するためのソフトウェアの更新、ソフトウェアの依存関係の更新を取り入れるプロセスを指します。現代のアジャイルソフトウェアは常に進化しているため、これらのライフサイクルのフェーズは頻繁に大きく重なり、継続的に配布・保守されるソフトウェアには定期的に機能が追加されています。 |
| Software Dependencies | ソフトウェアの依存関係 |
| A piece of software that is incorporated into a larger piece of software is referred to as a dependency of the larger piece of software. Each dependency may in turn have other dependencies (which may in turn have dependencies...) The total collection of dependencies and dependencies-of-dependencies is referred to as the set of transitive dependencies, and large software projects may have thousands of transitive dependencies. | より大きなソフトウェアに組み込まれたソフトウェアの断片は、より大きなソフトウェアの断片の依存性と呼ばれます。依存関係や依存関係の依存関係の集合は、推移的依存関係の集合と呼ばれ、大規模なソフトウェアプロジェクトでは、何千もの推移的依存関係を持つことがあります。 |
| Open-source software may be distributed on its own (as is the case with the Android Open Source Project (AOSP, commonly just “Android”) mobile operating system that powers Android smartphones) or as part of a proprietary product (Apple’s proprietary iOS mobile operating system that powers the iPhone platform is based on the open-source BSD operating system). In that case, the open-source software is a dependency of the commercial product. | オープンソースソフトウェアは、それ自体で配布されることもあれば（Androidスマートフォンを動かすAndroid Open Source Project（AOSP、一般的には単に「Android」）モバイルオペレーティングシステムのように）、プロプライエタリー製品の一部として配布されることもあります（iPhoneプラットフォームを動かすApple独自のiOSモバイルオペレーティングシステムは、オープンソースのBSD OSをベースにしています）。この場合、オープンソースソフトウェアは、商用製品の依存関係にあります。 |
| Because of the way that software is constructed out of many layers of dependencies, even if only proprietary software is purchased there are likely still open-source software dependencies and therefore open-source software supply chains that must be considered. | ソフトウェアは何重もの依存関係から構成されているため、たとえプロプライエタリなソフトウェアのみを購入したとしても、オープンソースソフトウェアの依存関係が存在する可能性があり、したがってオープンソースソフトウェアのサプライチェーンを考慮する必要があります。 |
| Software Risks | ソフトウェアのリスク |
| Incorporating open-source software into a software project can significantly speed up the delivery and decrease the cost of developing that software due to re-use of previously developed software. It would be difficult to name a successful software project today that didn’t rely on OSS in some form. | オープンソースソフトウェアをソフトウェアプロジェクトに組み込むことで、納期を大幅に短縮し、以前に開発したソフトウェアを再利用することで、ソフトウェアの開発コストを削減することができます。今日、成功しているソフトウェアプロジェクトで、何らかの形でOSSに依存していないものを挙げるのは難しいでしょう。 |
| Successfully using open-source software requires being cognizant of certain risks: | オープンソースソフトウェアをうまく利用するためには、ある種のリスクを認識することが必要です。 |
| • The incorporation of any software dependencies (whether open- or closed-source) into your project can expose you to responsibility for maintaining that dependency during the lifetime of your project. If the company or team that developed the software decides to end support for the product, then users may be forced to find a replacement product or pay for an expensive one-off support contract for maintenance. This maintenance also includes the correction of security deficiencies as they are discovered; for this reason, the use of unmaintained software poses both a business and cyber security risk. | ・オープンソース、クローズドソースを問わず、ソフトウェアに依存する部分をプロジェクトに組み込むと、プロジェクトの存続期間中、その依存関係を維持する責任を負わされる可能性があります。ソフトウェアを開発した企業やチームが製品のサポート終了を決定した場合、ユーザーは代替製品を探すか、メンテナンスのために高価な単発のサポート契約を支払わなければならなくなる可能性があります。このメンテナンスには、セキュリティ上の欠陥が発見された場合の修正も含まれる。このため、メンテナンスされていないソフトウェアの使用は、ビジネスとサイバーセキュリティの両方のリスクをもたらすことになるのです。 |
| o Example: For years after Windows XP was formally discontinued, Microsoft continued to support existing Windows XP customers via support contracts that increased in price over time (due to a smaller and smaller customer base to distribute the cost across). | o 例：Windows XPが正式に製造中止となった後、マイクロソフトは、時間とともに価格が上昇するサポート契約を通じて、Windows XPの既存顧客のサポートを継続した（コストを分散させる顧客基盤が小さくなっているため）。 |
| • Any software dependency (open-source or proprietary) may inadvertently introduce security flaws into your software product. These broadly fall into the categories of known flaws (these are typically published as Common Vulnerabilities and Exposures, or CVEs) and as-yetundiscovered flaws (known as “zero-days” in the cybersecurity community). Security-conscious organizations such as the DoD may have more stringent requirements for mitigating these flaws than other organizations, making it difficult for them to utilize the dependency because of a lack of evidence supporting the security of the dependency, disagreement over the severity of the flaws in the software, or timelines for mitigations of flaws that don’t satisfy policy or operational requirements. | ・ソフトウェアの依存関係（オープンソースかプロプライエタリか）は、あなたのソフトウェア製品に不注意にセキュリティの欠陥を持ち込む可能性があります。これらの欠陥は大きく分けて、既知の欠陥（これらは一般にCommon Vulnerabilities and Exposures、またはCVEsとして公開されています）と、まだ発見されていない欠陥（サイバーセキュリティのコミュニティでは「ゼロデイ」として知られています）に分類されます。DoD のようなセキュリティ意識の高い組織は、これらの欠陥を緩和するための要件が他の組織よりも厳しく、依存関係のセキュリティを裏付ける証拠がない、ソフトウェアの欠陥の深刻度に関する意見の相違、ポリシーまたは運用要件を満たさない欠陥の緩和のためのスケジュールなどのために、依存関係を利用することが難しくなる可能性があります。 |
| o Example: Several months ago, several severe zero-day vulnerabilities in an open-source logging framework named “log4j” were discovered and eventually disclosed as CVEs; thousands or millions of software projects needed to incorporate newer versions of log4j into their projects quite rapidly in order to avoid falling victim to cyber attacks. | o 例：数ヶ月前、「log4j」というオープンソースのログ記録フレームワークに深刻なゼロデイ脆弱性が複数発見され、最終的にCVEとして公開されました。何千、何百万のソフトウェアプロジェクトが、サイバー攻撃の犠牲にならないよう、より新しいバージョンのlog4jを非常に迅速にプロジェクトに取り込む必要がありました。 |
| • The distribution channels for software may themselves come under attack – this is what is commonly referred to as a “supply chain attack.” These sorts of attacks come in several forms. A malicious developer may decide to publish a version of the software that is intentionally flawed, and users that automatically update to the latest version may suffer a degradation in the capability of their system as a result. Malicious developers may publish copy-cat software using a similar name to a common piece of software that is malicious software, hoping that a user will accidentally download and use their malicious software. Finally, if a distribution channel is insufficiently hardened against attack, an adversary may be able to make changes to software in the distribution channel without the developer or using realizing it. | ・ソフトウェアの流通経路そのものが攻撃を受けることもあり、これは一般に「サプライチェーン攻撃」と呼ばれるものです。この種の攻撃には、いくつかの形態があります。悪意のある開発者が意図的に欠陥のあるバージョンを公開し、最新バージョンに自動更新したユーザーがシステムの機能低下を被る可能性があります。また、悪意のある開発者が、悪意のあるソフトウェアである一般的なソフトウェアに似た名称のコピーソフトウェアを公開し、ユーザーが誤ってその悪意のあるソフトウェアをダウンロードし使用することを期待する場合もあります。最後に、流通経路の攻撃対策が不十分な場合、敵対者は開発者や利用者が気づかないうちに流通経路上のソフトウェアに変更を加えることができるかもしれません。 |
| o Example: The author of a popular open-source package named “left-pad” grew disgruntled with the open-source community and intentionally deleted the software from the distribution service, briefly causing outages of several prominent websites and probably thousands of less prominent ones. |
o 例：「left-pad」という人気のあるオープンソースパッケージの作者が、オープンソースコミュニティに不満を持ち、意図的に配布サービスからソフトウェアを削除し、いくつかの著名なウェブサイトとおそらく数千のあまり著名ではないウェブサイトに一時的に障害を引き起こしました。 |
| o Example: The internal development environment at SolarWinds was compromised in a sophisticated supply chain attack that introduced malicious code into their proprietary (i.e. not OSS) software product, which in turn exposed the networks of dozens of governmental and commercial entities to attack. | o 例：SolarWinds 社の内部開発環境は、同社のプロプライエタリ（つまり OSS ではない） ソフトウェア製品に悪意のあるコードを導入する巧妙なサプライチェーン攻撃で侵害され、その結果、何十もの政府機関や商業団体の ネットワークが攻撃にさらされることになりました。 |
| Software Policy | ソフトウェアポリシー |
| The documents listed below are a few of the governing policies that relate to the secure use of opensource software by the Air Force. They are not intended to be comprehensive. | 以下に挙げる文書は、空軍によるオープンソースソフトウェアの安全な使用に関連する統治ポリシーの一部です。これらは包括的なものであることを意図していません。 |
| Executive Order 14028, Improving the Nation’s Cybersecurity (May 12, 2021) | 大統領令14028号「国家のサイバーセキュリティの改善」（2021年5月12日） |
| This executive order mandates several efforts to improve the cybersecurity posture of the country. Of particular note to the topic of software dependencies is section 4, “Enhancing Software Supply Chain Security.” This section mandates, among other things, the use of secure build environments for compiling software source code into usable programs and the creation of a Software Bill of Materials (SBOM) that is distributed with software that is utilized by the Federal government. This SBOM will assist in knowing what software dependencies exist within a project in order to accurately assess the overall risk of using that project, and to aid in the long-term maintenance and operations of the software. In the log4j example above, the Air Force’s use of SBOMs, described below, allowed for the rapid identification of systems that required an updated version of log4j. | この大統領令は、国のサイバーセキュリティ態勢を改善するためのいくつかの取り組みを義務付けています。ソフトウェアの依存関係のトピックで特に注目すべきは、セクション 4 の 「ソフトウェアサプライチェーンセキュリティの強化」 です。このセクションでは、特に、ソフトウェアのソースコードを使用可能なプログラムにコンパイルするための安全なビルド環境の使用と、連邦政府が利用するソフトウェアとともに配布されるソフトウェア部品表（SBOM）の作成が義務付けられています。このSBOMは、プロジェクト内にどのようなソフトウェアの依存関係があるかを知ることで、そのプロジェクトを使用する全体的なリスクを正確に評価し、ソフトウェアの長期的な保守と運用を支援するために役立ちます。上記のlog4jの例では、空軍が以下に説明するSBOMを使用することで、log4jの更新バージョンを必要とするシステムを迅速に特定することができました。 |
| DoD CIO Memo on Software Development and Open-Source Software (Jan 24, 2022) | ソフトウェア開発とオープンソースソフトウェアに関する国防総省CIOメモ(2022年1月24日) |
| This memorandum expands upon and clarifies a 2009 memo on open-source software use in the DoD. Key points included are that the use of open-source software is explicitly allowed in the DoD, that DoD personnel may contribute code to open-source software as part of their regular duties, and that the DoD must actively manage software supply-chain risk in accordance with the 2018 DoD Cyber Strategy. | このメモでは、国防総省におけるオープンソースソフトウェアの使用に関する2009年のメモを拡大し、明確化しています。含まれる主なポイントは、オープンソースソフトウェアの使用はDoDで明示的に許可されていること、DoD職員は通常業務の一環としてオープンソースソフトウェアにコードを提供できること、DoDは2018 DoD Cyber Strategyに従ってソフトウェアのサプライチェーン・リスクを積極的に管理しなければならないこと、などです。 |
| DoD Development, Security, and Operations (DevSecOps) Reference Design | DoDの開発、セキュリティ、運用（DevSecOps）リファレンスデザイン |
| The DevSecOps reference design outlines the technology, people, and procedures necessary to create a secure environment for developing and operating secure software. Software development organizations within the Air Force look to the reference design as a starting point for standing up a software development center. | DevSecOpsリファレンスデザインは、安全なソフトウェアを開発し運用するための安全な環境を構築するために必要な技術、人材、手順の概要を示しています。空軍内のソフトウェア開発組織は、ソフトウェア開発センターを立ち上げるための出発点として、このリファレンスデザインを参考にしています。 |
| Platform One Efforts to Enhance Software Supply Chain Security | ソフトウェアサプライチェーンセキュリティ強化のためのPlatform Oneの取り組み |
| Platform One is an Air Force organization that serves as enterprise provider of development, security, and operations tools and services for the DoD. These services include a secure gateway between secure government cloud environments and the commercial internet; a managed platform-as-a-service for developing and deploying cloud-based applications; the Iron Bank hardened container repository, and the Big Bang implementation of the DoD DevSecOps reference design. | Platform One は空軍の組織で、国防総省向けに開発、セキュリティ、運用のツールやサービスを提供する企業として活動しています。これらのサービスには、安全な政府クラウド環境と商用インターネット間の安全なゲートウェイ、クラウドベースのアプリケーションを開発・展開するためのマネージドPlatform-as-a-Service、Iron Bank Hardenedコンテナーレポジトリ、DoD DevSecOpsリファレンスデザインのビッグバン実装などが含まれます。 |
| Iron Bank (DoD Hardened Container Repository) | Iron Bank（国防総省の変更制限がかけられたコンテナリポジトリ ） |
| Platform One’s Iron Bank is a repository for container images, which is one of the most popular software packaging formats for both OSS and proprietary software that is designed to run in the cloud. Containers are a “cloud native” method of packaging containers and are widely used at Google, Amazon, Microsoft, Oracle, and virtually every organization that provides or hosts cloud-based software, including Platform One. Iron Bank adds several levels of security that today mitigate some of the risks mentioned above: | Platform OneのIron Bankは、コンテナイメージのリポジトリです。コンテナは、クラウドでの実行を前提としたOSSおよびプロプライエタリなソフトウェアの両方で、最も一般的なソフトウェアパッケージングフォーマットの1つとなっています。コンテナは「クラウドネイティブ」なパッケージング手法であり、Google、Amazon、Microsoft、Oracleをはじめ、Platform Oneを含むクラウドベースのソフトウェアを提供またはホストするほぼすべての組織で広く利用されています。Iron Bankは、上記のリスクを軽減するために、いくつかのレベルのセキュリティを追加しています。 |
| • When projects are onboarded, developer identities are verified, reducing the risk of a malicious developer intentionally inserting malicious code into a codebase. | ・プロジェクトに参加する際、開発者の身元を確認し、悪意のある開発者が意図的にコードベースに悪質なコードを挿入するリスクを低減します。 |
| • Copy-cat project names that might confuse users or developers into using the wrong project are not allowed. | ・ユーザーや開発者を混乱させ、間違ったプロジェクトを使用させる可能性のあるコピーキャットプロジェクト名は許可されません。 |
| • Automated security checks and validation by cybersecurity experts enforce best practices in the development of software containers, potentially reducing the severity of any “zero-day” vulnerabilities that may exist inside of that container. | ・サイバーセキュリティの専門家による自動セキュリティチェックと検証により、ソフトウェアコンテナの開発におけるベストプラクティスを実施し、コンテナ内に存在する可能性のある「ゼロデイ」脆弱性の深刻度を低減しています。 |
| • Software is compiled and packaged using secure “pipelines” that run inside of the governmentcontrolled software environment, protecting against the introduction of malicious code during the packaging process. | ・ソフトウェアは、政府が管理するソフトウェア環境内で実行される安全な「パイプライン」を使用してコンパイルおよびパッケージ化され、パッケージ化プロセス中に悪意のあるコードが混入しないように保護されます。 |
| • Software Bills of Materials (SBOMs) are generated for every container in the repository, allowing organizations using those containers to build an accurate, up-to-date inventory of software (including all the dependencies) running in their environment. | ・ソフトウェア部品表（SBOM）は、リポジトリ内のすべてのコンテナに対して生成され、コンテナを使用する組織は、その環境で実行されているソフトウェア（すべての依存関係を含む）の正確で最新のインベントリを構築することができるようになります。 |
| • Software in the repository is continuously scanned and compared to the most up-to-date list of Common Vulnerabilities and Exposures (CVEs), so that when a vulnerability is discovered it can be remediated in a timely fashion. | ・リポジトリ内のソフトウェアは継続的にスキャンされ、最新のCVE（Common Vulnerabilities and Exposures）リストと比較されるため、脆弱性が発見された場合、タイムリーに修正することができます。 |
| • The Iron Bank repository is hosted in a secure cloud environment and is continuously monitored and assessed according to DoD cyber security standards, ensuring the integrity and availability of the repository and securing it from attack by our adversaries. | ・ Iron Bankのリポジトリは安全なクラウド環境でホストされており、DoDサイバーセキュリティ基準に従って継続的に監視・評価され、リポジトリの完全性と可用性を確保し、敵対者からの攻撃から保護しています。 |
| Iron Bank has been a successful venture to date: there are approximately 1,000 containers available on Iron Bank, each of which has been assessed against DoD criteria for hardened containers. In the near term, Platform One is focused on improvements to allow Iron Bank to scale in an agile fashion. These include publishing fully automated assessments of a container image to provide fast, objective feedback to DoD organizations that are considering using a piece of software from Iron Bank (a “nutrition label” for a software container), increased use of digital signatures to validate the entire software supply chain, and automated notifications to users (on an opt-in basis) to notify them if they may be using a piece of software that has had a vulnerability disclosed. Because it is a centralized repository, Platform One can search across the repository for critical vulnerabilities (such as the log4j vulnerabilities) and notify anyone that is impacted by the vulnerability (this search is enabled by SBOMs, which provide an inventory of the software in a system). On occasion, the Iron Bank team has provided the first notification to OSS developers that one of their dependencies is vulnerable and needs to be updated. | Iron Bankはこれまで成功を収めてきました。Iron Bankで利用できるコンテナは約1、000個で、それぞれがハード化されたコンテナに関するDoDの基準に照らして評価されています。Platform Oneは、短期的には、Iron Bankをアジャイルに拡張できるようにするための改良に注力しています。これには、Iron Bankのソフトウェアの使用を検討しているDoD組織に迅速かつ客観的なフィードバックを提供するためのコンテナイメージの完全自動評価（ソフトウェアコンテナの「栄養ラベル」）の公開、ソフトウェアのサプライチェーン全体を検証するためのデジタル署名の利用拡大、脆弱性が公表されたソフトウェアを使用している可能性がある場合にユーザーに通知する自動通知（選択ベース）などが含まれます。Platform One は一元管理されたリポジトリであるため、重要な脆弱性（log4j の脆弱性など）をリポジトリ全体で検索し、脆弱性の影響を受けるユーザーに通知することができます（この検索は、システム内のソフトウェアのインベントリを提供する SBOM によって可能になっています）。Iron Bankチームは、OSS開発者に対して、依存関係の1つが脆弱であり、更新が必要であることを最初に通知することもあります。 |
| Big Bang (DevSecOps Reference Design Implementation) | ビッグバン（DevSecOpsリファレンスデザインの実装） |
| Secure software operations depend on both secure software and correct configuration of that software. Platform One provides a secure baseline for a Development, Security, and Operations (DevSecOps) under the name Big Bang. By adhering to the reference design, Big Bang provides compartmentalization of running applications to minimize the impact of any security incident, implements the services and connections to conduct active cyber defense, and runtime security to detect and neutralize threats to the applications. Big Bang also increases developer productivity and return-on-investment by providing a common baseline for developing and deploying applications. Big Bang is itself an open-source piece of software. Iron Bank (and other Platform One services) utilize Big Bang to provide a secure environment for hosting their applications. | 安全なソフトウェア運用は、安全なソフトウェアと、そのソフトウェアの正しい設定の両方に依存します。Platform Oneは、DevSecOps（開発、セキュリティ、運用）のためのセキュアなベースラインをBig Bangという名称で提供しています。リファレンスデザインに準拠することで、Big Bangは、実行中のアプリケーションを区分けして、あらゆるセキュリティ事故の影響を最小限に抑え、アクティブなサイバー防御を行うためのサービスと接続、およびアプリケーションに対する脅威を検出して無効化するランタイムセキュリティを実装しています。また、Big Bangは、アプリケーションの開発と配備に共通のベースラインを提供することで、開発者の生産性と投資対効果を向上させます。Big Bangはそれ自体がオープンソースのソフトウェアです。Iron Bank（および他のプラットフォーム・ワン・サービス）は、Big Bangを利用して、アプリケーションのホスティングに安全な環境を提供しています。 |
| Conclusion | まとめ |
| Iron Bank is a successful effort to reduce some aspects of supply chain risk for both open-source and proprietary/commercial software for DoD use. Software security (like cyber security in general) is a constantly evolving and constantly improving effort, not a line of effort that can be “completed” and then focus turned elsewhere. Iron Bank will continue to evolve as better techniques for avoiding software supply-chain risk are developed and implemented. By presenting an enterprise capability for consuming containerized software, Iron Bank users can avoid “re-inventing the wheel” and unnecessarily duplicating the work that has already been done. Finally, Iron Bank and Big Bang serve as foundational capabilities for building enterprise development, security, and operations solutions. | Iron Bankは、国防総省が使用するオープンソースおよびプロプライエタリ／コマーシャルソフトウェアのサプライチェーン・リスクの一部を低減するための取り組みとして成功しています。ソフトウェア・セキュリティ（一般的なサイバー・セキュリティと同様）は、常に進化し、常に改善される取り組みであり、「完了」して焦点を他に移すことができるような取り組みではありません。Iron Bankは、ソフトウェアのサプライチェーン・リスクを回避するためのより良い技術が開発・実装されるにつれて、進化し続けるでしょう。Iron Bankのユーザーは、コンテナ化されたソフトウェアを利用するためのエンタープライズ機能を提供することで、「車輪の再発明」や「すでに行われた作業の不必要な重複」を回避することができます。最後に、Iron BankとBig Bangは、エンタープライズ開発、セキュリティ、および運用ソリューションを構築するための基礎的な機能として機能します。 |
(2) [PDF] Mr. Brian Behlendorf, General Manager, Open Source Security Foundation
| Thank you for your invitation to address you today, and the opportunity to share with you the work being done within the Open Source Security Foundation and the broader open source software community to raise the level of security and trustworthiness of open source software. | 本日はお招きいただきありがとうございます。また、オープンソースソフトウェアのセキュリティと信頼性のレベルを高めるために、オープンソースセキュリティ財団と幅広いオープンソースソフトウェアコミュニティで行われている活動をご紹介する機会をいただき、ありがとうございます。 |
| 1. What are the consequences of insecure open-source software and what is industry as a whole, and the Open Source Security Foundation in particular, doing to tackle such Vulnerabilities? | 1. 安全でないオープンソースソフトウェアはどのような結果をもたらすのか、また、業界全体、特にオープンソースセキュリティ財団は、このような脆弱性に対処するためにどのようなことを行っているのか？ |
| Open source software (“OSS”) has become an integral part of the technology landscape, as inseparable from the digital machinery of modern society as bridges and highways are from the physical equivalent. According to one report, typically 70% to 90% of a modern application “stack” consists of pre-existing OSS, from the operating system to the cloud container to the cryptography and networking functions, sometimes up to the very application running your enterprise or website. Thanks to copyright licenses that encourage no-charge re-use, remixing, and redistribution, OSS encourages even the most dogged of competitors to work together to address common challenges, saving money by avoiding duplication of effort, moving faster to innovate upon new ideas and adopt emerging standards. | オープンソースソフトウェア（以下、OSS）は、橋や高速道路と同じように、現代社会のデジタル機器と切り離せない存在になっています。あるレポートによると、現代のアプリケーション「スタック」の70%から90%は、オペレーティングシステムからクラウドコンテナ、暗号化、ネットワーク機能、時には企業やウェブサイトを動かすアプリケーションまで、既存のOSSで構成されているという。無償で再利用、リミックス、再配布が可能な著作権ライセンスのおかげで、OSS は、最も頑強な競合他社でさえも協力して共通の課題に取り組み、重複作業を回避してコストを削減し、新しいアイデアに基づく革新や新しい標準の採用を迅速に行うことを後押ししています。 |
| However, this ubiquity and flexibility can come at a price. While OSS generally has an excellent reputation for security, the developer communities behind those works can vary significantly in their application of development practices and techniques that can reduce the risk of a defect in the code, or in responding quickly and safely when one is discovered by others. Often, developers trying to decide what OSS to use have difficulty determining which ones are more likely to be secure than others based on objective criteria. Enterprises often don’t have a well-managed inventory of the software assets they use, with enough granular detail, to know when or if they’re vulnerable to known defects, and when or how to upgrade. Even those enterprises who may be willing to invest in increasing the security of the OSS they use often don’t know where to make those investments, nor their urgency relative to other priorities. | しかし、このユビキタス性と柔軟性には代償が伴います。OSS は一般にセキュリティ面で高い評価を得ていますが、これらの作成物を支える開発者コミュニティは、コードに欠陥が生じるリスクを低減するための開発手法や技法の適用、あるいは欠陥が他者によって発見された場合の迅速かつ安全な対応に大きなばらつきがある場合があります。どのOSSを使うべきか、開発者はしばしば、客観的な基準に基づいて、どのOSSが他よりも安全である可能性が高いかを判断することが困難です。企業は多くの場合、使用しているソフトウェア資産のインベントリを十分に管理できておらず、既知の欠陥に対していつ脆弱性があるか、いつ、どのようにアップグレードすればよいかを知ることができません。使用するOSSのセキュリティ強化に投資する意思のある企業でも、どこに投資すべきか、また他の優先事項との比較でその緊急性が分からないことがよくあります。 |
| There are commercial solutions to some of these problems. There are vendors like Gitlab or Red Hat who sell support services for specific open source software, or even entire aggregate distributions of OSS. There are other vendors, like Snyk and Sonatype, who sell tools to help enterprises track their use of OSS and flash an alert when there is a new critical vulnerability in software running deep inside an enterprise’s IT infrastructure. | これらの問題のいくつかには、商業的な解決策があります。GitlabやRed Hatのように、特定のオープンソースソフトウェアや、OSSの集合ディストリビューション全体のサポートサービスを販売しているベンダーがあります。また、SnykやSonatypeのように、企業がOSSを利用している状況を把握し、企業のITインフラの奥深くにあるソフトウェアに新たな重要な脆弱性が見つかった場合に警告を発するためのツールを販売しているベンダーもあります。 |
| However, fighting security issues at their upstream source - trying to catch them earlier in the development process, or even reduce the chances of their occurrence at all - remains a critical need. We are also seeing new kinds of attacks that focus less on vulnerabilities in code, and more on the supply chain itself - from rogue software that uses “typosquatting” on package names to insert itself unexpectedly into a developer’s dependency tree, to attacks on software build and distribution services, to developers turning their one-person projects into “protest-ware” with likely unintended consequences. | しかし、セキュリティ問題を上流で解決すること、つまり開発プロセスの早い段階で発見すること、あるいは問題の発生確率を下げることは、依然として重要なニーズです。また、パッケージ名の「タイポスクワッティング」を利用して開発者の依存関係ツリーに不意に挿入する不正ソフトウェアや、ソフトウェアのビルドおよび配布サービスに対する攻撃、開発者が一人で行うプロジェクトを「プロテストウェア」に変えて意図しない結果を招くなど、コードの脆弱性よりもサプライチェーン自体に焦点を当てた新しい種類の攻撃が見られるようになりました。 |
| To address the urgent need for better security practices, tools, and techniques in the open source software ecosystem, a collection of organizations with deep investments into the OSS ecosystem came together in 2020 to form the Open Source Security Foundation, and chose to house that effort at the Linux Foundation. This public effort has grown to hundreds of active participants across dozens of different public initiatives housed under 7 working groups, with funding and partnership from over 75 different organizations, and reaching millions of OSS developers. | オープン ソース ソフトウェアのエコシステムにおけるより優れたセキュリティ手法、ツール、および技術の緊急の必要性に対処するため、OSS エコシステムに深く投資している組織の集まりが 2020 年に集まって Open Source Security Foundation を設立し、その取り組みを Linux Foundation に集約することを選択しました。この公的な取り組みは、75以上の異なる組織から資金提供やパートナーシップを受け、7つのワーキンググループの下に収容された数十の異なる公的なイニシアチブにわたって数百人のアクティブな参加者に成長し、数百万のOSS開発者に到達しています。 |
| The OpenSSF’s seven working groups are: | OpenSSF の 7 つのワーキンググループは次のとおりです。 |
| 1. Best Practices for Open Source Developers: This group works to provide open source developers with best practices recommendations, and easy ways to learn and apply them. Among other things, this group has developed courseware for teaching developers the fundamentals of secure software development, and implement the OpenSSF Best Practices Badge program. | 1. オープンソース開発者のためのベストプラクティス：このグループは、オープンソース開発者に対して、ベストプラクティスの推奨と、それを学び適用するための簡単な方法を提供するために活動しています。特に、このグループは、開発者に安全なソフトウェア開発の基礎を教えるためのコースウェアを開発し、OpenSSFベストプラクティスバッジプログラムを実装しています。 |
| 2. Securing Critical Projects: This group exists to identify and help to allocate resources to secure the critical open source projects we all depend on. Among other things, this has led to a collaboration with Harvard Business School to develop a list of the most critical projects. | 2. 重要なプロジェクトのセキュリティ確保：このグループは、私たち全員が依存している重要なオープンソースプロジェクトを特定し、その安全性を確保するためのリソースの割り当てを支援するために存在します。特に、ハーバード・ビジネス・スクールとのコラボレーションにより、最も重要なプロジェクトのリストを作成しました。 |
| 3. Supply Chain Integrity: This group is helping people understand and make decisions on the provenance of the code they maintain, produce and use. Among other things, this group has developed a specification and software called “SLSA”, for describing and tracking levels of confidence in a software supply chain. | 3. サプライチェーン・インテグリティ：このグループは、保守、生産、使用するコードの出所について、人々が理解し、意思決定できるよう支援しています。特に、ソフトウェアのサプライチェーンにおける信頼性のレベルを記述し、追跡するための「SLSA」と呼ばれる仕様とソフトウェアを開発しました。 |
| 4. Securing Software Repositories: This group provides a collaborative environment for aligning on the introduction of new tools and technologies to strengthen and secure software repositories, which are key points of leverage for security practices and the promotion to developers of more trustworthy software. | 4. ソフトウェアリポジトリの保護：このグループは、ソフトウェアリポジトリを強化し、安全性を確保するための新しいツールや技術を導入するための協力的な環境を提供します。このリポジトリは、セキュリティの実践と、より信頼性の高いソフトウェアの開発者への普及を促進するための重要なポイントです。 |
| 5. Identifying Security Threats in Open Source Projects: This group enables informed confidence in the security of OSS by collecting, curating, and communicating relevant metrics and metadata. For example, it is developing a database of all known security reviews of OSS. | 5. オープンソースプロジェクトにおけるセキュリティ脅威の特定：このグループは、関連するメトリクスやメタデータを収集、管理、伝達することにより、OSS のセキュリティに対する十分な信頼性を確保できるようにする。例えば、OSSの既知のセキュリティレビューのデータベースを構築しています。 |
| 6. Security Tooling: This group’s mission is to provide the best security tools for open source developers and make them universally accessible. Among other activities, this group has released code to better enable a security testing technique called “fuzzing” among open source projects. | 6. セキュリティツール：オープンソースの開発者に最適なセキュリティツールを提供し、汎用的に利用できるようにすることを目的とするグループです。特に、「ファジング」と呼ばれるセキュリティテスト技術をオープンソースプロジェクト間でよりよく利用できるようにするためのコードを公開しています。 |
| 7. Vulnerability Disclosures: This group is improving the overall security of the OSS ecosystem by helping advance vulnerability reporting and communication. For example, this group has produced a Guide to Coordinated Vulnerability Disclosure for OSS. |
7. 脆弱性の開示：脆弱性の報告・伝達を促進することにより、OSSエコシステム全体のセキュリティを向上させる活動をしています。例えば、このグループは、「OSSのための協調的な脆弱性開示のためのガイド」を作成しました。 |
| There are also a series of special projects under the OpenSSF worthy of special mention: | また、OpenSSFの下には、特筆すべき一連の特別プロジェクトがあります。 |
| ● Project sigstore: an easy-to-use toolkit and service for signing software artifacts, ensuring that the software you are holding is the same as what the developer intended, addressing a wide array of supply chain attacks. | ・プロジェクト sigstore: ソフトウェアの成果物に署名するための使いやすいツールキットとサービスで、手元にあるソフトウェアが開発者が意図したものと同じであることを保証し、さまざまなサプライチェーン攻撃に対応します。 |
| ● The Alpha-Omega Project: an effort to systematically search for new vulnerabilities in open source code, and work with critical open source projects to improve their vulnerability handling and other security practices. | ・Alpha-Omega プロジェクト：オープンソースコードの新しい脆弱性を体系的に検索し、重要なオープンソースプロジェクトと協力して、脆弱性の取り扱いやその他のセキュリティ慣行を改善する取り組みです。 |
| ● The GNU Toolchain Initiative: this effort supports the build ecosystems for perhaps the most critical set of developer libraries and compilers in the world, the GNU Toolchain, as a means to ensure its safety and integrity. | ・GNU Toolchainイニシアティブ: この活動は、おそらく世界で最も重要な開発者ライブラリとコンパイラのセットであるGNU Toolchainの安全性と完全性を保証する手段として、その構築エコシステムをサポートします。 |
| All the above efforts are public-facing and developed using the best practices of open source software communities. Funding from our corporate partners goes towards supporting the core staff and functions that enable this community, but all the substance comes from voluntary efforts. In some cases funds flow to assist with specific efforts - for example, recently the Alpha-Omega project decided to allocate funding towards the NodeJS community to augment its security team with a part-time paid employee and to fund fixes for security issues. | 上記のすべての努力は一般に公開され、オープンソースソフトウェアコミュニティのベストプラクティスを用いて開発されています。企業パートナーからの資金は、このコミュニティを実現する中核的なスタッフや機能の支援に使われますが、実質はすべて自発的な努力によってもたらされています。例えば、最近 Alpha-Omega プロジェクトは、NodeJS コミュニティに資金を割り当て、パートタイムの有給社員でセキュリティチームを増強し、セキュリティ問題の修正に資金を提供することを決定しました。 |
| The Linux Foundation has also begun to adapt its “LFX” platform, a set of services designed to support the open source communities hosted by the Foundation, to incorporate security-related data such as vulnerability scans from Snyk and BluBracket, along with information from the OpenSSF Best Practices Badge program and the OpenSSF Security Scorecards initiative, to provide a unified view of the security risks in a particular collection of open source code, and what maintainers and contributors to those projects can do to improve those scores and reduce those risks. We expect to see more kinds of risk-related data coming into a unified view like this, helping developers and enterprises make better decisions about what open source components and frameworks to use, and how to reduce risk for those components they depend upon. | Linux Foundation は、Linux Foundation がホストするオープンソースコミュニティを支援するために設計された一連のサービスである「LFX」プラットフォームに、Snyk や BluBracket の脆弱性スキャンなどのセキュリティ関連データ、および OpenSSF Best Practices Badge プログラムや OpenSSF Security Scorecards イニシアティブの情報を組み込み、特定のオープンソースコードの集合におけるセキュリティリスクと、それらのプロジェクトのメンテナと貢献者がそれらのスコアを向上させてリスクを低減するためにはどうしたらよいかについての統合ビューを提供し始めています。私たちは、このような統合ビューに、より多くの種類のリスク関連データが取り込まれ、開発者や企業が、どのオープンソースコンポーネントやフレームワークを使用するか、また、依存するコンポーネントのリスクをどのように低減するかについて、より良い判断を下せるようになることを期待しています。 |
| OpenSSF Security Scorecards initiative, to provide a unified view of the security risks in a particular collection of open source code, and what maintainers and contributors to those projects can do to improve those scores and reduce those risks. We expect to see more kinds of risk-related data coming into a unified view like this, helping developers and enterprises make better decisions about what open source components and frameworks to use, and how to reduce risk for those components they depend upon. | OpenSSF Security Scorecards initiative の情報と合わせて、特定のオープンソースコードのコレクションにおけるセキュリティリスクと、そのスコアを向上させリスクを低減するためにプロジェクトのメンテナや貢献者ができることを統一的に表示することができるようになります。私たちは、このような統合ビューに、より多くの種類のリスク関連データが取り込まれ、開発者や企業が、どのオープンソースコンポーネントやフレームワークを使用するか、また、依存するコンポーネントのリスクをどのように低減するかについて、より良い決定を下せるようになると期待しています。 |
| Guiding all of this is a deep conviction among the OpenSSF community that while there are many different ways in which security issues manifest themselves in the OSS ecosystem, every one of them is addressable, and that there are lots of opportunities for investment and collective action that will pay a return many times over in the form of lower risk of a future major vulnerability in a widely-used package, and lesser disruption if one is discovered. | OpenSSF コミュニティでは、OSS のエコシステムにおいてセキュリティ問題が顕在化する方法はさまざまですが、そのすべてに対処可能であり、広く利用されているパッケージにおいて将来重大な脆弱性が発生するリスクを低減し、脆弱性が発見された場合の混乱を少なくするという形で、何倍もの見返りがある投資と集団行動の機会が数多く存在する、という深い信念がすべての指針となっています。 |
| Other efforts at the Linux Foundation include “Prossimo”, an effort focused on moving core Internet-related services to “memory-safe” languages like Rust, Go, or Java, which would eliminate an entire category of vulnerabilities that other languages allow too easily. Another is the SPDX standard for Software Bill of Materials (“SBOMs”), addressing the needs identified by White House Executive Order 14028 in a vendor-neutral and open way. | 「Prossimo」は、インターネット関連のコアサービスをRust、Go、Javaなどの「メモリセーフ」な言語に移行することに焦点を当てた取り組みで、他の言語が容易に許してしまう脆弱性のカテゴリ全体を排除することができます。また、ソフトウェア部品表（SBOM）のためのSPDX標準は、ホワイトハウス大統領令14028によって特定されたニーズに、ベンダーニュートラルかつオープンな方法で対応するものです。 |
| This is by no means a comprehensive list of all such efforts in the OSS ecosystem to improve security. Every OSS foundation either has a security team in operation today or is scrambling to identify volunteers and funding to establish one. There is a greater emphasis today than I’ve seen in my 30 years of using and contributing to OSS (since before it was called OSS) on the importance of such efforts. Clear metrics for progress are elusive since we lack clear metrics for evaluating software risk; in fact developing ways to measure and represent that risk is a key priority for OpenSSF. We will never see a time when open source software is free from security defects, but we are getting better at determining the tools and techniques required to more comprehensively address the risk of vulnerabilities in open source code. Scaling up those tools and techniques to address the tens of thousands of widely used OSS components and to get them more quickly updated remains a challenge. | これは、OSSエコシステムにおけるセキュリティ向上のための努力のすべてを網羅したものでは決してありません。すべての OSS 財団は、現在、セキュリティチームを運営しているか、または、ボランティアと資金を調達してチームを設立しようと奮闘しています。私が30年間OSSを使い、OSSに貢献してきた中で（OSSと呼ばれる前から）、このような努力の重要性がより強調されているのです。ソフトウェアのリスクを評価する明確な指標がないため、進歩のための明確な指標は捉えにくい。実際、リスクを測定し表現する方法を開発することは、OpenSSFの主要な優先事項です。オープンソースソフトウェアにセキュリティ上の欠陥がなくなることはないでしょうが、オープンソースコードの脆弱性リスクにより包括的に対処するために必要なツールや技術を決定することについては、より良くなってきています。しかし、広く利用されている何万ものOSSコンポーネントに対応し、より迅速にアップデートするために、それらのツールや技術をスケールアップすることは、依然として課題として残っています。 |
| 2. How can the Federal government improve collaboration with industry to help secure open-source software? | 2. 連邦政府は、オープンソースソフトウェアのセキュリティ確保を支援するために、産業界との協力をどのように改善すればよいのでしょうか。 |
| I’ll focus here on principles and methods for collaboration that will lead to more secure OSS, and then for question 3 on specific opportunities to collaborate on. | ここでは、より安全なOSSにつながる協力の原則と方法に焦点を当て、質問3については、具体的な協力の機会について述べます。 |
| First, focus on resourcing long-term personal engagements with open source projects. | まず、オープンソースプロジェクトに個人的に長期的に関わるためのリソースを確保することに焦点を当てます。 |
| Over the last few years, we have seen a healthy degree of engagement by the Federal government with OSS projects and stakeholders on the topic of improving security. The push established by Executive Order 14028 for the adoption of SBOMs aligned nicely with the standardization and growing adoption of the SPDX standard by a number of OSS projects, but it was aided substantially by the involvement of personnel from NIST, CISA, and other agencies engaging directly with SPDX community members. | ここ数年、連邦政府による、セキュリティ向上というテーマでのOSSプロジェクトや利害関係者との健全な関わり合いが見られるようになりました。大統領令 14028 によって確立された SBOM の採用の推進は、多くの OSS プロジェクトによる SPDX 標準の標準化と採用の拡大にうまく合致していましたが、NIST、CISA、およびその他の機関の職員が SPDX コミュニティのメンバーと直接関わることによって、大幅に支援されました。 |
| Often the real secret to a successful OSS effort is in the communities of different stakeholders that come together to create it - the software or specification is often just a useful byproduct. The Federal government, both through its massive use of open source code and the role that it traditionally performs in delivering and protecting critical infrastructure, should consider itself a stakeholder, and like other stakeholders prioritize engagement with upstream open source projects of all sizes. That engagement need not be so formal; most contributors to open source projects have no formal agreement covering that work aside from a grant of intellectual property in those contributions. But as they say, “history is made by those who show up.” If the IT staff of a Federal agency (or of a contractor under a Federal contract) were authorized and directed to contribute to the security team of a critical open source project, or to addressing known or potential security issues in important code, or to participating in an OpenSSF working group or project, that would almost certainly lead to identifying and prioritizing work that would result in enhanced security in the Federal government’s own use of open source code, and likely to upstream improvements that make OSS more secure for everyone else. | OSSの成功の秘訣は、さまざまな利害関係者が集まって作るコミュニティにあることが多く、ソフトウェアや仕様は有用な副産物に過ぎないことがよくあります。連邦政府は、そのオープンソース コードの大規模な使用と、重要なインフラの提供と保護という伝統的な役割を通じて、自分自身をステークホルダーと考えるべきであり、他のステークホルダーと同様に、あらゆる規模の上流オープンソース プロジェクトとの関わりを優先させる必要があります。オープンソースプロジェクトの貢献者の多くは、その貢献に対する知的財産の供与を除けば、その仕事をカバーする正式な契約を結んでいないため、その関与はそれほど正式なものである必要はありません。しかし、よく言われるように、「歴史は、姿を現した人々によって作られる」のです。もし、連邦政府機関（または連邦政府との契約に基づく請負業者）の IT スタッフが、重要なオープンソースプロジェクトのセキュリティチームへの貢献、重要なコードにおける既知または潜在的なセキュリティ問題の対処、あるいは OpenSSF のワーキンググループやプロジェクトへの参加を許可され指示されたとしたら、ほぼ確実に、連邦政府自身のオープンソースコードの使用におけるセキュリティ強化につながる作業を特定して優先させ、他のすべての人にとって OSS をより安全にしてくれるアップストリーム改善につながる可能性があります。 |
| Second, engage in OSS development and security work as a form of global capacity building, and in doing so, in global stability and resilience. OSS development is inherently international and has been since its earliest days. Our adversaries and global competitors use the same OSS that we do, by and large. When our operating systems, cloud containers, networking stacks and applications are made to be more secure, there are fewer chances for rogue actors to cause disruption, and that can make it harder to de-escalate tensions or protect the safety of innocent parties. Government agencies in France, Taiwan, and more have begun to establish funded offices focused on the adoption, development, and promotion of OSS, in many ways echoing the Open Source Program Offices being set up by companies like Home Depot and Walmart or intergovernmental agencies like the WHO. The State Department in recent years has funded the development of software like Tor to support the security needs of human rights workers and global activists. The Federal government could use its convening authority and statecraft to bring like-minded activities and investment together in a coordinated way more effectively than any of us in the private sector can. | 第二に、グローバルな能力構築の一形態として OSS 開発とセキュリティ業務に従事し、そうすることで世界の安定と回復力を高めることです。OSS の開発は本質的に国際的なものであり、その初期からそうでした。私たちの敵対者やグローバルな競争相手は、大体において私たちと同じOSSを使用しています。私たちのOS、クラウドコンテナ、ネットワークスタック、アプリケーションをより安全なものにすれば、不正な行為者が混乱を引き起こす可能性は少なくなり、緊張の緩和や罪のない人々の安全を守ることが難しくなる可能性があるのです。フランスや台湾などの政府機関は、OSS の採用、開発、普及に焦点を当てた資金提供オフィスを設立し始めており、Home Depot や Walmart などの企業、または WHO などの政府間機関が設立しているオープンソースプログラムオフィスと多くの点で呼応しています。国務省は近年、人権活動家や国際的な活動家のセキュリティニーズをサポートするために、Tor のようなソフトウェアの開発に資金を提供しています。連邦政府は、その召集権限と国家統治を利用して、同じ考えを持つ活動や投資を、民間企業の誰よりも効果的な方法で協調させることができるでしょう。 |
| Third, many of the ideas for improving the security of OSS involve establishing services - services for issuing keys to developers like Project sigstore does, or services for addressing the naming of software packages for SBOMs, or services for collecting security reviews, or providing a comprehensive view of the risk of open source packages. Wherever possible, the Federal government should avoid establishing such services themselves when suitable instances of such services are being built by the OSS community. Instead of owning or operating such services directly, the Federal Government should provide grants or other resources to operators of such services as any major stakeholder would. Along similar lines, should the Federal government fund activities like third party audits of an open source project, or fund fixes or improvements, it should ensure not only that such efforts don’t duplicate work already being done, it should ensure that the results of that work are shared (with a minimum of delay) publicly and upstream so that everyone can benefit from that investment. | 第三に、OSSのセキュリティを向上させるためのアイデアの多くは、サービスの確立を伴います。プロジェクト sigstoreのように開発者に鍵を発行するサービス、SBOMのソフトウェアパッケージの命名に対処するサービス、セキュリティレビューを収集するサービス、オープンソースパッケージのリスクに関する包括的なビューを提供するサービス、などです。可能な限り、連邦政府は、OSSコミュニティによってそのようなサービスの適切なインスタンスが構築されている場合、そのようなサービス自体を確立することを避けるべきです。そのようなサービスを直接所有または運営する代わりに、連邦政府は、他の主要な利害関係者と同様に、そのようなサービスの運営者に補助金や他のリソースを提供するべきです。同様に、連邦政府がオープンソースプロジェクトの第三者による監査などの活動や、修正・改良に資金を提供する場合、そうした取り組みがすでに行われている作業と重複しないようにするだけでなく、その作業の結果を（最小限の遅れで）公的に、上流で共有し、誰もがその投資から利益を得られるようにする必要があります。 |
| These three approaches to collaboration would have an outsized impact on any of the specific efforts that the Federal government could undertake. | これら3つのコラボレーションへのアプローチは、連邦政府が行うことのできる具体的な取り組みのいずれに対しても、大きな影響を与えるでしょう。 |
| 3. Where should Congress or the Administration focus efforts to best support and secure the open-sourced software ecosystem as a whole? | 3. オープンソースソフトウェアのエコシステムを全体として支援し、保護するために、議会または行政はどこに焦点を当てるべきですか？ |
| The private sector and the Federal government have a common cause in seeing broad improvements in the security of OSS. I’m happy to share where I see the private sector starting to invest in enhanced OSS security, in the hopes that this may inspire similar actions from others. | 民間企業と連邦政府は、OSSのセキュリティに広範な改善を見るという共通の大義があります。民間企業がOSSのセキュリティ強化のために投資を始めているところを紹介し、それが他の企業の同様の行動を刺激することを期待しています。 |
| 1. Education. Very few software developers ever receive a structured education in security fundamentals, and often must learn the hard way about how their work can be attacked. The OpenSSF’s Secure Software Fundamentals courses are well regarded and themselves licensed as open source software, which means educational institutions of all kinds could deliver the content. Enterprises could also start to require it of their own developers, especially those who touch or contribute to OSS. There must be other techniques for getting this content into more hands and certifications against it into more processes. | 1. 教育。セキュリティの基礎について体系的な教育を受けたソフトウェア開発者はほとんどおらず、多くの場合、自分の作品がどのように攻撃されるかについて苦労して学ばなければなりません。OpenSSFのセキュアソフト基礎コースは評判が高く、それ自体がオープンソースソフトウェアとしてライセンスされているため、あらゆる種類の教育機関がコンテンツを提供することが可能です。また、企業は、自社の開発者、特にOSSに触れたり貢献したりする開発者に、このコースを要求し始めることができます。このコンテンツがより多くの人の手に渡り、より多くのプロセスで認証されるようにするための他のテクニックがあるはずです。 |
| 2. Metrics and benchmarks. There are plenty of efforts to determine what are suitably objective metrics for characterizing the risks of OSS packages. But running the cloud systems to perform that measurement across the top 100,000 or even 10,000 open source projects may cost more than what can be provided for free by a single company, or may be fragile if only provided by a single vendor. Collective efforts funded by major stakeholders are being planned-for now, and governments as a partner to that would not be turned away. | 2. 指標とベンチマーク。OSS パッケージのリスクを特徴付けるための適切な客観的指標を決定するための努力はたくさんあります。しかし、上位10万、あるいは1万のオープンソースプロジェクト全体でその測定を行うためのクラウドシステムを稼働させるには、一企業が無料で提供できる以上のコストがかかるかもしれないし、単一のベンダーが提供するだけではもろいかもしれません。主要なステークホルダーが資金を提供する集団的な取り組みが、今のところ計画されており、そのパートナーとしての政府も目を背けてはならないでしょう。 |
| 3. Digital signatures. There is a long history of U.S. Government standards for identity proofing, public key management, signature verification, and so on. These standards are very sophisticated, but in open source circles, often simplicity and support are more important. This is pulling the open source ecosystem towards Project sigstore for the signing of software artifacts. We would encourage organizations of all sorts to look at sigstore and consider it for their OSS needs, even if it may not be suitable for all identity use cases. | 3. デジタル署名。身元証明、公開鍵管理、署名検証などに関する米国政府の標準規格には長い歴史があります。これらの標準は非常に洗練されていますが、オープンソースの世界では、シンプルさとサポートがより重要視されることがよくあります。このため、オープンソースのエコシステムは、ソフトウェア成果物の署名のためのプロジェクト sigstoreに引き寄せられつつあります。私たちは、あらゆる種類の組織がsigstoreに注目し、たとえそれがすべてのIDユースケースに適していないとしても、OSSのニーズに合わせて検討することを推奨しています。 |
| 4. Research and development investments into memory-safe languages. As detailed above, there are opportunities to eliminate whole categories of defects for critical infrastructure software by investing in alternatives written in memory-safe languages. This work is being done, but grants and investments can help accelerate that work. | 4. メモリーセーフな言語への研究開発投資。上に詳述したように、メモリセーフな言語で書かれた代替品に投資することで、重要なインフラストラクチャー・ソフトウェアの欠陥の全カテゴリを排除する機会があります。この作業はすでに行われていますが、助成金や投資によってこの作業を加速させることができます。 |
| 5. Fund third-party code reviews for top open source projects. Most OSS projects, even the most critical ones, never receive the benefit of a formal review by a team of security experts trained to review code not only for small bugs that may lead to big compromises, but to look at architectural issues and even issues with the features offered by the software in the search for problems. Such audits vary tremendously in cost based on the complexity of the code, but an average for an average-sized code base would be $150K-250K. Covering the top 100 OSS projects with a review every other year, or even 200 every year, seems like a small price compared to the costs on US businesses to remedy or clean up after a breach caused by just one bug. | 5. 主要なオープンソースプロジェクトに対する第三者によるコードレビューに資金を提供する。ほとんどのOSSプロジェクトは、最も重要なものでさえ、コードをレビューする訓練を受けたセキュリティ専門家のチームによる正式なレビューの恩恵を受けることがありません。このチームは、大きな危険につながる可能性のある小さなバグだけでなく、アーキテクチャ上の問題や、問題を探すためにソフトウェアが提供する機能の問題まで見ることができます。このような監査は、コードの複雑さによってコストが大きく異なりますが、平均的な規模のコードベースであれば、15万～25万ドルが平均的なコストとなります。上位100のOSSプロジェクトを隔年で、あるいは毎年200のレビューでカバーすることは、たった1つのバグによって引き起こされた違反の後の改善や後始末に米国企業がかけるコストに比べれば、小さな金額のように思われます。 |
| 6. Invest into better supply chain security support in key build systems, package managers, and distribution sites. This is partly about seeing technologies like SBOMs, digital signatures, specifications like SLSA and others built into the most widely used dev tools so that they can be adopted and meaningfully used with a minimum of fuss. Any enterprise (including the Federal government) that has software certification processes based on the security attributes of software should consider how those tools could be enhanced with the above technologies, and automate many processes so that updates can be more frequent without sacrificing security. | 6. 主要なビルドシステム、パッケージマネージャ、流通拠点におけるサプライチェーンセキュリティのサポート強化に投資する。これは、SBOM、デジタル署名、SLSA などの仕様のような技術が、最も広く使用されている開発ツールに組み込まれ、最小限の手間で採用され、有意義に使用できるようにすることでもあります。ソフトウェアのセキュリティ属性に基づくソフトウェア認証プロセスを持っている企業（連邦政府を含む）は、これらのツールを上記の技術でどのように強化できるかを検討し、多くのプロセスを自動化することで、セキュリティを犠牲にすることなく更新をより頻繁に行えるようにする必要があります。 |
| These activities, if done at sufficient scale, could dramatically lower the risks of future disruptive events like we have seen. As a portfolio of different investments and activities they are mutually reinforcing, and none of them in isolation is likely to have much of a positive impact. Further econometrics research could help quantify the specific reduction of risk from each activity. But I believe that each represents a very cost-effective target for enhancing security in OSS no matter who is writing the check. | これらの活動は、十分な規模で行われれば、我々が見てきたような将来の破壊的事象のリスクを劇的に低下させることができる。さまざまな投資や活動のポートフォリオとして、これらは相互に補強し合うものであり、どれも単独ではあまり良い影響を与えないと思われます。さらに計量経済学の研究が進めば、それぞれの活動から得られる具体的なリスク軽減を定量化することができるでしょう。しかし、誰が小切手を切ろうと、それぞれが OSS のセキュリティを強化するための非常に費用対効果の高い目標であると私は信じています。 |
| Thank you again for the opportunity to share these thoughts with you. I look forward to answering any questions you may have or providing you with further information. | このような考えを共有する機会を与えていただき、改めて感謝いたします。また、ご質問やご相談がありましたら、お気軽にお問い合わせください。 |
| Sincerely, | 敬具 |
(3) [PDF] Ms. Amélie Erin Koran, Non-Resident Senior Fellow, The Atlantic Council
| Chairman Foster and Chairwoman Stevens and members of the Subcommitee, thank you for the opportunity to tesfy before you today. I am Amélie Koran, Non-Resident Senior Fellow in the Cyber Statecra Iniave at the Scowcro Center for Strategy and Security at The Atlanc Council. It is an honor and a pleasure to be here with Dr. Lohn and Mr. Behlendorf. | フォスター委員長、スティーブンス委員長、そして小委員会の皆さん、本日は証言の機会をいただき、ありがとうございます。私はアメリー・コラン、アトラン・カウンシルのスカウクロ戦略・安全保障センターで、サイバー・ステートクラ イブの非居住シニアフェローを務めています。Lohn 先生、Behlendorf 先生とご一緒にこの場にいられることを光栄に思います。 |
| At the Cyber Statecra Iniave, we work at the nexus of geopolics, technology, and security to help shape policy and beter inform and secure the users of technology. This work takes place in three clusters, the Geopolics of Cybersecurity, Securing Operaonal Technology, and Communies of Cyberspace. The Iniave strives to address strategic quesons by combining systems analysis, policymaker engagement, and the operaonal experience of our interdisciplinary praconer community. | サイバー・ステートクラ・インターナショナルでは、地政学、テクノロジー、セキュリティの接点で、政策の形成、テクノロジーの利用者へのより良い情報提供と安全確保に取り組んでいます。この活動は、「サイバーセキュリティの地政学」、「オペラオナル・テクノロジーのセキュリティ」、「サイバースペースのコミュニティ」という3つのクラスターで行われています。この研究所では、システム分析、政策立案者の関与、そして学際的な研究者コミュニティによるオペレーションの経験を組み合わせることで、戦略的な課題に取り組むよう努めています。 |
| In my opening remarks I’d like to discuss the impact of realisc and applicable acons that can be used to address beter securing the open-source soware ecosystem and how to educate developers and users more effecvely and responsibly. My views and perspecves come from a point of a contributor to open-source projects, a technician who’s worked in securing and operang systems in crical infrastructure, and one lucky enough to experience all of this within both public and private sectors at various levels and in different industries. | 冒頭では、オープンソースのソフトウェア・エコシステムをより安全にするために、また、開発者やユーザーをより効果的かつ責任を持って教育するために、現実的で適用可能な規範が与える影響についてお話したいと思います。私は、オープンソースプロジェクトの貢献者であり、臨床インフラのシステムのセキュリティと運用に携わってきた技術者であり、幸運にも公共・民間セクターの様々なレベルや業界でこれらすべてを経験することができたという立場から、見解と展望を述べたいと思います。 |
| Code is Speech and Infrastructure | コードはスピーチであり、インフラである |
| The concepts of open-source soware were not only intended to be something to free developers and creators of soware from the shackles of onerous licensing terms common for contemporary compung, but also a way to allow them, in a way that was natural for them, to freely express speech through code. The counterculture of the 1960s, mainly hobbyists and research sciensts, homed on university systems and networks supported by academia and the government, felt that the best way for technology to advance was sharing. While not on these networks, they met up at “fests” to share their hacks to get new capabilies out of systems they had available, or novels ways to improve what they had access to. | オープンソース・ソウェアのコンセプトは、ソウェアの開発者やクリエイターを、現代のコンピュターによくある煩わしいライセンス条項の束縛から解放するだけでなく、彼らにとって自然な形で、コードを通じて自由に言論を表現できるようにするためのものだったのです。1960年代のカウンターカルチャーは、主にホビーストや研究科学者たちが、大学のシステムや学術・政府によってサポートされたネットワークをホームとし、技術の進歩のための最良の方法は共有であると感じていました。このようなネットワーク上ではありませんが、彼らは「フェスティバル」に集まり、利用可能なシステムから新しい機能を引き出すためのハッキングや、利用可能なシステムを改善するための斬新な方法を共有しました。 |
| Fast forward a few decades, when personal compung started to take hold, more of this freeware made it into the hands of consumers, it was oen provided with an ask that if those users found it useful, to possibly drop a contribuon, in the way of monetary remuneraon or fixes to bugs, and thus a “share-a-like” model was born, and the alternave to copyright, a copyle, license model came into existence. These requirements of these licenses priorized sharing contribuons, embracing the logic that many eyes looking and working on such soware would more rapidly surface bugs and fixes, so long as these efforts came back to the core code. | 数十年前になりますが、パーソナルコンピュータが普及し始めると、このフリーウェアが消費者の手に渡るようになり、もしそのユーザーが有用だと感じたら、金銭的報酬やバグ修正といった形で貢献するよう求められることもありました。こうして「シェアアライク」モデルが誕生し、著作権の代替となるコピーライセンスモデルが存在するようになったのです。これらのライセンスの要件は、貢献を共有することを優先し、そのようなソフトウェアに目を向け、作業する多くの目が、これらの努力がコアコードに戻る限り、バグや修正をより迅速に表面化するという論理を受け入れています。 |
| As access to the Internet expanded, and such code became widely accessible, more and more projects, from applicaons to the core operang systems on which they ran, were available under these very permissible licenses known oen as open source. Most, if not all, were free with that caveat of a responsible user will contribute back to the code in line with the selected license of the original author. Some of these projects, as they grew, began to adopt governance models to support larger projects through management of resources, commits to the core code base, as well as laying out road maps for features and other changes. | インターネットへのアクセスが拡大し、そのようなコードに広くアクセスできるようになると、アプリケーションからそれらが動作するコアオペレーティングシステムまで、より多くのプロジェクトが、オープンソースとして知られる、非常に許容範囲の広いライセンスの下で利用できるようになりました。すべてではないにせよ、ほとんどのプロジェクトは、責任あるユーザが原作者の選択したライセンスに沿ってコードに貢献するという注意書きをもって、無料で提供されていました。これらのプロジェクトの中には、成長するにつれて、リソースの管理、コアコードベースへのコミット、機能やその他の変更に関するロードマップの作成などを通じて、より大きなプロジェクトをサポートするガバナンスモデルを採用するようになったものもあります。 |
| This core concept of project governance is one of the greatest challenges, yet also greatest opportunies in which this commitee and the government can assist the open-source movement. Governance is both a rudder and engine for projects, providing direcon and velocity, via an agreed upon route and stop or gates along the way to make sure everything is coming along as planned. JFK seng the goal of the US space program to land a man on the moon before the decade of the 1960s was out, was a form of governance. He gave the goal, set where the US technology efforts were to be focused, and worked with his partners in government to resource the acvity to achieve the goal, even if that leadership mantle was passed on. The process of how government evaluated progress and how that aligned with overall policy of the US also composed governance in that instance. It doesn’t always have to be overbearing but can also be inspiraonal. We need just this manner of governance now. | このプロジェクトガバナンスの核となる概念は、この委員会と政府がオープンソースムーブメントを支援する上で、最大の課題の一つであると同時に最大のチャンスでもあるのです。 ガバナンスはプロジェクトの舵でありエンジンであり、合意されたルートと、すべてが計画通りに進んでいるかどうかを確認するための途中の停止やゲートを通じて、方向性と速度を提供するものです。JFKは、1960年代の10年間が終わる前に、人間を月に着陸させるというアメリカの宇宙計画の目標を掲げたが、これはガバナンスの一形態でした。彼は目標を与え、アメリカの技術的な努力をどこに集中させるかを決め、政府内のパートナーと協力して目標達成のための活動を資源化しました。その際、政府がどのように進捗を評価し、それが米国全体の政策とどのように整合しているかというプロセスも、ガバナンスを構成していました。それは必ずしも威圧的である必要はなく、刺激的であってもいい。今、私たちはまさにこのようなガバナンスを必要としているのです。 |
| One of the original progenitors of the concern both in how much our modern society relies upon open-source code, but also provided the most stereotypical example of some of the most common failings was the Heartbleed vulnerability disclose din early 2014. I had the opportunity, through what some may consider luck, but also circumstance, to observe and parcipate in our government’s approach to handling this incident while on a leadership development rotaon at the Office of Management and Budget. | 現代社会がどれほどオープンソースコードに依存しているかという懸念の元祖の1つであり、また最も一般的な失敗のいくつかの最もステレオタイプな例を提供したのが、2014年初めに開示されたHeartbleed脆弱性です。私は、幸運にも、そして状況的にも、行政管理予算局でリーダーシップ育成の職務に就いている間に、この事件に対する政府の取り組みを観察し、それに参加する機会を得ました。 |
| One of the challenges which hampered a more comprehensive approach to triaging and responding to this event by the US Government was not understanding the vulnerability in a comprehensive manner. This was due to those in charge, having been only aware to the surface use of such technologies. The vulnerability ran much deeper than inially expected, but the lack of experience and actual technology literacy of the response coordinators and policymakers wasted me and resources in the inial response. | 米国政府によるこの事件のトリアージと対応へのより包括的なアプローチを妨げた課題の1つは、脆弱性を包括的に理解していなかったことです。これは、担当者がそのような技術の表面的な使用しか認識していなかったことが原因です。脆弱性は当初の予想よりはるかに深かったのですが、対応するコーディネーターや政策立案者の経験や実際の技術リテラシーが不足していたため、初動で私やリソースを無駄にしてしまったのです。 |
| While websites were a major part of our core digital economy and oen the most visible public face of the internet, the vulnerability in OpenSSL impacted the internet’s core infrastructure – its underbelly; compiled in the operang systems of the routers and switches, in the protocols, which made that lock icon useful. In short, we had a “baked in” issue with near billions of devices, as well as applicaons, which made response and resoluon more challenging that merely patching an offending applicaon. This challenge of confronng cracks in the foundaon of digital infrastructure would return, most recently in the Log4j response. | ウェブサイトはデジタル経済の中核であり、インターネットの最も目立つ顔でもありますが、OpenSSLの脆弱性はインターネットの中核インフラ、つまりその裏側にまで影響を及ぼしており、ルーターやスイッチのオペレーティングシステム、錠前のアイコンを便利にしているプロトコルにコンパイルされていました。つまり、何十億というデバイスやアプリケーションに「組み込まれた」問題であり、その対応と解決は、単に問題のあるアプリケーションにパッチを当てるだけでは困難なのです。デジタルインフラの基盤に生じた亀裂に立ち向かうというこの挑戦は、最近ではLog4jの対応で再来しています。 |
| What made Heartbleed so challenging, versus simply picking up the phone or dropping an email to a vendor such as a Microso, Google, Cisco, Amazon or Apple to ask them to modify their proprietary, non-open-source code, was that this was a project largely maintained by volunteers working in their free me out of interest. personal values, or the ulity this code had for them. That personal value and ulity statement carries true for the creaon of a lot of open-source soware we are familiar with today. | Heartbleedが非常に困難だったのは、Microso、Google、Cisco、Amazon、Appleなどのベンダーに電話をかけたりメールを送ったりして、彼らの所有権や非オープンソースのコードを修正するよう依頼するのとは異なり、このプロジェクトが主にボランティアによって、興味や個人の価値、このコードが彼らにとって持つ有用性から自由に活動していたことです。この個人的価値と有用性の声明は、今日私たちがよく知る多くのオープンソースソウェアの作成にも当てはまります。 |
| Open-Source Values and Governance | オープンソースの価値観とガバナンス |
| While we are gathered here to discuss out how to support the open-source community and foster this ecosystem, the phrase “we’re from the government, and we’re here to help” is somewhat an inhibitor. Government should foster collaboraon and create venues and opportunies for that, not creang another checklist or reporng mandate that adds more work or confuses the desired outcomes of securing crical open-source soware. | 私たちは、オープンソースコミュニティをサポートし、このエコシステムを促進する方法を議論するためにここに集まっていますが、「私たちは政府から来ました、助けるためにここにいます」というフレーズは、いくらか阻害要因になります。 政府は、コラボレーションを促進し、そのための場と機会を作るべきであり、仕事を増やしたり、重要なオープンソースソウェアのセキュリティ確保という望ましい結果を混乱させるような別のチェックリストや報告義務を作ったりしてはなりません。 |
| The execuve order from May of last year was a way to have agencies to conceptualize their challenges with managing open-source use and applicaon of such technology in their environments but does very litle to assist or address it anywhere else. It is a dark cloud over agencies and may sfle innovaon and self-determinaon, but also puts a chill over industry as it was so focused on Federal enes without expressing stronger needs to collaborate with the open-source community and supporng facilies. | 昨年5月の大統領令は、各機関がオープンソースの利用やその技術の適用を管理する上での課題を概念化するためのもので、それ以外の部分で支援や対処をすることはほとんどありません。また、オープンソースコミュニティや支援機関との協力の必要性を強く表明することなく、連邦政府のエネスに焦点を当てたため、産業界にも冷や水を浴びせることになりました。 |
| We’re here to discuss the best way for the agencies and their associated missions and programs can best support this challenge. This is not just an all of government problem to solve or address but is internaonal. Few in this space have acvely stepped up to take the reins. The world has witnessed our digital interdependency throughout the war in Ukraine, efforts to secure systems there have made Americans and our allies safer. In open-source soware, there is another opportunity for the United States to be a global leader and obtain some of the American exceponalism back in the global community as well as the open-source ecosystem. Potenal acons by Congress as well as agencies fall in line with regulaon, standards creaon, sector coordinaon, and even grantmaking efforts. Our challenge exists in figuring out where they can best interface and, quite literally, get the best bang for the buck. | 私たちは、各機関とその関連ミッションやプログラムが、この課題を最もよくサポートできる方法を議論するためにここに集まりました。これは、政府全体が解決すべき問題ではなく、国際的な問題なのです。この分野では、手綱を取るために積極的に踏み出す人はほとんどいません。ウクライナでの戦争を通じて、世界は私たちのデジタル相互依存を目の当たりにしてきました。オープンソースソフトウェアの分野では、米国がグローバルリーダーとして、国際社会とオープンソースエコシステムに米国の卓越性を取り戻すための別の機会があります。議会や政府機関による潜在的な取り組みは、規制、標準の作成、セクターの調整、そして助成金の取り組みと密接に関係しています。私たちの課題は、それらがどこで最もうまく接することができるか、そして文字通り、費用対効果に最も優れたものを得ることができるかということです。 |
| As I had my me at agencies, and most notably at Health and Human Services, which holds the tle of the largest grant-making authority in the world, it also contains the largest inspector general for oversight in all of the US Government, to ferret out waste, fraud and abuse. Add to the percepon that the cybersecurity industry has become filled with false or overleveraged promises, guaranteeing to chase aer every event and incident toung their wares. Adding a pot of money in the wrong hands or wrong place may atract many more bad actors to what is essenally a gold rush exacerbated by recent incidents from Solarwinds to Log4j, with many more desned to come. | 特に保健福祉省は、世界最大の助成金交付機関であると同時に、米国政府の中で最大の監視機関であり、無駄、詐欺、不正を発見する機関でもあります。さらに、サイバーセキュリティ業界は、偽りの、あるいは過大評価された約束で満ちており、自社の製品を売り込むあらゆる出来事やインシデントを追いかけることを保証している、という認識もあります。このような状況下、サイバーセキュリティ業界は、自社の製品に関連するあらゆる出来事やインシデントを追いかけることを保証する、偽りの、あるいは過大な約束で満ちています。間違った手や場所に大金があると、本質的にゴールドラッシュであるこの業界により多くの悪者が引き寄せられ、 Solarwinds や Log4j など、今後さらに多くの悪者が出てくると予想される事件が発生する可能性があります。 |
| However, this provides a good opportunity to engage private sector and non-profit enes already established to help interface with open-source soware projects on a level where these resources can be guided aer professional evaluaon and management into the right hands where they can do the most good. | しかし、このことは、オープンソースのソフトウェアプロジェクトに関わる民間企業や非営利団体を、これらのリソースが専門的な評価と管理を受け、最も良い結果をもたらすことができる正しい手に導かれるようなレベルで支援する良い機会を提供します。 |
| We are joined by one such organizaon, the Open Secure Soware Foundaon, under the wing of the Linux Foundaon, a not for profit established to help manage, maintain, and govern several key open-source, crical soware projects. Just a few months ago, the Apache Foundaon, which maintains several other essenal soware projects, and truly is an excellent example of longstanding and scalable governance frameworks joined the Senate to discuss open-source soware and Log4j. But these organizaons are rare when you look at the enre open-source ecosystem. Self-interest from a foundaon or other similar organizaon may occur, however subtly, by priorizing suggested changes, features, or even direcon by those who provide resources such as funding or staff me, at the detriment of addressing or solving something in a more democrac or egalitarian way from a less potenally parsan leadership. | 私たちは、そのような組織の1つであるOpen Secure Soware Foundaonに参加しています。Linux Foundaonは、いくつかの重要なオープンソース、臨床ソフトウェアプロジェクトの管理、保守、運営を支援するために設立された非営利団体です。ほんの数ヶ月前、Apache Foundaonは、他のいくつかの本質的なsowareプロジェクトを維持し、本当に長年にわたって拡張可能なガバナンスの枠組みの優れた例である、オープンソースのsowareとLog4jを議論するために上院に参加しました。しかし、オープンソースのエコシステム全体を見ると、このような組織は稀です。財団や他の類似の組織からの利己主義は、より民主的または平等主義的な方法で何かを解決するために、資金やスタッフのようなリソースを提供する人々が提案した変更、機能、あるいは指揮を優先することによって、たとえ微妙でも発生する可能性があります。 |
| Very few projects and code bases reach the scale to where they are lucky enough to become funded, managed and governed by foundaons like these. Some may be given resources by consumers of their code, potenally from larger organizaons that benefit from not having to pay licensing but feel it’s in their best interest to share back to help keep projects healthy, but oen nothing formalized as to who and how features, modificaons, and versions are planned and delivered. These are generally the ninety-nine percent of open-source soware projects, regardless of their perceived usefulness or crically to the proper operaon of our digital economy and infrastructure. | このような財団が資金を提供し、管理し、統治するような規模に達するプロジェクトやコードベースは、幸運にもごくわずかです。いくつかのプロジェクトやコードベースは、コードの消費者からリソースを与えられるかもしれませんし、ライセンスを払わなくても利益を得られるが、プロジェクトを健全に保つために還元することが最善の利益であると感じている大きな組織から与えられるかもしれません。このようなプロジェクトは、デジタル経済やインフラの適切な運用に対する有用性や批判性に関係なく、一般にオープンソースソウェアプロジェクトの99%を占めています。 |
| That one percent, curated by foundaons and other support models, oen, though maybe not as transparent, are oen beholden to the whims and wishes of their board benefactors, which come in the shape, in most cases from large technology companies that have integrated their code into their own products and services, thus creang a self-interest which is in opposion of organic and self-sustaining nature of open-source soware. In short, this takes many parallels to the old fire companies of large cies prior to the American Civil War, where response was priorized for those who paid your fire companies and was not a public good provided by the government. | その1パーセントは、財団やその他の支援モデルによって管理されていますが、透明性は高くないものの、理事会の後援者の気まぐれや意向に左右されることが多く、その後援者は、ほとんどの場合、自社の製品やサービスにコードを統合した大手テクノロジー企業の形をとっており、オープンソース ソフトウェアの有機性や自立性に反した自己利益を作り出しています。要するに、これは南北戦争前の大国の消防団と多くの類似点があり、消防団にお金を払う人たちのために対応が優先され、政府が提供する公共財ではなかったのです。 |
| This is something our discussion here should begin to address, which is to help find ways to triage crical, core, open-source digital infrastructure and provide the guidance necessary to engender trust in the use and ulizaon of it, but ensure that it’s care and feeding is addressed as the public good it was intended to be, rather than be beholden to what resources are applied to it by foundaon grants at the commercial level. We do have to tread carefully, as this may result in locking up future investments by those private sector technology organizaons, so an opportunity to coordinate and align should be a first step. | つまり、重要で中核的なオープンソースのデジタルインフラを選別し、その使用と活用に信頼を与えるために必要なガイダンスを提供し、そのケアと育成が、商業レベルの助成金によって適用されるリソースに依存するのではなく、公共財として対処されることを保証する方法を見つけることに、ここで私たちが取り組むべきことがあるのです。しかし、民間の技術系組織による将来の投資を制限することになりかねないので、慎重に行動しなければなりません。 |
| Standards and Validaon | 標準と評価 |
| While we look to NIST and the NCCoE as an essenal player in interfacing with the open-source community in the services it provides best, which is guidance and standards, we also need to lean on their methodology for assessments and validaon, such as in use for the FIPS encrypon process. The Special Publicaon series, colloquially known as the “SPs”, have been some of the most effecve naonal and internaonal contribuons to computer security the US government has created, and industry has voluntarily adopted or referenced. In my me as both a public servant, but also private sector employee, nearly every company and organizaon has used various SPs to use as a bar to reach or be measured by for compliance and addressing of gaps in their configuraons and operaons of technology environments. | NIST と NCCoE は、オープンソースコミュニティとの連携において、ガイダンスと標準化という最も優れたサービスを提供する重要なプレイヤーとして期待されていますが、FIPS 暗号化プロセスのような評価と検証のための手法にも注目する必要があります。特別公開シリーズ、通称「SP」は、米国政府が作成し、産業界が自主的に採用または参照した、コンピュータ・セキュリティに対する最も効果的な国内および国際的貢献の1つでした。私は公務員として、また民間企業で働く者として、ほぼすべての企業や組織が、技術環境の構成や運用におけるコンプライアンスやギャップへの対処のために、様々なSPを利用し、到達すべき基準としていることを実感しています。 |
| This is oen due to organizaons’ desires to work with government, and the requirements in many cases that systems be compliant to these standards and guidance, but also, in lieu of comprehensive best pracces developed by industry, since many technology environments are hybrids from many vendors, it is the only holisc method to ulize. However, this bar that is reached has been addressed as the high bar, rather than the minimum base to secure or migate threats to systems. This leaves many without the resiliency to take the eventual hit from a breach, atack, or other adverse event. | これは、政府との協働を望む組織や、システムがこれらの標準やガイダンスに準拠していることを要求する多くのケースによるものですが、多くの技術環境が多くのベンダーのハイブリッドであるため、業界が開発した包括的なベストプラクティスの代わりに、これが唯一の全体的手法となりました。しかし、この到達したバーは、システムを保護したり、脅威を回避したりするための最低限のベースではなく、高いバーとして扱われてきました。このため、侵害、攻撃、その他の有害事象から最終的な打撃を受けるための弾力性がないまま、多くの企業が放置されています。 |
| While the SP series addresses aspects of these systems and technologies in use, gaps remain for where this can assist making open-source soware more secure. Noted earlier, governance is a major component to success and long-term viability of open-source projects. What can be proposed here is to develop guidance that can be adopted by projects, large and small, like a “what to expect when you’re expecng an open-source project” book like you have for expectant parents, that provides tools and guidance on how to structure, build, operate and maintain such acvies. As NIST does, to convene experts to contribute to this guidance. It would be a good first step to be able to offer the open-source soware community at least a framework which projects at various stages can look to achieve or conform to, in this case a standard or guide for open-source project governance. | SP シリーズでは、このようなシステムや技術に対応していますが、オープンソースソフトウェアをより安全にするために役立つ部分については、まだギャップが残っています。先に述べたように、ガバナンスは、オープンソースプロジェクトの成功と長期的な存続のための主要な要素です。ここで提案できるのは、大小さまざまなプロジェクトが採用できるガイダンスを開発することです。たとえば、妊婦の両親のためにあるような「オープンソースプロジェクトに期待すること」という本を作り、そのような活動をどのように構成、構築、運用、維持するかについてのツールやガイダンスを提供することです。NISTが行っているように、このガイダンスに貢献する専門家を招集することです。少なくとも、オープンソースソフトウェアのコミュニティに、様々な段階のプロジェクトが達成または適合を目指せるような枠組み、この場合はオープンソースプロジェクトのガバナンスに関する標準やガイドを提供できるようになれば、良い最初のステップとなるでしょう。 |
| Leveraging the well-worn process for validaon, and the deep reach into the private sector for such services, as well as their stewardship of the naonal vulnerability database, NIST is in an enviable posion to share that knowledge and interface with soluons and services already trusted and used by a good poron of the developer and user community for open source. Offering frameworks to prepare key soware packages, potenally hosted at locaons such as GitHub and GitLab, among others, to go through a vulnerability validaon process, or, even as low-level as to provide or support build and test services for crical code bases is a workable way forward for NIST to have an effecve role in this space. Providing automated tools and services, those which make sense to automate, checking for well-known or obvious issues, but may not be a capability available to all developers, can free those developers to work on tougher, less-obvious issues that they can address. Services offered to Federal agencies, such as CARWASH for mobile applicaons, is one example that similarly can be developed and deployed. GitHub recently added and expanded availability of just such tools to commiters who ulize their services, including alerng users to insecure dependencies that have been imported into their code bases, a previously resource intensive, manual acvity for developers to perform on their own. | NIST は、よく知られた評価プロセスや、そのようなサービスに対する民間企業との深いつながりと、国内の脆弱性データベースの管理を活用して、知識を共有し、オープンソースの開発者やユーザーコミュニティの大部分からすでに信頼されて利用されているソリューションやサービスとのインターフェースを提供できる羨ましい立場にあります。GitHub や GitLab などにホストされている主要なソフトウェアパッケージを脆弱性評価プロセスにかけるためのフレームワークを提供すること、あるいは臨床コードベースのビルドおよびテストサービスを提供またはサポートすることは、NIST がこの分野で効果的な役割を果たすための有効な方法と言えます。自動化されたツールやサービスを提供することで、よく知られた問題や明白な問題をチェックし、自動化することに意味があるが、すべての開発者が利用できる能力ではないかもしれないものを、開発者は、より困難で明白でない問題に取り組むことができるようになるのです。モバイルアプリケーションのCARWASHのような連邦政府機関に提供されるサービスも、同様に開発・展開できる一例です。GitHubは最近、このようなツールを追加し、サービスを利用するコミッターに提供しました。このツールには、コードベースにインポートされた安全でない依存関係をユーザーに警告する機能が含まれていますが、これまでは開発者が自分で行うにはリソースが多く、手動の作業でした。 |
| Creaon of an independent Underwriters Laboratory (UL)-like for crical open-source soware programs, similar to what we have for more physical systems, is one path. This is something Germany has already undertaken as part of their involvement with vulnerability treatment efforts from OECD (Organizaon for Economic Co-operaon and Development), via regional TÜVs (Technischer Überwachungsverein), technical inspecon associaons, but we have yet to do at scale for soware system within the United States. Assurance is the name of the game when wondering if the latest bit of code they opted to ulize will adversely affect the operaons of their organizaon. | より物理的なシステムで行われているような、犯罪的なオープンソースソフトウェアプログラムのための独立した UL (Underwriters Laboratory) の設立は、1 つの道筋です。これは、OECD（経済協力開発機構）の脆弱性対策の一環として、ドイツが地域のTÜV（Technischer Überwachungsverein、技術検査協会）を通じてすでに取り組んでいることですが、米国内のソウェアシステムではまだ規模が大きくなっていません。しかし、米国内のソフトウェア・システムの規模では、まだ実現できていないのが現状です。 |
| This verificaon lab service like UL, would be voluntary for projects who wish to be used by crical infrastructure, but once through the process, can carry the trusted verificaon. The process should be agnosc, whether the code is maintained by a non-industry or sector affiliated individual or team, or a large corporaon who’s chose to create and steward a open source project. Much like you cannot pick and choose which physical infrastructure you should repair based on who it serves, the same model needs to apply here. The NSF in conjuncon with NIST are best candidates to develop this process and idenfy the metrics and measures required. If this gets to a state of internaonal collaboraon, this US Government agency partnership merely shall be subsumed as supporng affiliate members within the internaonal community. | ULのような検証ラボサービスは、臨床インフラで使用されることを希望するプロジェクトにとっては任意ですが、一度プロセスを通過すれば、信頼できる検証を行うことができます。このプロセスは、コードが業界やセクターに属さない個人またはチームによって管理されているか、オープンソースプロジェクトを作成し管理することを選択した大企業によって管理されているかに関係なく、アグノスティックであるべきです。物理的なインフラを修理する際に、それが誰に役立つかによって選ぶことができないのと同じように、ここでも同じモデルを適用する必要があるのです。NSFはNISTと共同で、このプロセスを開発し、必要な測定基準を特定する最良の候補者です。もしこれが国際的な協力関係にまで発展すれば、この米国政府機関のパートナーシップは、単に国際的なコミュニティ内の関連メンバーをサポートするものとして包含されることになります。 |
| Addionally, OSS projects should be providing an easy to use, understand, and apply soware bill of materials (SBOM), to assist with decision support for organizaons who opt to be opensource soware friendly consumers to determine if they picked a healthy soluon to base their operaons on. SBOMs offer a point in me view for checking the “ingredients list” through advanced soware composion analysis, offering up a role for NIST for maintaining a historical record or database of performance over me, that is searchable, similar to the Naonal Vulnerability Database (NVD) which is relied upon heavily for checking the status of known individual vulnerabilies in both open source and commercial soluons, but rarely is used to help analyze and risk score systems that may be composed of mulple packages and code bases, and leave consumers to make best guesses rather than data-based decisions on their consumpon of open-source soware. | さらに、OSSプロジェクトは、使いやすく、理解しやすく、適用しやすいソフトウェア部品表（SBOM）を提供し、オープンソースソフトウェアの消費者になることを選択した組織が、自分たちのオペレーションの基盤となる健全なソリューションを選択したかどうかを判断できるよう支援する必要があります。SBOMは、高度なソウェア合成分析を通じて「成分表」をチェックするための視点を提供し、NISTが検索可能な過去の記録やデータベースを維持する役割を提供します。NVD は、オープンソースと商用ソリューションの既知の個々の脆弱性の状態を確認するために多用されていますが、複数のパッケージとコードベースで構成されている可能性があるシステムの分析とリスクスコア付けに使用されることはほとんどなく、消費者はオープンソースソウェアの消費に関してデータに基づく決定ではなく、最善の推測をすることになります。 |
| Assessment, Categorizaon, and Triage | アセスメント、分類、トリアージ |
| Beyond the highlighted capabilies of the government to convene, collaborate and align resources at a naonal and internaonal level, it also can muster these resources at scale like no other enty, to support a public need. As seen from disaster response to military power, the typically maligned bureaucracy can be put aside in many cases to quite literally move mountains. | 政府は、国内および国際的なレベルでリソースを招集し、協力し、調整する能力を備えていることに加え、公共のニーズをサポートするために、他の組織と同様にこれらのリソースを大規模に集めることができます。災害対応から軍事力に至るまで、一般的に悪名高い官僚主義を脇に置いて、文字通り山を動かすことができるのです。 |
| Focusing this ability on a realm the US government is not necessarily the top of the heap in, requires a direct, focused, and paent touch. DHS, in their roles in coordinang sector security such as power, transportaon and others, has a unique role in applying guidance, but also working with such sectors to listen and work to correlate and priorize common needs. For crical open-source soware, CISA, NIST and research from NSF programs, should agnoscally assess, categorize, and triage the top projects of interest and work with those sector coordinang councils, developers, integrators, and consumers to remediate issues, develop resourcing strategies, and help with project governance. A task force from these agencies and components should be formed to operaonalize these first steps unl transioned to a more authoritave office or agency component. This cannot wait for typical legislave processes to hem and haw while these problems grow and are exacerbated daily. | この能力を、米国政府が必ずしもトップレベルではない分野に集中させるには、直接的、集中的、かつ穏やかなタッチが必要です。DHSは、電力、交通、その他といったセクターのセキュリティを調整する役割を担っており、ガイダンスを適用するだけでなく、こうしたセクターと協力して、共通のニーズに耳を傾け、関連付け、優先順位をつけるというユニークな役割を担っています。危機的なオープンソースソフトウェアについては、CISA、NIST、およびNSFプログラムの研究が、関心の高い上位プロジェクトを非球面的に評価、分類、およびトリアージし、これらのセクター調整協議会、開発者、インテグレータ、および消費者と協力して、問題を修正し、リソースの戦略を策定し、プロジェクトのガバナンスに協力する必要があります。より権威のある部署や機関に移行するまでは、これらの機関や部署からタスクフォースを結成して、これらの最初のステップをオペラ化する必要があります。このような問題が日々拡大し、悪化していく中で、典型的な立法府のプロセスを待っているわけにはいきません。 |
| For example, with local telephone companies, or even the US Postal service, for projects that may lack all the above, either due to size, resources, abandonment, or other complicaon, CISA and its partners essenally may become “carrier of last resort”. They should for a me, help with these efforts and look to match the project in its state at the me with willing supporters to shepherd it to a point where trust, reliability, and resilience can be achieved. Such a government led effort could be well complemented by an established volunteer network of open-source developers and security praconers, with the exisng goal of ‘swarming’ to important but underserved code to migate risk. | 例えば、地元の電話会社、あるいは米国の郵便局など、規模、リソース、放棄、その他の複雑さのために上記のすべてが欠けているプロジェクトでは、CISAとそのパートナーは本質的に「最後の手段」のキャリアになる可能性があるのです。CISAは、このような取り組みを支援し、その時点のプロジェクトの状態に合わせて、信頼性、信頼性、回復力を達成できる地点まで支援する意欲的な支援者を探す必要があります。このような政府主導の取り組みは、オープンソースの開発者とセキュリティ保護者の確立されたボランティアネットワークによって十分に補完される可能性があります。 |
| This carrier of last resort status is literally the “Hail Mary” for idenfied crical projects or code that have become crical but have lost all means of maintenance and support to keep the projects viable or interest other pares to maintain and connue developing. Somemes this may be due to the presence of very old code, change in status of a maintainer, or overall lack of interest beyond a release. Any effort to directly interface by the US Government must consider these cases and plan accordingly. | この最後の手段としてのキャリアは、文字通り、特定された危機的なプロジェクトや、危機的な状況に陥ったものの、プロジェクトを存続させるための保守やサポートの手段をすべて失ってしまったコード、あるいは他の組織が保守や開発の継続に関心を持つための「万能薬」なのです。これは、非常に古いコードの存在、メンテナの地位の変化、あるいはリリース以降の全体的な関心の欠如が原因である場合があります。米国政府による直接のインターフェイスへの取り組みは、このようなケースを考慮し、それに応じて計画する必要があります。 |
| Educaon and Stewardship | 教育とスチュワードシップ |
| Finally, it is very easy to focus on projects, their developers and the technical nits involved in open-source soware security. However, much like many of us should have learned in programs such as home economics in school, being a smart consumer is also paramount into driving adopon and use of such tools in our lives and communies. | 最後に、プロジェクトやその開発者、オープンソースソフトウェアのセキュリティに関わる技術的な些細なことに注目することは非常に簡単です。しかし、私たちの多くが学校の家庭科などで学んだように、賢い消費者であることは、私たちの生活や地域社会でこのようなツールを採用し使用する上で最も重要なことなのです。 |
| As a former Chief Technology Officer, along with Deputy Chief Informaon Officer and Enterprise Security Architect, I’ve had to consider the ramificaons and impacts to systems I was responsible for when selecng a technology strategy for my organizaon. It’s very easy for many organizaons to strictly focus on cost or features but miss the bigger picture of the total cost of ownership which includes looking at the lifecycle of such adopon. This results in many gaps for resources such as maintenance and operaons, but also inclusion of knowledge management, training, and awareness for both technology staff, but users who will be interacng with it. | 元最高技術責任者、副最高情報責任者、企業セキュリティアーキテクトとして、私は組織の技術戦略を選択する際に、担当したシステムへの影響と影響を考慮する必要がありました。多くの組織では、コストや機能ばかりに目が行きがちですが、導入のライフサイクルを含めた総所有コストという大きな視点を見逃しています。その結果、保守やオペレーションのようなリソースだけでなく、ナレッジマネジメント、トレーニング、そして技術スタッフだけでなく、それを利用するユーザーに対する認識など、多くのギャップが生じるのです。 |
| For developers, it’s also not just wring code, but consideraons far outside code quality and completeness, and should also dive into the realms of providing methods for interacng with data security and management, privacy, and user experience, which are, albeit abstract, but sll components of designing, building, and operang secure systems. Operaons and security staff are oen already overtasked and under resourced in many organizaons, so focusing on the design and build of secure code, whether it be proprietary or open source, helps remove any extra load on that staff, which translates up the chain to leaders and customers of organizaons who chose to ulize open source-based soluons. | また、開発者にとっては、単にコードを書くだけでなく、コードの品質や完全性だけでなく、データセキュリティや管理、プライバシー、ユーザーエクスペリエンスなど、抽象的ではありますが、安全なシステムを設計、構築、運用するための要素を考慮する必要があります。オペラオンスとセキュリティの担当者は、多くの組織ですでに過剰なタスクとリソース不足に陥っています。したがって、セキュアコードの設計と構築に注力することは、それがプロプライエタリかオープンソースかにかかわらず、担当者への余計な負荷を取り除くのに役立ち、それは、オープンソースのソリューションを選択した組織のリーダーや顧客にも波及していきます。 |
| While foundaons can help cover parts of these tasks through selecve engagement, guides, frameworks, and badge programs, there are sll gaps that need to be collaboravely addressed in partnership between the public and private sector. NIST through programs supported by NICE, provide well-established educaonal frameworks and interfaces with instuons without having to rework the proverbial wheel to establish relaonships and a curriculum. Having the private sector focus foundaonal resources to work directly with NICE can shorten the me and increase resources it would take to put efforts like those from OpenSSF into acon. | 財団は、選択的関与、ガイド、フレームワーク、およびバッジプログラムを通じてこれらのタスクの一部をカバーするのに役立ちますが、官民のパートナーシップで協力して対処する必要があるすべてのギャップが存在するのです。NISTは、NICEが支援するプログラムを通じて、確立された教育フレームワークと教育機関とのインターフェースを提供しており、関係やカリキュラムを確立するためにわざわざ車輪を作り直す必要はありません。民間企業がNICEと直接連携するための基盤的なリソースを集中させることで、OpenSSFのような取り組みを実現するために必要な時間を短縮し、リソースを増やすことができます。 |
| For example, by leveraging NICE, versus going alone, programs from OpenSSF and others can focus on developing lesson plans and content, as well as supporng or operang “hack-a-thons” to get ahead of open-source projects that may need a swarm of resources to shore up their security. It will remove the extra labor and me desired by such independent efforts to inially create those connecons with our educaon infrastructure. It is merely one match of many that the Federal government can make to help address these challenges. | 例えば、単独ではなくNICEを活用することで、OpenSSFやその他のプログラムは、レッスンプランやコンテンツの開発、また、セキュリティ強化のために多くのリソースを必要とするオープンソースプロジェクトに先んじるための「ハッカソン」の支援や運営に注力することができます。このような独立した努力によって、教育インフラとの接続を最初に作るための余分な労力と私を取り除くことができるのです。これは、連邦政府がこれらの課題に対処するためにできる多くの取り組みのうちの一つに過ぎないのです。 |
| Conclusion | まとめ |
| While all of this appears at first blush to appear a never ending and daunng task, parts of the soluon are in moon, but not enrely aligned or moving at the same speed and rhythm. Nong that government’s strengths exist in the power of collaboraon and coordinaon, but also the trust and faith many put into the instuon, it just takes the wherewithal and dedicaon openly, to commit to put the full weight of government and its resources behind it to make it happen. It has now arrived at a point where we can no longer hem and haw about what to do, because technology won’t wait or slow down to work at the pace of government, but government needs to act at the pace of technology and iterate its collaboraons at its speed to achieve results. | 一見すると、これらすべてが終わりのない困難な作業に見えますが、解決策の一部は月並みですが、同じスピードとリズムで揃って動いているわけではありません。政府の強みは、コラボレーションとコーディネーションの力だけでなく、多くの人が政府に寄せる信頼と信用にあるのですが、それを実現するためには、政府の全資源を投入する覚悟と献身的な姿勢が必要です。なぜなら、テクノロジーは政府のペースに合わせるために待機したり速度を落としたりしませんが、政府はテクノロジーのペースに合わせて行動し、そのスピードに合わせてコラボレーションを繰り返し、結果を出すことが必要だからです。 |
| Trust your experts, listen, learn, and build these relaonships to help support forward leaning decisions rather than to strictly react. Use the power of automaon to help address some of the easy problems, and allow, oen the inelasc and unscalable resources, of smart people, try to crack some of the bigger nuts and problems by geng them me to work together and offering venues opportunies to solve by sponsoring such collaboraon efforts. Open-source soware survives by many people working together to apply themselves to a problem, find a way to work within those models. | 専門家を信頼し、耳を傾け、学び、このような関係を構築することで、厳格に対応するのではなく、前向きの意思決定を支援することができるのです。自動化の力を使って簡単な問題に対処し、非実際的で拡張不可能なリソースである賢い人たちに、一緒に仕事をするように促し、そのような共同作業の努力を支援することで解決の機会を提供することによって、大きなナットや問題のいくつかを解決しようとするのです。オープンソースソフトウェアは、多くの人々が協力して問題に取り組むことで、そのモデルの中で働く方法を見つけることで生き残ります。 |
« 英国 NCSC 組織体向けコネクテッド・デバイスの組織的利用 (2022.05.10) | Main | 経済産業省 産業構造審議会 知的財産分科会 不正競争防止小委員会 中間報告書、秘密情報の保護ハンドブック等 »
Comments