この記事はネットワーク研究所の最初の公式アカウントです。WeChat をフォローして詳細をご覧ください。
2021 年 12 月の Log4j 侵害は、ソフトウェア サプライ チェーンがセキュリティにおいて極めて無視されている領域であることを浮き彫りにしました。それは、私たちのソフトウェア成果物がどのように相互接続されているか、そして私たちのシステムがどのようにその最も弱いリンクと同じくらい安全であるかを明らかにします。
また、これは、セキュリティは購入できるものだと私たちが考えているかもしれないが、実際には開発チームとしてどのように運営するかが重要であるという考えを強化します。
それ以来、私たちは改善に努めてきました。
おそらく最も注目に値するのは、Google のオープンソースの Sigstore プロジェクトが、ソフトウェア アーティファクトに署名するための事実上の方法となり、Java、Python、Node、Ruby などを含むすべての主要な言語エコシステムで採用されたことです。これは、史上最も早く導入されたオープンソース セキュリティ プロジェクトの 1 つとなり、開発者にソフトウェアの構成要素の起源と来歴を確立するための信頼性の「封印」を提供しました。
2021 年 5 月のホワイトハウス令によって導入されたソフトウェア部品表 (SBOM) の概念はまだ遠いように感じられます。開発者がソフトウェア パッケージの成分リストを共有するための共通言語というこの概念には、問題を複雑にするいくつかの新しい形式 (SPDX、CycloneDX) があります。
さらに悪いことに、SBOM が実際に開発者のワークフローにどのように適合するのか、そのプロセスで開発者がどのような具体的なメリットを得ることができるのかは不明です。
これらすべてを統合し、ソフトウェア署名、SBOM、開発者ワークフローに関する一貫した戦略を早急に策定し始めることがガバナンスであり、ソフトウェア セキュリティの整合性に対するより厳格な所有権が要求されます。
4月に遡ると、サイバーセキュリティ・インフラ庁（CISA）は、ソフトウェア会社のCEOに自社のソフトウェアが安全な環境で開発されていることを証明する責任を課す、安全なソフトウェア開発のための新しい認証フォームに関するコメント要請を出した。信頼できるソースコードのサプライチェーンを維持するために、誠意を持って合理的な努力が払われています。
これまでのところ、「合理的な」取り組みとは、FedRAMP のコンテナ脆弱性スキャン要件および米国国立標準技術研究所の安全なソフトウェア開発フレームワークで規定されているガイドラインのようです。しかし、新しい自己認証要件のより微妙で詳細な説明は、ソフトウェアに組み込まれたサードパーティのコードをカバーする条項にあります。
つまり、ソフトウェアプロバイダーは、自社のサプライチェーンで使用している人気のオープンソースソフトウェアが資金不足でメンテナンスされていないことに対して責任を負うことになります。
CISO によるこの目まぐるしい一連の考慮事項は、多くの Twitter ミームのネタになっています。
サプライチェーンツールチェーン
必要に応じて、オープンソースの野放しな採用を調査することは、少々衝撃的です。私は企業がオープンソースを使用すべきではないと言っているのではなく、むしろその逆です。フリー (およびオープンソース) ソフトウェアとしてパッケージ化されている場合も含め、フリー ランチなどというものは存在しません。メンテナーを稼働させ続けるには誰かが報酬を得る必要があり、誰かが開発者がこの新たに登場するオープンソース ソフトウェアをすべて理解するのを助ける必要があります。
チェーンガードはまさにその男かもしれない。
元 Google 社員が率いる会社 Chainguard が Sigstore プロジェクトを担当しています。これらすべてを開発者向けの一貫したツールチェーンにまとめようとします。
このスタートアップの初期の取り組みは、ビルド プロセスをロックダウンし、署名、来歴、SBOM などの機能をソフトウェア サプライ チェーンとソフトウェア ビルド プロセスにネイティブにすることに重点を置いていました。昨年、Wolfi と協力して、サプライ チェーンのセキュリティのプリミティブに特化して構築された初のコミュニティ Linux (非) ディストリビューションを立ち上げました。また、スタンドアロン バイナリ、nginx などのアプリケーション、Go や C コンパイラなどの開発ツールの基本イメージである Chainguard イメージも起動しました。
最近、Chainguard は Enforce プラットフォームにもう 1 つの大きなアップデートを行い、ビルド システムをロックダウンするために使用されるビルディング ブロックを、開発者とセキュリティ チームの間にあるツールチェーンに拡張しました。
開発者、セキュリティ専門家、さらには監査人も、どのパッケージが、どこに、誰によってデプロイされているかを知る必要があります。SBOM は、これらの質問やその他の質問に答えられるように設計されていますが、環境が複雑になればなるほど、達成するのは難しくなります。
通常、クラスターは数百のワークロードと数百のコンテナー イメージを実行し、それぞれに数百、場合によっては数千のパッケージが含まれます。SBOM はまだ初期段階にあり、ほとんどのソフトウェア パッケージには SBOM が付属しておらず、SBOM を生成する必要があります。
Chainguard は、問題の両端に対処することを目的としています。まず、同社は Sigstore のメンテナーとして、ソフトウェアの署名、構成証明、および証明書のマネージャーをすべての主要なプログラミング言語とレジストリに導入してきました。これにより、これらのオープンソース プロジェクトが SBOM を作成する方法に統一性と一貫性が生まれます。最近リリースされた Enforce では、プラットフォームは Syft を使用して SBOM を自動的に作成するため、開発者は追加の手順を行わずに各イメージの完全なパッケージ情報を表示できます。
新しい自己認証規制要件に関する最も深刻な課題は、コンテナ イメージが上流の更新よりも遅れていることが多いため、サプライ チェーンが既知の脆弱性を含むイメージを依然として実行していることです。さらに、現在、ほとんどの Common Vulnerabilities and Exposures (CVE) スキャナーは、パッケージ データベースを使用して、コンテナー内にインストールされているパッケージを確認しますが、スキャナーは、それらのシステムの外部にインストールされているソフトウェアを確認することはできません。
Chainguard は、開発者がまだ含まれていないパッケージの SBOM を簡単に取得または自動的に作成できるようにすることで、脆弱性検出のためのより忠実度の高いデータセットを提供します。さらに、Enforce の新しい脆弱性スキャンにより、チームは CVE を使用してアーティファクトを実行しているかどうか、またどこで実行しているかを知ることができます。
すべてがちょうどいいタイミングで起こりました。SBOM の使用方法を最初に理解したい開発者はいません。しかし、彼らには選択の余地がありません。FedRAMP と自己認証要件の組み合わせにより、ソフトウェア パッケージと自動プロセスを一貫して可視化し、脆弱性を発見して根絶することが緊急に求められています。
米国連邦政府に販売したい場合は、SBOM が間もなく必須になります。しかし、それは政府に物を売る人だけのためではありません。安全でないソフトウェアに対する法的責任を割り当てるための新しい自己認証モデルにより、SBOM がテクノロジー業界全体、または少なくとも将来の集団訴訟で名指しされたくないソフトウェア会社にとって共通のセキュリティ費用となる可能性があると考えるのが合理的です。 。