ソフトウェアサプライチェーンセキュリティの強化：サミットからの洞察

近年、ソフトウェアシステムを狙ったサイバー攻撃が増えてきてるね。特に、あまりセキュリティが強くないシステムが標的になってる。これらの攻撃は、企業や団体にとって大きな損害を引き起こす可能性があるよ。ソーラーウィンズやlog4jの事件がその代表例で、何千人もの顧客に影響を与えたんだ。アメリカ政府と業界のリーダーたちは、今、ソフトウェアのサプライチェーンのセキュリティを強化することに集中してる。この文章では、最近のサミットで専門家たちがソフトウェアのサプライチェーンセキュリティのさまざまな側面について話し合ったことをまとめてる。

#サミットの概要

2022年9月30日に、17社の19名の業界の実務者が集まるサミットが開催された。このサミットの目的は、ソフトウェアのサプライチェーンセキュリティに関する経験を共有し、課題を特定することだった。ディスカッションはオープンコミュニケーションを促進するために小グループで行われた。参加者には大企業、中小企業、ソフトウェア財団の代表が含まれてたよ。

#サミットの形式

サミットは1つの基調講演と6つのパネルディスカッションで構成されてた。イベントの前に、参加者はディスカッションのトピックを選ぶためのアンケートに答えた。各パネルは45分間で、最初に四人のスピーカーが短い発言をする形だった。残りの時間はグループでそのトピックについて話し合ったりした。ディスカッション中にはメモが取られて、後でこの記事にまとめられたんだ。

#大統領令

ひとつの重要な話題は、大統領令14028で、2021年5月12日に出された。この命令は、アメリカ政府に重要なソフトウェアを供給する組織に対して、自分たちのソフトウェアとそのサプライチェーンのセキュリティを強化することを求めている。多くの組織はこれらの要件に従うために内部のプロセスを変える必要があるね。

サミット参加者の中には、この命令を形作ったり要件を明確にするために政府機関と以前に会った人もいた。命令に合ったプラクティスをすでに実践している企業もあるけど、リソースが足りない小さな会社は特にコンプライアンスについて心配してた。開発者が作業習慣やプロセスを調整する必要があるかもしれないという話も出たよ。

#オープンな疑問

このパネルで提起された重要な疑問は、命令に従わなかった場合の影響について。参加者たちは、命令に従わなかった組織に対して法的な問題が生じるかどうかを気にしてた。

#ソフトウェア部品表 (SBOM)

次に重要な話題は、ソフトウェア部品表 (SBOM)だった。SBOMは基本的に、ソフトウェア製品を構成するコンポーネントのリストだね。これを使うことで、組織はサードパーティの要素を追跡し、脆弱性を管理できる。大統領令によれば、連邦政府にソフトウェアを販売する企業は完全なSBOMを提供しなきゃいけない。

#生産者と消費者へのメリット

SBOMがソフトウェアの生産者と消費者にとってどんな利点があるかについて話し合われた。生産者は製品に関する明確な情報を提供することで顧客との信頼を築けるし、消費者は脆弱性に関連するリスクについての洞察が得られるんだ。

参加者たちはSBOMを扱うための強力なツールが必要だと強調してた。SBOMを作成することは進化してきたけど、効果的に活用するのはまだ課題がある。何人かの参加者は、初代のSBOMの信頼性について疑問を示し、定期的なチェックの必要性も指摘してた。

#オープンな疑問

パッケージマネージャーがSBOMを生成するためにアップデートすべきか、政府が受け取ったSBOMをどのように利用する計画かといった未解決の問題もあったよ。

#脆弱な依存関係

ソフトウェアはしばしば、機能を強化するためにサードパーティのコンポーネント、つまり依存関係に頼ることがある。しかし、これらの依存関係は複雑さや潜在的な脆弱性を引き起こすことがある。依存関係でセキュリティの問題が起こった時は、最新のバージョンにすぐにアップデートすることが重要だね。

#プロセスと課題

サミット参加者は、依存関係の脆弱性を特定し対応するさまざまな方法について話し合った。脆弱性をスキャンするツールがあるけど、その量が膨大で圧倒されることもある。脆弱性が特定されると、実務者たちは更新に追いつくのが大変で、新しい問題が頻繁に発生するんだ。

