TL; DR
近年、テクノロジー業界はソフトウェア開発における「シフトレフト」の概念を熱心に支持し、セキュリティ慣行を開発ライフサイクルに早期に統合することを提唱しています。この動きは、プロジェクトの開始時からコードのセキュリティを確保する責任を開発者に与えることを目的としています。ただし、このアプローチの背後にある意図は崇高なものですが、現実はより微妙な状況を描いています。つまり、開発者のみに依存して維持するという単純な概念が存在するということです。 ソフトウェアサプライチェーンのセキュリティ 不十分であることが証明されます。この記事では、補完的なバランシング アプローチ、つまり CISO 主導の SDLC ガードレール、つまり SDLC のセキュリティ ポリシーを管理または強制する自動制御手段について説明します。
私のチーズをシフトチェンジしたのは誰ですか?
シフトレフトのパラダイムは本質的に、開発の初期段階でセキュリティ上の懸念に対処することを目的としており、開発者がコード内にセキュリティ対策を積極的に組み込むことを期待しています。これは、開発者がコードを作成して展開するときに脆弱性を特定し、セキュリティ制御を実装するという使命を負うという魅力的なイデオロギーです。
ただし、この理想主義的なアプローチは、実際の実装では重大な課題に直面します。開発者はコーディングには熟練していても、セキュリティ技術やベスト プラクティスに関する包括的な専門知識が不足している場合があります。彼らの主な焦点は機能要件を満たすことにあり、進化し続けるサイバーセキュリティの状況を徹底的に理解していることを期待するのは非現実的です。
さらに、時間の制約やプロジェクトのプレッシャーにより、セキュリティと期限の遵守との間にトレードオフが生じることがよくあります。開発者は機能を迅速に提供することを急ぐあまり、潜在的なセキュリティの抜け穴をうっかり見落としたり、安全性の低いコーディング手法を採用したりして、後の段階まで脆弱性が解決されないままになる可能性があります。結局のところ、彼らの KPI はスピード指向であり、大多数にとってセキュリティは常に 2 番目です。
CI/CD ガードレールの導入
ここで、継続的インテグレーション/継続的デプロイメント (CI/CD) パイプラインにセキュリティの「ガードレール」を実装する必要性が明らかになります。ガードレールは、開発パイプライン内に組み込まれた自動チェックポイントとして機能し、セキュリティ対策が手動介入や個々の開発者の専門知識やモチベーションだけに依存しないようにします。
ガードレールはプロアクティブなゲートキーパーとして機能し、ソフトウェア開発ライフサイクル (SDLC) 全体を通じてセキュリティ標準、ポリシー、ルールを常に監視して適用します。これらの自動チェックは、不良パッケージのブロックリスト化、重大な脆弱性を含むコードの停止、静的コード分析テストの不合格、または問題のある依存関係のあるコードの停止、コンプライアンス標準または安全な SDLC ポリシー (例: コードなど) の遵守など、さまざまなセキュリティ側面を網羅できます。コミットごとにレビューします)。
コードとしてのポリシーの概念を使用すると、ガードレールとして実装されると考えられるほぼすべてのルールを作成できます。以下に、以下に沿ったガードレール ルールの例をいくつか示します。 NIST 800-204D:
ガードレール ルールの例:
- 開発者ワークステーション
- 開発者ワークステーションのエンドポイント セキュリティ スイートを確認する
- SCMの
- ブランチ保護ルールの検証: 複数の特定のレビューを強制する
- CI ファイルが許可された担当者のみによって変更されていることを確認する
- シークレット スキャンが実施されており、シークレットが検出されないことを確認します。
- CI
- コードスキャンが有効になっていることを確認します。
- コード スキャンの結果が事前定義されたバーの下にあることを確認します
- 依存関係
- オープンソースのライセンスを確認します。
- オープンソースの脆弱性が組織のポリシーに準拠していることを確認する
- アーティファクト
- 正しい ID がアーティファクトに署名していることを確認します。
- 最終的なアーティファクトの脆弱性を確認します。
手すりではなくガードレール
ガードレールを CI/CD パイプラインに統合することにより、組織は体系的にセキュリティ プロトコルを適用でき、包括的なセキュリティ対策の確保を開発者だけに依存することなく、安全な製品を実現できます。開発者が開発ペースを理由にセキュリティ対策を回避する可能性があることを考慮すると、ガードレール アプローチでは、これらの決定を不可能にするか、少なくとも可視化して、単一ビルド レベル (例: アーティファクトの信頼性の決定など) で考慮できるようにします。 ）および組織レベル（組織の開発者に何が期待でき、何が期待できないかを理解する）。 自動ツールは、新しいバージョンが運用環境にリリースされる前、またはクライアントに配信される前に、潜在的な脆弱性やコンプライアンス違反の問題にフラグを立てたり、ブロックしたりすることができます。結局のところ、セキュリティ問題に対処するのは、納品後ではなく、開発段階の方がはるかに簡単、迅速、かつ安価です。
左へのシフトは開発者のセキュリティ実践への関与を奨励しますが、他の利害関係者 (セキュリティ専門家、DevOps エンジニア、品質保証チーム) の役割を免除するべきではないことを認識することが不可欠です。あなたが製品セキュリティ、AppSec、DevSecOps、または CISO であれば、開発者に対する責任を「左にシフト」しても、責任が肩から降ろされるわけではないことをすでにご存知でしょう。ほとんどの CISO とそのチームは研究開発部門の出身ではないため、ソフトウェア開発環境は歴史的に彼らの視野の外にありました。彼らは従来、運用セキュリティ、ネットワーク セキュリティ、組織間の接続に重点を置いていました。ガードレール アプローチは、CISO を開発環境の荒野に「慎重に」導き、CISO の責任の範囲を再び制御する方法です。. 「丁寧に」というのは「協力的に」という意味です。製品のセキュリティはセキュリティ チームと開発チームの共同作業であるため、開発速度を妨げることなく潜在的なセキュリティ脅威に対して CI/CD パイプラインを強化する堅牢なガードレールを設計および実装するには、これらのエンティティ間の協力が不可欠です。
CI/CD パイプラインにおけるガードレールの確立とシフトレフトの原則の統合は、良いバランスです。開発者は引き続き安全なコードを作成し、基本的なセキュリティ原則を理解する責任を負いますが、セキュリティ チームは製品がリリースするために満たす必要がある基準を決定します。その後、ガードレールはそれに応じてツールとプロセスに自動化され、セーフティ ネットとして機能し、セキュリティ基準と SDLC ポリシーを継続的に監視および強化します。ガードレールは、設計およびデフォルトで安全な製品を実現するための重要なステップです。
結論として、シフトレフトの概念は善意ではありますが、開発者の関与だけでは包括的なソフトウェア セキュリティを確保するには不十分です。最終的なソフトウェア成果物の整合性と信頼性を強化するには、組織は CI/CD パイプライン内にガードレールの実装を採用する必要があります。この組み合わせたアプローチは、ソフトウェアのセキュリティ体制を強化するだけでなく、開発者、セキュリティ専門家、自動化ツールが安全なソフトウェアを作成するという共通の目標に向かって相乗的に取り組む共同環境を促進します。
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 詳しくはこちら。
関連記事
