ソフトウェア署名からコンテナ イメージ、新しい Linux ディストリビューションに至るまで、新たな OSS スタックは、ビルド システムとソフトウェア成果物の整合性を管理するためのガードレールを開発者に提供しています。
SolarWindsとLog4jは、ソフトウェア成果物とビルドシステムのセキュリティの脆弱性、いわゆる「ソフトウェアサプライチェーンセキュリティ」問題に業界を目覚めさせた5つの警鐘でした。しかし、ビルド環境をロックダウンするための具体的な手順を模索している開発者やセキュリティエンジニアリングチームにとって、これは困難な状況でした。
ホワイトハウスが2021年5月に出した国家のサイバーセキュリティ向上に関する大統領令では、ソフトウェア部品表（BOM）の登場が予告されていた。BOMとは基本的に、ソフトウェアパッケージに含まれる構成要素のリストであり、政府の技術調達に必要な認証および開示プロセスを確立するものである。
セキュリティベンダー各社がソフトウェアサプライチェーンのセキュリティに関して自社製品を隠蔽しようと懸命に努力しているにもかかわらず、SBOM（ソフトウェアサプライチェーン管理）をどのように構築・維持すべきかは依然として明確ではありません。連邦政府機関の長に宛てた最近のメモでは、「安全なソフトウェア開発環境の重要性」を強調するのみで、それをどのように実現すべきかについては、ほとんど有益な説明がされていません。
しかし、Linux は再びこの難問の解決に役立つ可能性がある。
ベストプラクティスを模索する難しいセキュリティ領域
歴史が示すように、開発者はシステムのセキュリティ確保において推測に頼る必要のないプロセスに従います。ただし、それはワークフローへの影響を最小限に抑えつつ、明確で規範的な手順が定められている場合に限られます。例えば、Let's Encryptは、以前は複雑で煩雑だったトランスポート層セキュリティの領域を容易に解決した認証局です。Let's Encryptは多くの開発者に採用され、非常に短期間でWebの大部分でTLSをロックダウンしました。
参照: ダークウェブ監視サービスでサイバー犯罪からビジネスを守る (TechRepublic Academy)
しかし、このソフトウェアサプライチェーンのセキュリティ問題は、TLSよりもはるかに複雑です。ビルドシステム、CI/CD、プログラミング言語とそのレジストリ、開発者が使用するすべてのフレームワークとその管理チェーンに関係します。この課題の根底にあるのは、オープンソースソフトウェアの普遍性、開発者が構築するすべてのシステムで共有されるOSSフレームワークの推移性、そして非常に人気のあるOSSプロジェクトが一般的に受けているサポートの不足です。
問題の深刻さについて、多くの声高な抗議や警告が飛び交っています。しかし、開発者やセキュリティエンジニアは実際に何をすべきなのでしょうか？
新興スタックからの新たな答え
ソフトウェアサプライチェーンのセキュリティ課題と、OSSメンテナーに正しい（安全な）行動をとるようインセンティブを与えることの複雑さを解決するには、いくら資金を投入しても無駄です。必要なのは、開発者にセキュリティを委ね、同時にソフトウェアサプライチェーンのセキュリティ確保プロセスをガードレールで保護する適切なツールです。
ここ数ヶ月、ソフトウェアサプライチェーンの課題の重要な側面に取り組むオープンソースプロジェクトが次々と立ち上がっています。新たなスタックが形成されつつあり、ソフトウェアサプライチェーンのセキュリティに関する理論的な議論が、実際の実装やベストプラクティスの改良へと飛躍していくのが間近に迫っていると考えています。
まず、Google発のオープンソースプロジェクトであるSigstoreは、ソフトウェア署名と成果物の信頼のルートに焦点を当てており、3大プログラミング言語レジストリすべてが公式に採用する事実上の標準方式となっています。GitHubは最近、JavaScriptのnpmパッケージにSigstoreを使用していると発表しました。PythonはPyPiレジストリにSigstoreを使用し、JavaはMavenにSigstoreを使用しています。今年の夏には、KubernetesもSigstoreを搭載してリリースされました。
第二に、SLSA（「サルサ」と発音）とセキュア・ソフトウェア開発フレームワーク（SSDF）は、ソフトウェア・サプライチェーンのセキュリティ確保のプロセスを明示的にガイドするフレームワークとして、同様に広く採用されています。米国の国家安全保障の重鎮であるNSA、CISA、ODNIは、最近発表した報告書「開発者向けソフトウェア・サプライチェーンのセキュリティ確保ガイド」の中で、SLSAとSSDFをそれぞれ14回と38回参照しています。
Wolfi と呼ばれる新しいディストリビューションは、パズルの重要な新しいピースとなる可能性があります。
Linuxが再び救世主となる
Dan LorencとKim Lewandowskiは、Googleでの正式な役職時代に共同で立ち上げたSigstore、SLSA、そして関連するオープンソースの取り組みを支えるダイナミックなデュオです。スタートアップにおいてソフトウェアサプライチェーンをデフォルトで安全にするという使命を掲げ、彼らはChainguardを共同設立しました。そして本日、彼らはソフトウェアサプライチェーンのセキュリティに特化した初のLinuxディストリビューション、Wolfiをリリースしました。
参照：パスワード侵害：ポップカルチャーとパスワードが混ざらない理由（無料PDF）（TechRepublic）
なぜ新しいディストリビューションが必要なのでしょうか？結局のところ、重大な脆弱性や脆弱性への現在のアプローチには大きな盲点があるのです。Linuxディストリビューションやパッケージマネージャーは、ソフトウェアパッケージの最新バージョンを配布していないことが多く、開発者はこれらの境界外でアプリケーションをインストールすることがよくあります。コンテナの台頭と、既存のディストリビューションよりもはるかに迅速に最新アプリケーションをリリースできるようになったことで、独自のLinuxカーネルをホストするユーザーも増加しています。セキュリティベンダーが使用するスキャナーは、パッケージマネージャーやディストリビューションの外部にインストールされたコンテナイメージを検出できず、その結果、コンテナイメージ内に存在する様々な脆弱性を見逃してしまうのです。
これが重要なのは、環境内で実行されていることすら知らないソフトウェア成果物のセキュリティを測定することは明らかにできないからです。この教訓は、開発者とセキュリティ エンジニアを慌てさせた Log4j の脆弱性から得られた大きな成果の 1 つです。
Wolfiは、この問題を解決しようとしています。Wolfiは、Chainguardがソースから構築した非ディストリビューションであり、アップストリームパッケージから最終的なコンテナイメージに至るまで、SBOM、署名、コンプライアンスをあらゆる段階で確保しています。Chainguardは、Wolfiを使用することで、開発者はバイナリ解析スキャンを行う必要がなくなり、SBOMは事後ではなくソフトウェアのビルド時に作成されると主張しています。
Chainguardは今年初め、安全なソフトウェアサプライチェーン向けに設計された、ディストリビューションレスなコンテナベースイメージとして初めてChainguard Imagesを発表しました。Chainguard Imagesは、既知の脆弱性ゼロを目指し、継続的に更新されるコンテナベースイメージです。ChainguardはWolfiと共同で、ソフトウェアサプライチェーン向けのデフォルトのセキュリティ対策を備えたコミュニティLinuxディストリビューションを開発しました。現在、スタンドアロンバイナリ、nginxなどのアプリケーション、GoやCコンパイラなどの開発ツールのベースイメージが同梱されています。
なぜ非ディストリビューションなのか？Chainguardによると、「コンテナは本質的に不変（つまりアップグレード/ダウングレードは不要）であり、カーネルはホストによって提供される（パッケージマネージャーがさらに簡素化される）。簡単に言えば、ディストリビューションは今日のソフトウェア構築方法を想定して設計されていない」とのことだ。
このスタックがシフトレフトセキュリティに何を意味するか
2000 年代初頭、LAMP スタック (Linux、Apache、MySQL、Perl、Python) の台頭は、現代の Web アプリケーション出現の大きなきっかけとなり、開発者に安定した使い慣れたツール セットを提供し、テクノロジー業界史上最大のイノベーションの波の 1 つにつながりました。
ソフトウェアサプライチェーンのセキュリティスタックをめぐる現在の進化にも、似たような傾向が見られます。セキュリティは着実に開発者へとシフトしており、開発者が自らビルド環境にセキュリティを強化できるよう、より多くのガードレールが必要であることは認識していますが、その理解は非常に困難な領域となっています。
開示: 私は MongoDB で働いていますが、ここで表明されている意見は私自身のものです。
