米国の 3 つの政府機関が協力して開発者に特定の慣行を採用するよう「強く奨励」する場合は、注意を払う必要があります。 CISA、NSA、ODNI は、サイバーハッカーの脅威を認識し、SolarWinds 攻撃を受けて、将来このような脆弱性を防ぐためにソフトウェア サプライ チェーンを保護するための推奨事項をまとめたものを共同で発行すると発表しました。 。この発表では、この文書の目的が開発者にベスト プラクティスの採用を奨励することであることが明らかになり、次のように述べられています。これらの原則には、セキュリティ要件の計画、セキュリティの観点からのソフトウェア アーキテクチャの設計、セキュリティ機能の追加、ソフトウェアと基盤となるインフラストラクチャのセキュリティの維持が含まれます。「
このガイダンスは 3 部構成のシリーズとして構成されており、ソフトウェア サプライ チェーンのライフサイクルに合わせてリリースされます。 シリーズのパート 1ソフトウェア開発者への推奨事項に焦点を当てた「」は、2022 年 2 月にリリースされました。残りの 3 つのパートは近い将来リリースされる予定です。パート XNUMX はソフトウェアのサプライヤーに焦点を当て、パート XNUMX はソフトウェアを受け取る顧客に焦点を当てます。最終的な目標は、このシリーズがこれら XNUMX つの主要な関係者間およびサイバーセキュリティ専門家間のコミュニケーションを促進し、回復力の向上を促進し、全体的な改善を促進するのに役立つことです。 ソフトウェアサプライチェーンのセキュリティ.
特定の組織内で誰が全体的な責任を負うかに関係なく、ソフトウェアのセキュリティを確保する責任が誰にあるのかは必ずしも明確ではありませんが、 新しいガイド これは、すべての開発者がこれらの新しいベスト プラクティスをよく理解する必要があり、ソフトウェア サプライ チェーンのセキュリティを確保する役割を担っていることを明確に示しています。または、もっと率直に言えば、次のようになります。 開発者の皆さん、あなたは組織のソフトウェア サプライ チェーンを保護する上で重要な役割を果たしています。 そのため、このガイドの最初の部分の (比較的) 短い要約を、あなたのために読んでおくと便利だと考えました。来たよ。
ガイドを一言で言うと:
この開発者向け実践ガイドで言及されている潜在的な脅威の広範なリストの中には、特定されている重要な脆弱性がいくつかあるため、必ず対処し、それらに備える必要があります。
- 適切に文書化されていない機能、または危険な機能を実装している機能
- セキュリティ評価時とコード配信時の間で、セキュリティの中核となる前提条件が目に見えて変化している
- サプライチェーンのステークホルダーに対する企業の変化
- 標準以下のコーディングまたはセキュリティ慣行
経営陣、財務マネージャー、およびプログラム マネージャーはすべて、ソフトウェア サプライ チェーンのセキュリティに対処する責任がありますが、ソフトウェア サプライ チェーンの完全性は重要です。 ソフトウェアサプライチェーンのセキュリティ 多くの場合、ソフトウェア開発者の警戒心とサプライチェーンのすべての利害関係者の認識に依存します。ガイドのパート 1 では、開発者の役割と開発プロセスの各段階に固有の脅威に焦点を当て、標準的な実践となるべき緩和戦略の推奨事項を提供します。
ステージ #1: 安全な製品基準と管理
安全な開発は、製品チームと開発チームの主要な関係者全員がソフトウェア サプライ チェーンのセキュリティの重要性を認識することから始まります。脅威のシナリオは一般的であり、誰にとっても明らかかもしれません。課題は、決定された緩和政策に関して全員が同じ認識を持つようにすることです。これらのポリシーは、設計とアーキテクチャ、脅威のモデリング、コーディング、セキュリティ テスト計画、リリース基準、将来の脆弱性の管理方法など、プロセス全体をカバーする必要があります。この一環として、チームの能力を評価し、チームがそれぞれのタスクに対して適切なトレーニングを受けているかどうかを確認し、文書化の実践と定期的なセキュリティのレビューと脅威の評価を定義することも含まれます。
ステージ #2: 安全なコード開発
コード開発に関しては、安全なコーディングのための正しい実践方法がすでに規定されています。 SSDF。これが、プログラミング言語が事前に決定されていない限り、セキュリティの考慮もその決定の一部に含める必要がある理由です。ガイド 役立つガイダンスを提供する 開発者向けに、「内部関係者」（開発者など）による有害なソース コードの挿入、オープンソース ソフトウェア、およびそれに対処するためのベスト プラクティスなど、幅広いシナリオに対処します。コーディングのための安全な環境 (安全なビルド構成やサードパーティ ソフトウェア ツールを含む) を作成し、その後統合製品のセキュリティをテストする方法。脆弱性は納品後にも発生する可能性が高いため、報告された脆弱性に対処し、将来の外部ソフトウェア拡張機能によって製品のセキュリティの完全性が損なわれないようにするための推奨事項もあります。
ステージ #3: ビルド環境を強化する
コードが安全に開発された後は、ソフトウェア サプライ チェーンのセキュリティを確保するために、ビルド環境をソフトウェア自体と同じ基準に強化する必要があります。ビルド システムを侵害することは、コードに侵入するための魅力的な方法です。これは、開発プロセスの段階で開発者による当然の精査が少ないためです。
ステージ #4: コードの配信
このガイドで取り上げられる最後の弱点は、ソフトウェア サプライ チェーンの最終段階、つまりコード配信をカバーしています。ここまでコードが適切に保護されていたとしても、軽減する必要がある主要なサプライ チェーンの脆弱性がまだ 2 つあります。 1 つ目は最終的なパッケージの検証です。これは、たとえば、メタデータ、開発者の資格情報、またはオープンソース インベントリを誤って公開することによって悪用される可能性があります。脆弱性がよく調査されるもう 1 つのステップは、配信システムです。配信システムは、配信の 1 つまたは複数の段階を乗っ取る中間者攻撃によって侵害される可能性があります。
これらのリスク軽減策をソフトウェア開発レベルで適用することで、ソフトウェア ベンダーは、アップデートの侵入、コード署名の操作、オープンソース コードに隠された「サプライズ」などにつながる可能性のある弱点を回避できます。
フリーランチなど存在しない: サードパーティ ソフトウェアの隠れたコスト
かぎ 開発者の速度に貢献 サードパーティのソフトウェアを効果的に組み込むことができるようになりました。これにより、開発者は、拡張性やインターフェイスのために既製のコンポーネントを使用しながら、たとえばイノベーションや機能に集中することが可能になりました。このサードパーティ ソフトウェアの使用の増加により、ソフトウェア サプライ チェーンのセキュリティに大きな課題が生じています。このガイドでは、自分のコードの評価に使用したのと同じ基準に従ってそのようなコードの評価を実施することに加えて、バイナリをスキャンして脆弱性がないか確認し、その結果生じるリスクを評価することを推奨しています。この評価の結果は、特定のソフトウェア コンポーネントを使用するかどうかの決定に考慮される必要があります。ソフトウェア コンポーネントの選択では、そのソースも考慮する必要があります。サードパーティのコンポーネントをソース コードに組み込むことは長い関係の始まりであり、信頼できるパートナーと協力するよう努める必要があります。コードの所有権、コーディングの実践、バージョン管理ポリシーは、信頼できるソースを選択する際に考慮すべき点のほんの一部です。新しい脅威が発見されたときの各コンポーネントの今後のすべてのアップデート、リリース、メンテナンス作業について考えてみましょう。課題は、場合によっては厳しい時間的プレッシャーの下で、サードパーティによるすべての変更を監視し、脆弱性を評価し、それに応じて対応することです。
SBOM でソフトウェア サプライ チェーンのセキュリティを強化する
ソフトウェア サプライ チェーンの長期的な整合性を確保するための重要な実践方法の 1 つは、最新の状態を維持することです。 ソフトウェア部品表 (SBOM)。 SBOM は、特定のソリューションを構成するソフトウェア コンポーネントの詳細なインベントリです。
これにより、時間と労力が節約され、最も重要なことに、継続的な脅威にさらされる機会が減ります。製品に組み込まれる各ソフトウェア コンポーネントには独自の SBOM が付属しており、これを検証して製品の単一の「マスター」 SBOM にマージする必要があります。 SBOM に付属していないコンポーネントを組み込む場合は、ソフトウェア構成分析 (SCA) ツールを使用して独自の分析を行う必要があります。
SBOM が正確で記述的であればあるほど、保守と参照が容易になります。ソフトウェア コンポーネントが目まぐるしい速度で更新されることを考えると、 適切に構造化されたSBOM すべてのアップデート、パッチ、リリースを追跡して記録する時期が来たときに、成果が得られます。さらに重要なことは、セキュリティ上の脅威が発見されたら、一瞬一瞬が重要であるということです。 ご注意ください： ソフトウェアサプライチェーンのセキュリティ 常にあなたの最も弱い部分と同じくらい強いでしょう。数十のソフトウェア コンポーネントが危険にさらされている場合、すべての答えを備えた SBOM に感謝するでしょう。
効率的なワークフローのために、有用な SBOM には少なくとも次の 3 つのコンポーネントが含まれている必要があります。
- データフィールド – これらは、実装したコンポーネントの記述子です。開発が完了してからかなり時間が経っても、どのコンポーネントが使用されているかを簡単に特定できるため、コンポーネントの脆弱性を効果的に監視できます。
- 自動化サポート – SBOM を自動監視するには、受け入れられた機械可読形式のいずれかでも識別される必要があります。
- 実践と約束 – SBOM を管理するには、バージョンの頻度、依存関係、既知の未知の要素、配布と配信、アクセス制御、間違いへの対応方法などのメンテナンスの実践について共通の理解を必要とします。
特定の製品の利害関係者 (ソフトウェア開発者、ソフトウェア サプライヤー、顧客) 間で SBOM を共有すると、透明性と調整が促進され、ソフトウェア サプライ チェーンがセキュリティの脅威から製品を防御する能力が向上します。ソフトウェア サプライ チェーンにはすべての可動部分があるため、このような SBOM (簡単に参照、監視、維持できるもの) を一貫して維持することは複雑な課題であることに注意する必要があります。
最後の言葉: ソフトウェア サプライ チェーンのセキュリティを次のレベルに引き上げるにはどうすればよいでしょうか?
ソフトウェア サプライ チェーンのセキュリティがますます重要になるにつれ、組織は、配布または使用するソフトウェアに対する透明性のある信頼を構築するという課題に繰り返し直面しています。 ベスト プラクティスとして SBOM の採用は今後も拡大すると予想されるため、この課題を克服できるツールを用意することは、ソフトウェア サプライ チェーンのセキュリティを確立するための重要なステップとなります。これが、当社が最近、ソフトウェア製品向けの初の証拠に基づくセキュリティ ハブを立ち上げた理由です。 ユーザーがチームや組織全体でソフトウェアに対する信頼を築けるようにします。 このユーザーフレンドリーなプラットフォームは、SBOM をアクセスしやすく、使いやすくし、そして最も重要なことに、開発チームがソフトウェア サプライ チェーンのリスクを軽減するのに役立ちます。ソフトウェア製品のセキュリティを顧客、購入者、セキュリティ チームに対して透過的にする.
ソフトウェア開発者として、ソフトウェア サプライ チェーンのセキュリティに対する脅威を懸念している場合は、次のことをお勧めします。 プラットフォームを試してみる;無料で使用でき、制約はありません。当社のワークフローを実装することで、サプライ チェーン全体で SBOM を共有できるようになります。
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 詳しくはこちら。
関連記事