自動的に依存関係をパッチするツールもあるけど、多くの組織はこのアプローチが実用的ではないと感じてる。開発者は手動でこれらの更新を確認する必要があり、それが遅延につながることも多い。どのバージョンを使うべきかを判断するのが難しいという混乱もよくあるね。

#オープンな疑問

参加者たちは、依存関係の更新を管理するためのベストプラクティス、更新に対する異なるレベルのレビューを適用すべきか、依存関係を管理する責任を誰に割り当てるべきかといった疑問を考えてた。

#悪意のあるコミットを検出する

悪意のある行為者は、許可されていないコミットを通じてソフトウェアプロジェクトに有害な変更を注入することができる。これらの悪意のある変更を見つけるのは難しい、攻撃者はしばしば行動を隠そうとするからね。

#検出のための戦略

参加者たちは、コミッターの活動を調べて疑わしい行動を特定する方法について話し合った。大きな変更や異常な変更のパターンが潜在的な問題を示すかもしれない。機械学習を活用して悪意のある行動を検出するツールを作る手助けができるかもしれないけど、この種の活動を分析するのは難しい。

何人かの実務者は、無邪気なミスと故意に有害なコードを区別することの難しさを指摘してた。新しいセキュリティフレームワークが導入されていて、ソフトウェア開発プロセスの各段階でより厳密な確認が求められてるんだ。

#オープンな疑問

重要な疑問として、特に緊急時に開発者の効率を確保しつつ、セキュリティ対策をどう両立させるかということが挙げられた。

#安全なビルドとデプロイプロセス

安全なビルドとデプロイのプラクティスは、ソフトウェアが安全に開発・ローンチされるために重要だ。これには、安全な環境を作成し、正確に変更を追跡することが含まれる。

#現在のプラクティス

ほとんどの参加者はデプロイプロセスには自信を持っているけど、ビルドについては懸念を示してた。多くの人がロギングやモニタリングツールを使って活動を追跡し、透明性を確保しようとしてる。いくつかの組織は、さらなるセキュリティを確保するために第三者の監査人と協力してるんだ。

サミットではセキュリティを維持するためにアクセス権をより良く分離する必要があることが強調された。SLSAのような様々なフレームワークについての認識はあるけど、参加者たちはまだ実装には時間が必要だと言ってた。

#再現性のあるビルド

再現性のあるビルドは、ソフトウェアが一貫してビルドできて、最終製品が毎回同じになることを保証する。これにより、ビルドに改ざんがないかを確認できるんだ。

#実装の課題

多くの実務者は再現性のあるビルドのアイデアを支持してるけど、それを実現するには障害もあると指摘してた。プログラミング言語によっては、データのランダム性のためにこのプロセスが複雑になる場合もあるし、ソフトウェアを何度もビルドすることによる環境への影響も懸念されてる。

#オープンな疑問

再現性のあるビルドの代替案や、改ざんを特定するためにどのように使えるかについて質問が残ってる。

#標準とガイドライン

ソフトウェアのサプライチェーンセキュリティを改善するためのさまざまな標準やフレームワークが存在する。一つの主要なフレームワークはSLSAで、改ざんを防ぎ、ソフトウェアの整合性を向上させるためのコントロールチェックリストを提供してる。

#標準の採用

サミットのほとんどの参加者はSLSAフレームワークに対するコンプライアンスを高める方向に進んでる。ただ、特定の側面についてはより明確なガイダンスや標準の実装支援が必要だとも指摘してた。

特に小さな組織にとって、これらの標準に準拠していることを証明することができるかどうかについて懸念が示されてた。参加者の中には、政府が適切な基準を設定する能力に疑問を持つ声もあったよ。

#結論

このサミットは、ソフトウェアのサプライチェーンセキュリティの現状について貴重な洞察を提供した。参加者たちは、大統領令へのコンプライアンス、依存関係の管理の課題、SBOMを巡る問題についての懸念を表明してた。また、悪意のある行為を検出し、安全なビルドとデプロイを確保するための強力なセキュリティプラクティスの重要性についても共通の認識があった。ディスカッションは、ソフトウェアセキュリティの分野での継続的なコラボレーションと、より良いツールやフレームワークの開発の必要性を強調してたんだ。