helping to deliver secure software updates from code to the edge.
You have been redirected to the JFrog website
DevSecOpsの原則およびプラクティスを従来のDevOpsの原則およびプラクティスと並行させることにより、統合された学際的チームが協力して、継続的なソフトウェアデリバリの安全性を確保します。DevSecOps開発ライフサイクルは、開発者がコードを書くことから始まって、ビルドをトリガーし、ソフトウェアパッケージを本番環境にデプロイし、実行時に識別される問題を監視するという反復プロセスですが、これらの各段階にセキュリティが含まれます。
DevSecOpsのベストプラクティスでは、確実にセキュリティがソフトウェア開発ライフサイクルの不可欠な部分となる必要があります。このプロセスは、新しい機能が開発され、バグが修正されるたびに繰り返されます。開発とリリースを迅速化するために、開発者はプロジェクトを完成させる点でオープンソースソフトウェアに依存しています。典型的な最新のアプリケーションは、最大90パーセントがオープンソースソフトウェアで構成されています。これにより、組織に以下の問題が持ち込まれる可能性があります。
開発者レポートと手動プロセスに依存していては、部分的な全体像しか掴めません。したがって、セキュリティとコンプライアンスがDevSecOpsプロセスの不可欠な部分となります。
現状では、開発者、運用者、セキュリティ担当者の比率は200:5:1です。つまり、セキュリティ脆弱性スキャンツールによって特定されたセキュリティの問題は、技術的な知識が不足している可能性がある非常に少人数のセキュリティチームがレビューしなければならないということです。この課題は、開発者チームと運用チームがセキュリティとコンプライアンスの責任も担い、SDLCプロセスの早い段階にセキュリティを移行することで軽減できます。
CI/CDパイプラインの早い段階でセキュリティ問題の特定を実装し、手動プロセスを使用するのではなく、ソフトウェア開発ライフサイクル（SDLC）でセキュリティおよびコンプライアンスのポリシーを自動化することが重要です。さらに、セキュリティ（Sec）をDevOpsから除外している組織は、リリース間際にセキュリティとコンプライアンスの問題に直面し、そのような問題を修正するための追加コストが発生する可能性があります。
DevSecOpsカルチャは、全員がセキュリティの責任と所有権を持つカルチャです。DevOpsのベストプラクティスと融合させるため、各開発チームは、提供されるソフトウェアのセキュリティを最大限に高めることを目的として、チーム内のセキュリティとコンプライアンスのプロセスとアクションを主導するセキュリティチャンピオンを割り当てるべきです。
DevOpsの本質は、人為的エラーを防ぐために可能な限り自動化し、不安定なコードが本番環境に入るのを防ぐ自動化されたゲートを作成することです。本来、セキュリティ脆弱性または非準拠のライセンスが含まれるコードは不安定です。
組織にDevSecOpsを導入して実装するには、文化的および運用上の変化が必要です。それには、セキュリティトレーニング、ツール、およびリソースが含まれます。ここでは、組織文化を変えるときに役立つ概念をいくつか紹介します。
これらのチームメンバーは、全体的なセキュリティの側面について責任を担い、それらがDevOpsパイプラインに実装されていることを確認し、チームの他のメンバーに公開します。たとえば、開発チームのセキュリティチャンピオンは、以下に関するチームでの実装と使用を主導します。
QAチームのセキュリティチャンピオンは以下を実装します。
DevSecOpsのプラクティスでは、ソフトウェアが本番環境にリリースされる直前ではなく、SLDCの一部としてセキュリティが必要です。これは、開発者がセキュリティスキャンをビルドプロセスとIDE環境に統合して、脆弱な依存関係を特定することを意味します。
開発者の数はセキュリティ専門家を200:1の割合で上回っています。専用のIDEプラグインを使用すると、開発者がすでに使用しているツールにセキュリティデータを直接取り込むことができるため、簡単に採用できます。開発者がコードを書くときにセキュリティの問題を回避する方法について、開発者向けのベストプラクティスをご紹介します。
JFrog Xrayは、コードで使用されている依存関係に関するセキュリティの脆弱性情報を提供することにより、開発者がセキュリティをすぐに確保できるようにします。
コードレビューなどの手動チェックに加えて、セキュリティチェックポイントをDevOpsパイプラインの各フェーズに分散させ、ソフトウェアが次のフェーズに進むことができるかどうかを判断できます。 ガバナンスシステムは、企業のポリシーを自動的に適用し、それに応じて介入なしに次のようなアクションを実行できます。
JFrog Xrayを任意のCIサーバーと統合して、ビルドのアーティファクトまたは依存関係にセキュリティ脆弱性またはオープンソースライセンスのコンプライアンス違反が見つかった場合にビルドを失敗させることができます。
DevSecOpsをパイプラインに自動化して、セキュリティの抽象的なオーバーレイを作成できます。
SDLCのさまざまな側面に対処するため、セキュリティおよびコンプライアンスのツールにはいくつかのファミリがあります。これには、静的コード分析（SAST）、ソフトウェア構成分析（SCA）、および脆弱性についてコードをテストするための異なるアプローチ（DASTおよびIAST）が含まれます。さらに、コードや環境の脆弱性を悪用する攻撃から本番環境のバイナリを監視および保護することを目的としたツールもあります。理想的には、チームは完全なSDLCセキュリティを確保するためにこれらすべての領域を採用することを目指すべきです。
静的アプリケーションセキュリティテスト（SAST）ツールは、独自に開発したプロプライエタリコードの脆弱性を特定するのに役立ちます。開発者は、開発プロセスの自動化部分と認識してSASTツールを使用する必要があります。これにより、DevOpsサイクルの早い段階で潜在的な脆弱性を検出して修正することができます。
ソフトウェア構成分析（SCA）には、コードが依存するオープンソースコンポーネントでのライセンスコンプライアンスとセキュリティ脆弱性の管理と監視が含まれます。使用されているOSSコンポーネントとその依存関係を把握することが、第一に重要なことです。オープンソースコンポーネントを特定した後、JFrog XrayなどのSCAツールは、ライセンスに関する情報と、それらのコンポーネントに関連する既知のセキュリティ脆弱性の有無などの情報を提供します。高度なSCAツールにはポリシー適用機能が備わっていて、バイナリのダウンロードを防止したり、ビルドを失敗させたり、他のシステムへ通知したりします。
動的アプリケーションセキュリティテストおよび対話型アプリケーションセキュリティテスト（DASTおよびIAST）ツールは、実行中のアプリケーションの公開されたインターフェイスをテストし、脆弱性と欠陥を探します。DASTはアプリケーションをブラックボックスと見なしますが、IASTは動的アプリケーションセキュリティテスト（DAST）と静的分析セキュリティテスト（SAST）の手法を組み合わせたインストルメンテーションを使用して、アプリケーションセキュリティテストの精度を高めます。
コンテナランタイムセキュリティツールは、ランタイム環境のコンテナを監視します。このようなツールは、さまざまな機能を提供します。たとえば、各種レベルでのファイアウォール、行動分析に基づく異常の特定などです。
DevSecOpsのベストプラクティス
ソフトウェア構成分析（SCA）の必要性は、開発者がイノベーションのペースについていくために使用するオープンソースソフトウェアコンポーネントの利用が増えたことから生じています。企業は、チームやサイト間でのオープンソースの使用状況の管理および追跡に苦労しており、より自動化された方法を必要としていました。
通常、オープンソースソフトウェアはアプリケーションのコードの90％を占めています。コードのこの部分を管理し、安全性を確保することが重要です。
あまりにも多くの企業が、自分たちが書いたコードだけに注目し、オープンソースコンポーネントのリスクを見落としています。これは、EquifaxやCapital Oneなどの企業に数百万ドルのコストを負わせる、悪名高いセキュリティやライセンスの違反につながる可能性があります。この状況を、SCAソリューションは解決できます。
DevSecOps に重要なSCAには、オープンソースコンポーネントでのライセンスコンプライアンスとセキュリティの脆弱性の管理と監視が含まれます。使用されているOSSコンポーネントとその依存関係を把握することが、第一に重要です。組織内のOSSコンポーネントを特定した後、SCAツールは、ライセンスの情報、バージョン番号、およびそれに関連する既知のセキュリティ脆弱性の有無などを含む、各コンポーネントの可視性を提供します。
現在、最新のアプリケーションは、最大90%がOSSコンポーネントで構成されています。これは、私たちが日常的に構築、展開、および消費しているソフトウェアの大部分で、脆弱性が含まれている可能性がこれまで以上に高いことを意味します。オープンであるため、ハッカーは簡単にコードを確認し、脆弱性を探すことができます。オープンソースソフトウェアは脆弱性を通じてリスクをもたらすだけでなく、組織に複雑なライセンスコンプライアンスの問題をもたらす可能性もあります。複雑化する可能性があるのは、ライセンスに「このコンポーネントを使用する場合は、コードをオープンソースにする必要がある」と述べられている場合です。
理想的には、開発プロセスのできるだけ早い段階で、すべてのOSSコンポーネントのライセンスコンプライアンスと脆弱性の問題をスキャンして特定する必要があります。アプリケーションポートフォリオ全体でどのコンポーネントを使用しているかを把握し、それらを追跡することは絶対に必要であり、最終的には自動化すべきです。これは、開発とリリースの速度を軌道に乗せるための、CI/CDパイプラインの不可欠な部分です。
これまで、SDLC全体から本番環境までのセキュリティを確保するには、コンポーネントスキャンを行うためのエージェントの実行が必要でした。現在、より高いレベルのセキュリティとコンプライアンスの監視を実現できるさまざまなソリューションがあり、IDE、リポジトリマネージャー、CI/CDパイプラインに直接統合され、コンテナイメージをスキャンすることもできます。オープンソースのセキュリティとコンプライアンスの監視には、ネイティブに統合されたSCAソリューションが最適です。
高度なSCAツールにはポリシー適用機能が備わっており、オープンソースコンポーネントの自動監視を行うことができます。この機能では、スキャン対象のコンテキストに基づいて、特定されたセキュリティ違反またはコンプライアンス違反に対してさまざまな動作を構成できます。たとえば、脆弱性に基づいて非常に機密性の高いアプリケーションのビルドを失敗させる一方で、同じ脆弱性のあるコンポーネントを使用したテストアプリケーションのビルドは失敗させないなどです。SCAツールは、コード内のすべてのオープンソースコンポーネントをポリシーと比較し、結果に応じてさまざまなタイプの自動アクションをトリガーします。
SCAツールは、既知の脆弱性とライセンスの参照データベースを使用して、アプリケーションで使用されているOSSの依存関係を比較します。データベースが包括的であるほど、本番環境のコードに既知の脆弱性やライセンスの問題が発生するリスクが低くなります。
ソフトウェア構成分析ツールを検討する際には、次の点を考慮することが重要です。
1.テクノロジーサポート：どの程度ユニバーサルで、組織で使用されるすべてのコーディング言語とパッケージの種類をサポートしていますか。
2.エコシステム統合：SCAツールは、リポジトリ、IDE、パッケージマネージャー、CIサーバーなどと、すぐに使用できる統合機能や豊富なオープンAPIを介して統合される必要があります。
3.データベース：最高のカバレッジを提供するためには、包括的なライセンスと脆弱性のデータベースが必要です。
完全なセキュリティスタックは以下のツールで構成されている必要があります。
- 動的アプリケーションセキュリティテスト（DAST）
- 対話型アプリケーションセキュリティテスト（IAST）
- ソフトウェア構成分析（SCA）
- 静的アプリケーションセキュリティテスト（SAST）
JFrog Xrayは、アプリケーションコードを書くために依存するOSSコンポーネントと依存関係から、オープンソースのセキュリティ脆弱性とライセンスコンプライアンスの問題を検出して排除することに焦点を当てたSCAツールです。コードベースは最大90％がOSSで構成されているため、Xrayは本番環境リリースの安定性と安全性の確保に大きな影響を及ぼすことができます。
このようなアプローチを採用する組織は、問題の早期発見による品質の向上、プロプライエタリコードとオープンソースコード全体の可視化、開発プロセスの早い段階で脆弱性を検出して修正することによる修復コストの削減、セキュリティ侵害リスクの最小化、セキュリティテストの最適化など、SDLC全体で改善が見られます。
これまでで最高のSCAツールの統合を実現することは可能ですが、セキュリティスキャンソリューションの善し悪しは、それを駆動する脆弱性データベースに左右されます。最新の脆弱性に対応していないデータベースを使用することは、群衆の中の誰かを、その特徴も知らずに見つけようとするようなものです。一部の企業は、National Vulnerability Database（NVD）でのMITREの共通脆弱性タイプ一覧（CVE）の使用を、セキュリティを確保するためのゴールドスタンダードと見なしています。多くのセキュリティ専門家は、脆弱性データに関してCVEとNVDに依存するだけではもはや十分ではないと断言しています。
たとえば、最もタイムリーで包括的な脆弱性インテリジェンスサービスの1つであるVulnDBを利用できることで知られるRisk Based Securityは、そのサービスによりCVEおよびNVDを上回る総数の脆弱性を毎年特定および分類しています。CVE/NVDでは見つからない数万件の脆弱性を含む、27,676のベンダーの製品をカバーする、249,155を超える脆弱性により、VulnDBは市場で最も包括的なソリューションとなっています。2,000を超えるサードパーティのライブラリが特定され、脆弱性が監視されています。
JFrog Xrayは、脆弱性とライセンスコンプライアンスのインテリジェンスの主要なソースであるVulnDBと緊密に統合されていることから恩恵を受けています。
第一に、業界の多くのセキュリティ専門家は、脆弱性データに関してCVEデータベースとNVDデータベースに依存するだけではもはや十分ではないと断言しています。脆弱性がCVE/NVDデータベースに公開されるまでには長い時間がかかることがあり、その間に悪意のある人物がこれらの脆弱性を分析し、悪質な活動にそれらをどのように利用できるかを考え出す可能性があります。
SCAソリューションのデータベースに脆弱性が含められるのが早ければ早いほど、その脆弱性が存在しないように本番環境コードを迅速に保護できます。ライセンスの種類とバージョンのチェックについても同じことが言えます。コンプライアンス部門または法務部門には、オープンソースソフトウェアライセンスの使用に関する一連のガイドラインがあります。チェックするライセンスの最新のデータベースがあると、本番環境コードに意図しないライセンスの種類が含まれるというリスクを最小限に抑えることができます。こうしたリスクに対処するには、費用がかかり、処理が複雑になる可能性があります。
OSSの依存関係でライセンスコンプライアンスを確保することは、コンプライアンスマネージャー、法務チーム、およびCEOにとっても同様にますます大きな懸案事項となっています。監査に失敗したり、多額の費用がかかる知的財産またはライセンス侵害の訴訟裁判に巻き込まれたりすることは、誰も望みません。どのOSSが、どの開発者によって、どのビルドおよびリリースで使用されているかを把握することは非常に重要です。
誰もが、セキュリティ侵害のコストを痛感しています。数十億ドルの損失を被った、最近のSolarWinds社の侵害、または悪名高いEquifaxの大失態を振り返るだけで十分です。ソフトウェアライセンスのコンプライアンスから逸脱することは大きなリスクとなり、複雑で費用のかかる知的財産の争いに巻き込まれる可能性があります。特定のライセンス条項では、それらのコードを使用する場合に、アプリケーションコード全体をオープンソースにしなければならないこともあり得ます。また、自社の王冠の宝石を進んで無償で手放すCEOは多くはありません。一部の企業では、ソフトウェアの性質上、他の企業よりもソフトウェア監査の対象となる可能性があります。監査に失敗すると、所属する業界によっては高額の罰金が科せられることがあります。
