Jan 01, 1970
11,212 測定値
DevOps パイプラインを DevSecOps パイプラインに変える方法: シフトレフトの概念の概要
長すぎる; 読むには
シフト レフトの概念とは何か、またそれがバグ修正のコストと開発時間の削減にどのように役立つかについて説明しました。開発プロセスの早い段階でセキュリティ チェックを開始するほど効果的です。 次に、DevSecOps パイプライン構造を分解し、パイプラインの各段階でどのようなセキュリティ チェックが実行されるかを調べました。こんにちは、ハッカーヌーン！私の名前はソフィアです。DevOps/クラウド エンジニアです。 HackerNoonとAptibleによるコンテストに参加することにしました。
この記事では、DevSecOps パイプラインの機能と Shift Left の概念について説明します。 DevSecOps パイプラインの主要な段階、ソフトウェア開発における自動セキュリティ チェック、および無料のオープンソース ツールについて学びます。また、脆弱性を早期に検出し、アプリケーションのセキュリティを向上させるのに役立つヒントも見つかります。
この記事は、DevSecOps パイプラインの成熟度を評価し、開発のロードマップを作成し、各タスクに適切なツールを選択し、DevSecOps の哲学に従ってプロジェクトを管理する方法をより深く理解するのに役立ちます。
シフトレフトのコンセプト
DevSecOps 方法論の主な目的は、自動化されたセキュリティ チェックを DevOps パイプライン、つまりソフトウェア開発プロセス自体に導入することです。
少し前までは、情報セキュリティの専門家が開発プロセスの完了後にテストを実施していました。このアプローチは非効率的です。セキュリティ テスト中にエラーが発見された場合、開発サイクル全体をやり直す必要があります。これには時間がかかり、費用もかかります。
下の画像を見てください。エラー修正のコストがステップごとに増加することがわかります。
開発および機能テスト中に発見されたセキュリティ問題を修正するのにほとんど費用はかかりません。必要な変更はすべてソース コードにすぐに加え、再チェックのために送信できます。
アーティファクトの構築段階で問題を修正するには、少なくとも 2 倍の費用がかかります。 Dockerfile を編集するなど、ビルド プロセスを変更する必要があります。つまり、DevOps エンジニアの助けが必要になります。
統合テスト中にエラーが検出された場合、修正には 10 倍の費用がかかります。この場合、開発サイクルを再開し、開発者、DevOps エンジニア、テスターを巻き込む必要があります。
導入段階でセキュリティ上の問題が検出されると、ユーザーデータの漏洩につながる可能性があります。同社は数百万ドルの罰金や評判の低下を受け取る可能性があり、ミスの代償は何百倍にも増加することを意味します。
したがって、主な結論は、安全性チェックをできるだけ早く実行する必要があるということです。視覚化した場合は、パイプラインの左側に移動します。これは、セキュリティ専門家が好んで語るシフトレフトの概念です。
DevSecOps パイプラインの構造
DevSecOps パイプラインは、運用環境でアプリケーションを構築、テスト、配信し、あらゆる段階でセキュリティを確保する自動化されたプロセスとツールのチェーンです。
上の画像は、セキュリティ チェックのすべての主要フェーズを含む DevSecOps パイプライン構造を示しています。それぞれについて少し説明します。
- 事前コミット。これは、開発者がコードをバージョン管理システムにコミットする前に、ソース コードのセキュリティをチェックすることを意味します。このチェックにより、パスワードや API キーなどの暗号化されていない機密情報を検出できます。
- 事前構築。これは、ソース コードがバージョン管理システムに入った後にそのセキュリティをチェックすることを意味します。このツールは、ソース コードとその依存関係の静的分析を実行して、次のような一般的な脆弱性を検出します。
OWASP トップ 10 リスト。
- ビルド後。これは、Docker ファイル、RPM パッケージ、JAR アーカイブなどのソース コードから構築されたアーティファクトのセキュリティ チェックです。このツールはアプリケーション環境と依存関係を分析し、新しいバージョンのパッチがすでに適用されているパッケージとライブラリの古いバージョンを見つけます。
- テストの時間。これは、収集されたアーティファクトから実行されるアプリケーションのセキュリティをテストすることを意味します。このフェーズのツールは、攻撃者のアクションをシミュレートすることでアプリケーションを「破壊」しようとします。
- 導入後。これは、実稼働環境にアプリケーションをデプロイした後にアプリケーションのセキュリティをチェックすることを意味します。このツールは、既知の脆弱性のオープン レジストリをリアルタイムで監視し、アプリケーションに対する脅威が検出された場合に通知します。
次に、これらのチェックとは何なのか、またチェックを実行するためにどのようなツールが使用されるのかを詳しく見てみましょう。
コミット前のチェック
コミット前チェックを使用すると、リポジトリのローカル コピーに変更をコミットする前に、開発者のマシン上のソース コードを分析できます。いずれかのステートメントがエラーを返した場合、コミットは実行されません。この場合、開発者は間違いを修正して再度コミットする必要があります。
このチェックにより、チェックされていないコード (たとえば、暗号化されていないシークレットを含む) がリポジトリに侵入する状況が回避されます。
コミット前のソース コード チェックを実行するには、開発者のローカル マシンにツールをインストールする必要があります。このアプローチには利点だけでなく欠点もあります。たとえば、環境の違い: 機器のバージョンの違い、さまざまなオペレーティング システム、さらにはプロセッサ アーキテクチャなどです。
開発者が異なるバージョンのプリコミット ツールを使用すると、チェックの結果が異なるため、共同作業が困難になる可能性があります。チーム内または会社全体でコミット前チェックを実装する場合は、これを考慮してください。
コミット前チェック用のツール
多くのオープンソース ツールを使用して、コミット前チェックを設定できます。
これらはコミット前のチェックに最適なツールです。
ビルド前のチェック
ビルド前のフェーズでは、ホワイト ボックス テストが実行されます。これらのチェックは、前のステップと同様に、ソース コードを分析するために使用されます。この場合、アプリケーションはそのアーキテクチャと内部構造を知っており理解しているため、「ホワイト ボックス」です。
ビルド前チェックにはいくつかの種類があります。
- 秘密の検出
- 静的アプリケーション セキュリティ テスト (SAST)
- ソフトウェア構成分析 (SCA)
それでは、それらについて詳しく説明していきます。
ビルド前の秘密検出チェック
シークレット検出は、暗号化されていない機密情報、つまりバージョン管理システムに入力されたソース コード内の暗号化されていないシークレットを検出する自動チェックです。
ビルド前チェックは、ソース コードがバージョン管理システムのリポジトリに入った後に実行されます。したがって、リポジトリの内容が漏洩した場合など、ストレージ内の暗号化されていない機密データはすべて攻撃者によってアクセスされる可能性があります。
さらに、秘密検出チェックを実装するプロセスは、最初から発生するのではなく、進化するプロジェクトで発生する可能性があります。この場合、暗号化されていないシークレットが古いコミットや別のリポジトリ ブランチで見つかる可能性があります。
これらの問題を解決するには、さまざまなことを行う必要があります。たとえば、暗号化されていないシークレットのリポジトリをクリーンアップしたり、 Hashicorp Vaultなどのさまざまなシークレット管理ツールを実装したりする必要があります。
秘密検出のためのツール
シークレット検出は次を使用して構成できます。
ビルド前の SAST チェック
静的アプリケーション セキュリティ テスト (SAST) は、アナライザーが構文の正しさをチェックするだけでなく、独自のメトリクスを利用してコードの品質も測定するテストです。 SAST スキャナの主なタスクはセキュリティ テストです。
特に、SAST アナライザーには、一般的な脆弱性のソース コードが含まれています。
SAST 分析は、アナライザーがアプリケーションの内部構造にアクセスできるため、ホワイト ボックス テストと呼ばれます。アナライザーはソース コードを実行せずにチェックするため、誤検知が生成され、一部の脆弱性を検出できない可能性があることに注意することが重要です。
このため、SAST 分析のみに限定すべきではありません。問題に包括的にアプローチし、SCA、DAST、IAST、OAST などのさまざまな種類の分析を使用することをお勧めします。
SAST ツール
独自のソリューション:
無料のソリューションは GitLab SAST です。
ビルド前のソース SCA チェック
ソフトウェア構成分析 (SCA) は、オープンソース コンポーネントを分析することでアプリケーションを保護する手法です。
SCA スキャナーは、既知の脆弱性やエクスプロイトを含む古い依存関係を探します。さらに、一部の SCA ツールは、コンポーネントのライセンス互換性とライセンス侵害のリスクを判断できます。
ソース SCA はソース コードを分析し、より具体的にはソース コード内で定義されたアプリケーションの依存関係を分析します。この分析は、依存関係スキャンと呼ばれることがよくあります。
SCA を使用すると、1 つのコンポーネントの脆弱性がすべてのアプリケーションのセキュリティ上の問題につながる可能性がある問題を検出できます。
良い例は次のとおりです
SCAツール
無料料金プランを備えた商用ソリューション:
GitLab (Ultimate バージョンでのみ利用可能) の一部として、以下を使用できます。
ビルド後のチェック: バイナリ SCA
ビルド後のフェーズは、CI パイプラインのソース コード (Docker イメージ、RPM パッケージ、または JAR アーカイブ) からアーティファクトがビルドされた後に行われます。ビルド後のチェックを使用すると、これらのバイナリ アーティファクトの依存関係を分析できます。
バイナリ SCA 分析には、Docker イメージ、RPM パッケージ、JAR/WAR/EAR アーカイブなどのバイナリ アーティファクトの検査が含まれます。これは、コンテナ スキャンとも呼ばれます。バイナリ成果物がビルドされるとき、つまりビルド後の段階の前ではなく、これを実行するのが合理的です。
Docker イメージを使用する場合、いくつかの興味深い機能があります。バイナリ SCA アナライザーは、Docker イメージのレイヤーをチェックし、それらをパブリック脆弱性データベースのハッシュ サムとして検索します。
一部のアナライザーは、脆弱なコンポーネントを見つけるだけでなく、たとえば、既に修正された脆弱性を持つコンポーネントの最小必要バージョンを指定することによって、修正を提案することもできます。
一般的なバイナリ SCA アナライザの例
無料の解決策は、
オープンソース ソリューション:
アナライザーが組み込まれた Docker レジストリ -
テスト時チェック: DAST、IAST、および OAST
この段階では、動的なグレー ボックス テストとブラック ボックス テストが実行されます。アプリケーションの内部構造が部分的または全体的に不明な場合、これらのセキュリティ チェックは、脆弱性を発見し、それを悪用してアプリケーションを「破壊」しようとする攻撃者の動作をエミュレートすることによって実行されます。 DAST、IAST、OAST のそれぞれについて簡単に説明します。
テスト時 DAST チェック
DAST スキャナは、さまざまな脆弱性による外部攻撃をシミュレートすることにより、アプリケーションを自動的にテストします。アプリケーションはアナライザーにとってはブラック ボックスです。それについては何も知られていない。
DAST チェックの場合、スキャナーで使用できるアプリケーションの実行インスタンスが必要です。さらに、アプリケーションのテスト インスタンスのパラメーターが運用環境のインストールに近づくほど、誤検知が少なくなります。
たとえば、HTTP プロトコル経由でのみアクセスできるテスト アプリケーション インスタンスをデプロイしたが、運用環境では、アプリケーションは HTTP プロトコル経由でのみアクセスできるとします。
その場合、DAST スキャナーは、クライアント (アナライザー) とサーバー (アプリケーション インスタンス) 間のトラフィック暗号化の欠如に関連するいくつかのエラーを生成します。
DAST ツールの例
注目に値するツール:
GitLab DAST — アルティメット バージョンでのみ利用可能OWASP Zed 攻撃プロキシ (ZAP) — GitLab DAST でも使用されるオープンソース ソリューション- アキュネティックス
- WebInspect の強化
- HCL セキュリティ AppScan
- シノプシスが管理する DAST
Tenable.io (Web アプリのスキャン)- Veracode の動的分析
素晴らしいです、次に進みましょう。
テスト時 IAST チェック
IAST (Interactive Application Security Testing) は、ホワイト ボックス テスト SAST とブラック ボックス テスト DAST の利点と強みを組み合わせたグレー ボックス テストです。
SAST メソッドと DAST メソッドのすべての利点を収集し、欠点を解消するために、開発者は、これらのメソッドを組み合わせたハイブリッド メカニズムである IAST を発明しました。コード分析を通じてアプリケーションの動作に関するより多くの情報が得られるため、動的テストの精度が向上します。
IAST にはその利点以外にも制限があることを覚えておく価値があります。最も基本的なものは、テスト対象のアプリケーションが記述されている言語に依存することです。 IAST ソリューションはアプリケーション レベルで動作し、その動作を分析するには実行可能コードにアクセスする必要があります。
これは、IAST ソリューションがアプリケーションが記述されているプログラミング言語を理解できなければならないことを意味します。特定の IAST ソリューションのサポートは、一部の言語では他の言語よりも適切に実装される場合があることに注意してください。
IASTの解析にも時間がかかります。それは、アプリケーションのサイズと複雑さ、外部依存関係の数、使用される IAST ツールのパフォーマンスなど、多くの要因によって決まります。
さらに、分析プロセスではコード自体はスキャンされず、直接実行されるフラグメントのみがチェックされます。したがって、できるだけ多くのアプリケーション シナリオをテストできる場合、IAST 分析を機能テストと組み合わせるのが最適です。
IASTツールの例
ここにあなたのための素晴らしいツールがあります:
素晴らしいです、次に進みましょう。
テスト時の OAST チェック
OAST (アウトオブバンド アプリケーション セキュリティ テスト) は、によって開発された技術です。
OAST ツールの例
お勧めします:
進む。
展開後のチェック
これは、アプリケーションのセキュリティと操作性を確保する上で重要な段階です。開発段階で実行されるコミット前チェックとは異なり、デプロイ後チェックでは、自然環境でのアプリケーションの運用中に発生する可能性のある問題をすでに特定できます。
人工物の安全性の監視
新しい脆弱性を適時に検出するには、アプリケーションの展開後も含め、定期的にアーティファクト チェックを実行する必要があります。
これは、次のような特別なリポジトリまたはツールを使用して実行できます。
アプリケーションセキュリティの監視
セキュリティを確保するもう 1 つの方法は、アプリケーション自体を監視することです。この目的のために利用できるテクノロジーがいくつかあります。
- Web アプリケーション ファイアウォール (WAF) は、トラフィック フィルタリング ツールです。アプリケーション層で動作し、HTTP/HTTPS トラフィックを分析することで Web アプリケーションを保護します。
- RASP (Runtime Application Self-Protection) は、アプリケーションに対する攻撃をリアルタイムに検出してブロックするテクノロジーです。ランタイム環境に防御機能を追加し、アプリケーションが自動的に自己保護できるようにします。
WAF に対する RASP の主な利点は、アプリケーションがどのように動作するかを理解し、攻撃や不正なトラフィックを検出できることです。 RASP では、シグネチャ照合を使用した典型的な攻撃だけでなく、異常に反応してゼロデイ脆弱性を悪用しようとする試みも確認できます。
WAF とは異なり、RASP はアプリケーション内およびアプリケーションと連携して動作します。 WAFは騙される可能性があります。攻撃者がアプリケーション コードを変更した場合、WAF は実行コンテキストを理解できないため、それを検出できません。
RASP はアプリケーションに関する診断情報にアクセスし、それを分析し、異常を検出し、攻撃をブロックできます。
RASP テクノロジーは、デフォルトで攻撃を防ぐことに重点を置いているという特徴があります。システムはソース コードにアクセスする必要はありません。
RASP 愚か者
お勧めします:
素晴らしいです、次に進みましょう。
DevSecOps パイプラインの結果と脆弱性管理の視覚化
パイプラインのさまざまな段階で、私は多くのアプリケーション セキュリティ テスト/DevSecOps アナライザーを使用します。それぞれが独自の形式でレポートを生成し、その中にはいわゆる誤検知を生成するものもあります。このため、アプリケーション全体のセキュリティを分析するのは簡単ではありません。
脆弱性を効果的に分析し、修復プロセスを管理するには、単にセキュリティ ダッシュボードと呼ばれることが多い、専用の脆弱性管理ツールが使用されます。
セキュリティ ダッシュボードは、DevSecOps 分析の結果を統合された分析しやすい形式で提供することで問題を解決します。このようにして、セキュリティ エンジニアは、どのような問題が存在し、どの問題が最も重要で、どの問題に最初に対処する必要があるかを確認できます。
DevSecOps ツール
通常、セキュリティ ダッシュボードとしては、従来の SOAR/SIEM システムや、Swordfish Security の特殊な DevSecOps オーケストレーター AppSec.Hub やオープンソースの脆弱性管理ツールキット DefectDojo など、幅広いツールが使用されます。
DefectDojo は広く普及しているツールです。エンタープライズ企業でも広く利用されています。ただし、その人気と堅固な歴史にもかかわらず、このツールには、寄稿者がコミットで基本機能を破壊した場合に、初期レベルの欠陥が発生することがあります。
ただし、素晴らしいのは、DefectDojo の開発者とメンテナが複雑さを解決するのに協力してくれることです。 DefectDojo 開発者は非常に敏感な人々です。GitHub の問題を通じて直接連絡することをお勧めします。
シフトレフトのコンセプト: まとめてみましょう
もう一度、記事の内容を簡単に要約します。
シフト レフトの概念とは何か、またそれがバグ修正のコストと開発時間の削減にどのように役立つかについて説明しました。開発プロセスの早い段階でセキュリティ チェックを開始するほど良いのです。
次に、DevSecOps パイプライン構造を分解し、パイプラインの各段階でどのようなセキュリティ チェックが実行されるかを調べました。
- 事前コミット。これは、ソース コードがバージョン管理システムに入る前に、ソース コードの安全性をチェックすることを意味します。
- 事前構築。バージョン管理システム (秘密検出、SAST、SCA) におけるソース コードのセキュリティのチェックです。
- ビルド後。これは、ソース コード (ソース SCA、バイナリ SCA) から構築されたアーティファクトのセキュリティ チェックです。
- テストの時間。これは、収集されたアーティファクト (DAST、IAST、および OAST) から実行されているアプリケーションのセキュリティをテストすることを意味します。
- 導入後。これは、運用環境 (WAF、RASP) への展開後にアプリケーションのセキュリティをチェックすることを意味します。
これで、DevSecOps パイプラインがどのように機能するか理解できました。 DevSecOps パイプラインの成熟度を評価し、その開発のロードマップを作成し、各タスクに適切なツールを選択できるようになりました。
L O A D I N G
. . . comments & more!
. . . comments & more!
About Author
ラベル
関連ストーリー
ワークフローを10倍に向上させる方法: 必須アプリ17選 #web-development
Jan 01, 1970
フロキのヴァルハラがインドのスリランカツアーのアソシエイトスポンサーに加わる #web3
Jan 01, 1970
