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 x光は,アプリケーションコードを書くために依存するOSSコンポーネントと依存関係から,オープンソースのセキュリティ脆弱性とライセンスコンプライアンスの問題を検出して排除することに焦点を当てたSCAツールです。コードベースは最大90%がOSSで構成されているため,x光は本番環境リリースの安定性と安全性の確保に大きな影響を及ぼすことができます。

このようなアプローチを採用する組織は,問題の早期発見による品質の向上,プロプライエタリコードとオープンソースコード全体の可視化,開発プロセスの早い段階で脆弱性を検出して修正することによる修復コストの削減,セキュリティ侵害リスクの最小化,セキュリティテストの最適化など,SDLC全体で改善が見られます。

これまでで最高のSCAツールの統合を実現することは可能ですが,セキュリティスキャンソリューションの善し悪しは,それを駆動する脆弱性データベースに左右されます。最新の脆弱性に対応していないデータベースを使用することは,群衆の中の誰かを,その特徴も知らずに見つけようとするようなものです。一部の企業は,国家漏洞数据库(NVD)での横切の共通脆弱性タイプ一覧(CVE)の使用を,セキュリティを確保するためのゴールドスタンダードと見なしています。多くのセキュリティ専門家は,脆弱性データに関してCVEとNVDに依存するだけではもはや十分ではないと断言しています。

たとえば,最もタイムリーで包括的な脆弱性インテリジェンスサービスの1つであるVulnDBを利用できることで知られる基于风险的安全はそのサービスによりCVEおよびNVDを上回る総数の脆弱性を毎年特定および分類しています。CVE / NVDでは見つからない数万件の脆弱性を含む,27676のベンダーの製品をカバーする,249155を超える脆弱性により,VulnDBは市場で最も包括的なソリューションとなっています。2000を超えるサ、ドパ、ティのラ、ブラリが特定され、脆弱性が監視されています。

JFrog x光は,脆弱性とライセンスコンプライアンスのインテリジェンスの主要なソースであるVulnDBと緊密に統合されていることから恩恵を受けています。

第一に,業界の多くのセキュリティ専門家は,脆弱性データに関してCVEデータベースとNVDデータベースに依存するだけではもはや十分ではないと断言しています。脆弱性がCVE / NVDデータベースに公開されるまでには長い時間がかかることがあり,その間に悪意のある人物がこれらの脆弱性を分析し,悪質な活動にそれらをどのように利用できるかを考え出す可能性があります。

SCAソリューションのデータベースに脆弱性が含められるのが早ければ早いほど,その脆弱性が存在しないように本番環境コードを迅速に保護できます。ラ▪▪センスの種類とバ▪▪ジョンのチェックに▪▪いても同じことが言えます。コンプライアンス部門または法務部門には,オープンソースソフトウェアライセンスの使用に関する一連のガイドラインがあります。チェックするライセンスの最新のデータベースがあると,本番環境コードに意図しないライセンスの種類が含まれるというリスクを最小限に抑えることができます。こうしたリスクに対処するには，費用がかかり，処理が複雑になる可能性があります。

OSSの依存関係でライセンスコンプライアンスを確保することは,コンプライアンスマネージャー,法務チーム,およびCEOにとっても同様にますます大きな懸案事項となっています。監査に失敗したり,多額の費用がかかる知的財産またはライセンス侵害の訴訟裁判に巻き込まれたりすることは,誰も望みません。どのOSSが,どの開発者によって,どのビルドおよびリリースで使用されているかを把握することは非常に重要です。

誰もが，セキュリティ侵害のコストを痛感しています。数十億ドルの損失を被った,最近のSolarWinds社の侵害,または悪名高いEquifaxの大失態を振り返るだけで十分です。ソフトウェアライセンスのコンプライアンスから逸脱することは大きなリスクとなり,複雑で費用のかかる知的財産の争いに巻き込まれる可能性があります。特定のライセンス条項では,それらのコードを使用する場合に,アプリケーションコード全体をオープンソースにしなければならないこともあり得ます。また，自社の王冠の宝石を進んで無償で手放すceoは多くはありません。一部の企業では，ソフトウェアの性質上，他の企業よりもソフトウェア監査の対象となる可能性があります。監査に失敗すると，所属する業界によっては高額の罰金が科せられることがあります。