2022年、セキュリティはLinuxおよびオープンソース開発者にとって最優先事項となるでしょう。
Linuxとオープンソースソフトウェアはこれまで以上に注目されるようになりますが、実際の変化はそれらのセキュリティの仕組みにあります。
Linuxは至る所にあります。すべてのクラウド、Microsoft Azureさえも、Linux上で動いています。すべての500のトップ500スーパーコンピュータを動かしているのもLinuxです。実際、デスクトップLinuxも成長しています。Pornhubによれば、Linuxユーザーは28%増加し、Windowsユーザーは3%減少したとのことです。
オープンソースソフトウェアは急速に成長しています。ガートナーの2021年のオープンソースソフトウェア（OSS）向けハイプサイクルによれば、「2025年までに、70%以上の企業が現在のIT支出と比較してOSSへのIT支出を増加させるでしょう。また、2025年までに、ソフトウェア・アズ・ア・サービス（SaaS）がOSSの消費モデルとして好まれるようになるでしょう。その理由は、より優れた運用の簡素さ、セキュリティ、スケーラビリティを提供する能力にあります。」
データベースについて考えると、企業ソフトウェアの根幹であるビーフとポテトに関して、ガートナーは新しい社内アプリケーションの70%以上がオープンソースデータベース上で開発されると予測しています。同時に、既存のプロプライエタリリレーショナルデータベースインスタンスの50%は、オープンソースDBMSに変換されたか、変換中であるとされています。
その数字を買います；私は最初の日からLinuxとオープンソースソフトウェアを追い続けています。行く先々で、話す人々はその二人がソフトウェアの宇宙を運営していることを認めています。
しかし、スパイダーマンが知っているように、大きな力には大きな責任も伴う。そして、多くの開発者が最近、Apache JavaロギングのオープンソースライブラリであるLog4j2に複数のセキュリティ脆弱性が発見された時に知ったように、それはまた大きな頭痛も伴う。
log4j2の問題は最悪の中でも最悪です。国家脆弱性データベース（NVD）の尺度では、CVSSv3で10.0と評価されており、まさにひどいものです。
本当の問題は、オープンソース自体ではなく、オープンソースの方法論やセキュリティに特別な魔法があるわけではありません。セキュリティのミスは依然としてコードに入り込む可能性があります。
リーナスの法則は「十分な目があれば、すべてのバグは浅い」というものです。しかし、開発者の目が足りなければ、セキュリティの脆弱性は見逃されることになります。私が現在シュナイアの法則と呼んでいるものは、「セキュリティはプロセスであり、製品ではない」と言っています。これは、すべてのソフトウェアを保護するためには常に警戒が必要であることを示しています。
とはいえ、log4jの本当の厄介なところは、Javaがソースコードとバイナリで使用しているライブラリを多数のJavaアーカイブ（JAR）のバリエーションの中に隠してしまうことです。その結果？ あなたは脆弱なバージョンのlog4jを使用しているかもしれず、実際に悪用されるまで気付かないでしょう。
Anchoreのセキュリティ担当副社長であるジョシュ・ブレッサーズが最近説明したように、「log4jの脆弱性がもたらす課題の一つは、それを実際に見つけることです。Javaアプリケーションや依存関係は通常、配布と実行を非常に簡単にするようなパッケージ形式で存在しますが、それらのソフトウェアパッケージの内部が何であるかを把握することは難しい場合があります。」
幸運なことに、使用中の不良な log4j ライブラリを見つけるのに役立つ log4j スキャナーがあります。しかし、彼らは完璧ではありません。
log4jの混乱の背後には別の問題があります。それは、ソフトウェアがどのオープンソースコンポーネントを使用しているかをどのように知るかです。例えば、log4j2は2014年から使用されています。今日まだ使用しているプログラムで最初のバージョンを使用したかどうかを誰も覚えているとは期待できません。
その答えは、オープンソースコミュニティが最近数年で真剣に考え始めたものの一つです: ソフトウェア部品表（SBOM）の作成です。SBOMは、任意のプログラムで使用されているソフトウェアライブラリ、ルーチン、およびその他のコードが正確に何であるかを明示します。これを用いて、あなたのプログラムで使用されているコンポーネントのバージョンを調べることができます。
デイビッド・A・ウィーラー（Linux Foundationのオープンソースサプライチェーンセキュリティディレクター）が説明しているように、SBOMと検証済みの再現可能ビルドを使用することで、自分のプログラムの内容を確実に把握できます。そうすれば、コンポーネントにセキュリティホールが見つかった場合、問題のコードを見つけるために必死に探すのではなく、単にパッチを当てることができるのです。
「再現可能なビルド」とは、同じ入力があった場合に常に同じ出力を生成するものであり、そのビルド結果の検証が可能であるとウィーラーは説明しています。検証された再現可能なビルドは、独立した組織がソースコードからビルドを生成し、そのビルド結果が主張されたソースコードから来ていることを確認するプロセスです。
これを行うためには、あなたとあなたの開発者は、Linux Foundationのソフトウェアパッケージデータ交換（SPDX）フォーマットを使用して、プログラムをSBOMで追跡する必要があります。その後、あなたのコードが本当に主張しているものであることをさらに保証するために、Codenotary Community Attestation ServiceやTidelift Catalogsなどのサービスを使用して、SBOMを公証し、検証する必要があります。
全てこれは言うのは簡単ですが、行うのは難しいです。
2022年には、オープンソースの開発者たちは自分たちのコードに問題がないかを確認するために多くの時間を費やし、その後SPDXベースのSBOMを構築することになるでしょう。Solarwindタイプの災害やlog4jのセキュリティ問題を心配するユーザーたちは、こうしたものを要求するでしょう。
同時に、Linuxの開発者たちはRustをLinuxの第二言語にすることで、オペレーティングシステムのさらなるセキュリティ強化に取り組んでいます。なぜなら、Cとは異なり、Linuxの主要言語であるRustははるかに安全だからです。具体的には、Rustはメモリエラーの処理においてCよりもずっと安全です。
マイクロソフトのプリンシパルクラウド開発者アドボケイトであるライアン・レヴィックは次のように説明しました。「Rustは完全にメモリ安全です。」これは非常に重要なことで、2019年のLinuxセキュリティサミットでLinuxカーネル開発者のアレックス・ゲイナーとジェフリー・トーマスが指摘したように、Linuxカーネルのセキュリティホールの約3分の2がメモリ安全性の問題から生じているからです。それらはどこから来るのでしょうか？CおよびC++の固有の問題です。
Linuxはこの十年の間にRustで書き直されることはありません（2030年代にまた確認してください）。しかし、これから多くのLinuxドライバーやその他のコードがRustで書かれることになるでしょう。
リーナス・トーバルズが私に言ったように、彼は「決してRustを『押す』ことはないが、約束された利点を考慮し、安全の落とし穴を避けるためにそれに対してオープンだ」と。
それでも、彼は結論付けた。「時には約束が実現しないこともあるということも知っている。」
すべてがどのようにうまくいくか見てみましょう。私が確かに知っていることのひとつは、2022年にはコードのセキュリティがLinuxやオープンソースの開発者にとって最重要課題になるということです。両者は、他のどの方向にも進むにはあまりにも重要になっています。