DevSecOps：SCAの原則と比較。パート1

Synopsys、Sonatype、Snyk、White Sourceが発行するオープンソースライブラリの脆弱性に関する年次レポートがリリースされるにつれて、開発プロセスにおけるサードパーティのソフトウェアコンポーネントの分析（ソフトウェア構成分析-SCA）の重要性が高まっています。State of Open Source Security Vulnerabilities2020によると2019年にオープンソースで特定された脆弱性の数は、前年と比較してほぼ1.5倍に増加しましたが、オープンソースコンポーネントはプロジェクトの60％から80％で使用されています。独立した意見に目を向けると、SCAプロセスは成熟度の指標としてOWASP SAMMとBSIMMの別個のプラクティスであり、2020年の前半に、OWASPは新しいOWASPソフトウェアコンポーネント検証標準（SCVS）をリリースしました。これは、サプライチェーン内のサードパーティコンポーネントを検証するためのベストプラクティスを提供します。沿って。







最も明らかなケースの1つは、2017年5月にEquifaxで発生しました。未知の攻撃者が、氏名、住所、社会保障番号、運転免許証など、1億4300万人のアメリカ人に関する情報を押収しました。 209,000件の場合、文書には被害者の銀行カードに関する情報も含まれていました。このリークは、Apache Struts 2（CVE-2017-5638）の重大な脆弱性の悪用によるものでしたが、修正は2017年3月にリリースされました。同社はアップデートをインストールするのに2か月かかりましたが、誰もそれについて気にしませんでした。



この記事では、分析結果の品質の観点から、SCAを実施するためのツールを選択する問題について説明します。ツールの機能比較もあります。CI / CDに埋め込むプロセスと統合の可能性は、将来の出版物に残されます。ツールの幅広いリストがOWASPによってそのWebサイトで提示されましたが、現在のレビューの一部として、最も人気のあるオープンソースツールのDependency Check、少しあまり知られていないオープンソースプラットフォームのDependency Track、およびSonatype Nexus IQEnterpriseソリューションについてのみ触れます。また、これらのソリューションがどのように機能するかを理解し、誤検知に対して得られた結果を比較します。

動作原理

依存関係チェックは、プロジェクトファイルを分析し、依存関係に関する情報（パッケージ名、グループID、仕様タイトル、バージョンなど）を収集し、CPE行を作成するユーティリティ（CLI、maven、jenkinsモジュール、ant）です-（Common Platform Enumeration）、Package URL（PURL）を作成し、データベース（NVD、Sonatype OSS Index、NPM Audit API ...）からCPE / PURLの脆弱性を検出し、HTML、JSON、XML形式で1回限りのレポートを作成します...



CPEがどのように見えるかを見てみましょう。

cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other

• パーツ：コンポーネントがアプリケーション（a）、オペレーティングシステム（o）、ハードウェア（h）に属していることの表示（必須項目）
• ベンダー：製品のメーカー名（必須）
• 商品：商品名（必須商品）
• バージョン：コンポーネントバージョン（廃止されたアイテム）
• 更新：パッケージを更新します
• エディション：レガシーバージョン（非推奨）
• 言語： RFC-5646で定義されている言語
• SWエディション：ソフトウェアバージョン
• ターゲットSW：製品が実行されるソフトウェア環境
• ターゲットハードウェア：製品が実行されるハードウェア環境
• その他：サプライヤーまたは製品情報

CPEの例は次のようになります。

cpe:2.3:a:pivotal_software:spring_framework:3.0.0:*:*:*:*:*:*:*

この行は、CPEバージョン2.3がpivotal_software 、spring_frameworkバージョン3.0.0という名前のメーカーのアプリケーションのコンポーネントを記述していることを意味します。NVDでCVE-2014-0225の脆弱性を開くと、このCPEについての言及があります。すぐに気付くべき最初の問題は、CPEによると、NVDのCVEが、特定のコンポーネントではなく、フレームワークに問題があることを報告していることです。つまり、開発者がフレームワークに緊密に結びついていて、特定された脆弱性が開発者が使用するモジュールに適用されない場合、セキュリティスペシャリストは何らかの方法でこのCVEを分解し、更新を検討する必要があります。



URLはSCAツールでも使用されます。パッケージのURL形式は次のとおりです。

scheme:type/namespace/name@version?qualifiers#subpath

• Sheme：これがパッケージURLであることを示す「pkg」が常にあります（必須）
• タイプ：パッケージの「タイプ」またはパッケージの「プロトコル」（maven、npm、nuget、gem、pypiなど）。（必須条項）
• 名前空間： MavenグループID、Dockerイメージの所有者、GitHubユーザー、組織などの名前のプレフィックス。オプションで、タイプによって異なります。
• 名前：パッケージ名（必須）
• バージョン：パッケージバージョン
• 修飾子： OS、アーキテクチャ、ディストリビューションなど、パッケージの追加の資格。オプションのタイプ固有のアイテム。
• サブパス：パッケージルートに関連するパッケージ内の追加パス

例えば：

pkg:golang/google.golang.org/genproto#googleapis/api/annotations
pkg:maven/org.apache.commons/io@1.3.4
pkg:pypi/django-package@1.11.1.dev1

Dependency Trackは、CycloneDXおよびSPDXによって生成された既製のBill of Materials（BOM）、つまり既存の依存関係に関する既製の仕様を受け入れるオンプレミスのWebプラットフォームです。これは、依存関係（名前、ハッシュ、パッケージURL、発行元、ライセンス）を記述したXMLファイルです。次に、依存関係トラックはBOMを解析し、脆弱性データベース（NVD、Sonatype OSSインデックスなど）から特定された依存関係で使用可能なCVEを調べ、グラフを作成してメトリックを計算し、コンポーネントの脆弱性ステータスデータを定期的に更新します。



BOMがXML形式でどのように見えるかの例：

<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.2" serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79" version="1">
  <components>
    <component type="library">
      <publisher>Apache</publisher>
      <group>org.apache.tomcat</group>
      <name>tomcat-catalina</name>
      <version>9.0.14</version>
      <hashes>
        <hash alg="MD5">3942447fac867ae5cdb3229b658f4d48</hash>
        <hash alg="SHA-1">e6b1000b94e835ffd37f4c6dcbdad43f4b48a02a</hash>
        <hash alg="SHA-256">f498a8ff2dd007e29c2074f5e4b01a9a01775c3ff3aeaf6906ea503bc5791b7b</hash>
        <hash alg="SHA-512">e8f33e424f3f4ed6db76a482fde1a5298970e442c531729119e37991884bdffab4f9426b7ee11fccd074eeda0634d71697d6f88a460dce0ac8d627a29f7d1282</hash>
      </hashes>
      <licenses>
        <license>
          <id>Apache-2.0</id>
        </license>
      </licenses>
      <purl>pkg:maven/org.apache.tomcat/tomcat-catalina@9.0.14</purl>
    </component>
      <!-- More components here -->
  </components>
</bom>

BOMは、依存関係トラックの入力パラメータとしてだけでなく、サプライチェーン内のソフトウェアコンポーネントのインベントリを作成するためにも使用できます。たとえば、顧客にソフトウェアを提供するために使用できます。 2014年に、2014年のサイバーサプライチェーン管理および透明性法が米国で検討するために提案されました。これは、ソフトウェアを購入するときは、どの州でもあると述べています。機関は脆弱なコンポーネントの悪用を防ぐためにBOMを要求する必要がありますが、この法律は施行されていません。



SCAに戻ると、Dependency Trackは、Slackなどの通知プラットフォームやKennaSecurityなどの脆弱性管理システムとすぐに統合できます。 Dependency Trackは、とりわけ、古いバージョンのパッケージを検出し、ライセンスに関する情報を提供することにも注意してください（SPDXのサポートによる）。



SCAの品質について具体的に話すと、根本的な違いがあります。



依存関係トラックは、プロジェクトを入力として受け入れるのではなく、BOMを受け入れます。つまり、プロジェクトを確認する場合は、最初に、たとえばCycloneDXを使用してbom.xmlを生成する必要があります。したがって、依存関係トラックはCycloneDXに直接依存しています。同時に、それはカスタマイズを可能にします。そのため、OZONチームはCycloneDXモジュールを作成して、依存関係トラックをさらにスキャンするためのGolangプロジェクトのBOMファイルを作成しました。



Nexus IQSonatypeエコシステムの一部であるSonatypeの商用SCAソリューションであり、Nexus RepositoryManagerも含まれています。Nexus IQは、WebインターフェイスまたはAPIを介した戦争アーカイブ（Javaプロジェクトの場合）と、組織がCycloneDXから新しいソリューションへの再構築に成功していない場合は、BOMの両方を入力データとして受け入れることができます。オープンソースソリューションとは異なり、IQは、識別されたコンポーネントのCPE / PURLとそれに対応するデータベースの脆弱性を参照するだけでなく、脆弱な関数やクラスの名前など、独自の調査も考慮に入れます。IQメカニズムについては、結果の分析の後半で説明します。



機能的な機能のいくつかを要約し、分析のためにサポートされている言語についても検討しましょう：





機能性





統合の機会

依存関係チェック

最初のスタート

意図的に脆弱なDVJAアプリケーションで依存関係チェックを実行してみましょう。



これを行うには、依存関係チェックMavenプラグインを使用します。

mvn org.owasp:dependency-check-maven:check

その結果、dependency-check-report.htmlがターゲットディレクトリに表示されます。







ファイルを開いてみましょう。脆弱性の総数に関する要約情報の後に、パッケージ、CPE、CVE番号を示す、重大度と信頼性のレベルが高い脆弱性に関する情報が表示されます。



これに続いて、より詳細な情報、特に証拠の基になっているもの、つまり特定のBOMが続きます。







次は、CPE、PURL、およびCVEの説明です。ちなみに、NVDデータベースにないため、修正の推奨事項は添付されていません。







スキャン結果を体系的に確認するには、最小限の設定でNginxを構成するか、結果の欠陥を依存関係チェックコネクタをサポートする欠陥管理システムに送信します。たとえば、欠陥Dojo。

依存関係トラック

インストール

Dependency Trackは、チャートを表示するWebプラットフォームであるため、サードパーティのソリューションに欠陥を保存するという重大な問題はありません。

インストール用にサポートされているスクリプトは次のとおりです：Docker、WAR、ExecutableWAR。

最初のスタート

実行中のサービスのURLに移動します。admin / adminから入力し、ユーザー名とパスワードを変更してから、ダッシュボードに移動します。次に行うことは、[ホーム] / [プロジェクト]→[プロジェクトの作成]でJavaテストアプリケーションのプロジェクトを作成することです。例としてDVJAを取り上げましょう。







依存関係トラックは入力としてBOMのみを受け入れることができるため、このBOMを取得する必要があります。CycloneDXMavenプラグインを使用しましょう：

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

bom.xmlを取得し、作成したプロジェクトDVJA→依存関係→アップロードBOMにファイルをアップロードします。



[管理]→[アナライザー]に移動しましょう。NVDを含め、内部アナライザーのみが有効になっていることを理解しています。また、Sonatype OSSIndexを接続します。







したがって、私たちのプロジェクトについて次の図が得られ







ます。リストには、Sonatype OSSに適用可能な1つの脆弱性があります







。主な失望は、依存関係トラックが依存関係チェックxmlレポートを受け入れなくなったことです。5.3.2をテストしている間、依存関係チェック統合の最後にサポートされたバージョンは1.0.0〜4.0.2でした。



ここでビデオ（と、今、それはまだ可能であった場合）。

Nexus IQ

最初のスタート

Nexus IQはドキュメントアーカイブからインストールされますが、この目的のためにDockerイメージをコンパイルしました。



コンソールにログインした後、組織とアプリケーションを作成する必要があります。















ご覧のとおり、IQの場合の設定は少し複雑です。これは、さまざまな「ステージ」（開発、ビルド、ステージ、リリース）に適用できるポリシーも作成する必要があるためです。これは、脆弱なコンポーネントがパイプラインに沿って製品に近づくときにブロックするか、開発者がダウンロードしたときにNexusリポジトリに入るとすぐにブロックするために必要です。



オープンソースとエンタープライズの違いを感じるために、以前にNexusIQインターフェイスでテストアプリケーションを作成したMavenプラグインを使用して、同じ方法でNexusIQを使用して同じスキャンを実行してみましょうdvja-test-and-compare。

mvn com.sonatype.clm:clm-maven-plugin:evaluate -Dclm.applicationId=dvja-test-and-compare -Dclm.serverUrl=<NEXUSIQIP> -Dclm.username=<USERNAME> -Dclm.password=<PASSWORD>

IQ Webインターフェイスで生成されたレポートのURLに移動します。







ここでは、重要度のレベルが異なるすべてのポリシー違反を確認できます（情報からセキュリティクリティカルまで）。コンポーネントの横にある文字Dは、コンポーネントが直接依存であることを意味し、コンポーネントの横にある文字Tは、コンポーネントが遷移依存であること、つまり、遷移であることを意味します。



ちなみに、SnykのState of Open Source Security Report 2020は、Node.js、Java、Rubyで見つかったオープンソースの脆弱性の70％以上が一時的な依存関係にあると報告しています。



Nexus IQポリシー違反のいずれかを開くと、コンポーネントの説明と、タイムライン上の現在のバージョンの場所を示すバージョングラフ、および脆弱性がもはや脆弱ではなくなった時点を確認できます。グラフのローソク足の高さは、このコンポーネントの人気を示しています。







脆弱性のセクションに移動してCVEを開示すると、この脆弱性の説明、排除の推奨事項、およびこのコンポーネントが違反された理由、つまりクラスの存在を読むことができますDiskFileitem.class。











サードパーティのJavaコンポーネントのみを要約し、jsコンポーネントを削除しましょう。括弧内は、NVDの外部で見つかった脆弱性の数を示しています。



トータルネクサスIQ：

• スキャンされた依存関係：62
• 脆弱な依存関係：16
• 見つかった脆弱性：42（8ソナタイプデータベース）

完全な依存関係チェック：

• スキャンされた依存関係：47
• 脆弱な依存関係：13
• 見つかった脆弱性：91（14ソナタイプoss）

総依存関係トラック：

• スキャンされた依存関係：59
• 脆弱な依存関係：10
• 見つかった脆弱性：51（1ソナタイプoss）

次のステップは、得られた結果を分析し、これらの脆弱性のどれが実際の欠陥であり、どれが誤検知であるかを把握することです。

免責事項

このレビューは否定できない真実ではありません。著者には、別の楽器を他の楽器の背景と区別するという目標はありませんでした。レビューのポイントは、SCAツールがどのように機能し、その結果を確認する方法を示すことでした。

結果の比較

状態：



サードパーティコンポーネントの脆弱性に関連する誤検知は次のとおりです。

• 識別されたコンポーネントのCVEの不一致
• , struts2, struts-tiles, , false positive
• CVE
• , python > 3.5 2.7 — false positive, 3.x
• CVE
• , SCA CVE, RCE, SCA CVE, Cisco, RCE. false positive.
• たとえば、CVEはSpring-Webコンポーネントで見つかりました。その後、SCAはSpring Frameworkの他のコンポーネントの同じCVEを指しますが、CVEは他のコンポーネントとは何の関係もありません。この場合、誤検知になります。

オープンソースプロジェクトDVJAが研究対象として選ばれました。調査には、javaコンポーネントのみが含まれていました（jsは含まれていません）。

まとめ結果

特定された脆弱性を手動で確認した結果に直接進みましょう。各CVEの完全なレポートは、付録にあります。



すべての脆弱性の要約結果：



コンポーネントごとの要約結果：



脆弱性の総数に対する偽陽性と偽陰性の比率を評価するための視覚的なグラフを作成しましょう。コンポーネントは水平方向にマークされ、コンポーネントで識別された脆弱性は垂直方向にマークされます。















比較すると、同様の調査がSonatypeチームによって実施され、OWASP DependencyCheckを使用して1,531コンポーネントプロジェクトをテストしました。ご覧のとおり、正しいトリガーに対するノイズの比率は、私たちの結果に匹敵します。





出典：www.sonatype.com/why-precision-matters-ebook



スキャン結果からいくつかのCVEを見て、これらの結果の理由を理解しましょう。

詳細

＃1

まず、Sonatype NexusIQのいくつかの興味深い点を見てみましょう。



Nexus IQは、SpringFrameworkでRCEを複数回実行する機能に関する逆シリアル化の問題を指摘しています。spring-webのCVE-2016-1000027：3.0.5が初めて、spring-contextのCVE-2011-2894：3.0.5およびspring-core：3.0.5。最初は、複数のCVE間で脆弱性が重複しているように見えます。NVDデータベースのCVE-2016-1000027とCVE-2011-2894を見ると、すべてが明らかであるように思われます。





説明CVE-2011-2894からNVD：





の説明CVE-2016-1000027からNVD：





CVE-2011-2894自体は非常に有名です。 2011年のホワイトソースレポートは、このCVEを最も頻繁に遭遇するものの1つとしてランク付けしました。 CVE-2016-100027の説明は、原則としてNVDに少し含まれており、Spring Framework4.1.4にのみ適用できるようです。参考文献を見てください、そしてここでそれは多かれ少なかれ明らかになります。Tenableの記事からRemoteInvocationSerializingExporter、CVE-2011-2894の脆弱性に加えて、脆弱性がで観察されてHttpInvokerServiceExporterいることがわかります。これは、Nexus IQが私たちに伝えていることです。







それにもかかわらず、NVDにはこのようなものはありません。そのため、依存関係チェックと依存関係追跡はフォールスネガティブを受け取ります。



また、CVE-2011-2894の説明から、この脆弱性は実際にspring-context：3.0.5およびspring-core：3.0.5に存在することが理解できます。これの確認は、この脆弱性を見つけた人からの記事で見つけることができます。

＃2

CVE-2016-4003の脆弱性を調査すると、バージョン2.3.28で修正されたことがわかりますが、NexusIQから通知されます。脆弱性の説明には注意があります。







つまり、この脆弱性は、古いバージョンのJREとの関連でのみ存在し、警告することにしました。それでも、最悪ではありませんが、これは誤検知であると考えています。

ナンバー3

CVE-2017-9804とCVE-2017-7672の説明を見ると、問題がURLValidator classであることがわかります。CVE-2017-9804はCVE-2017-7672の後に続きます。2番目の脆弱性の存在は、その重大度がHighに成長したことを除いて、ペイロードを運ばないため、これは不要なノイズと見なすことができます。



全体として、NexusIQについて他の誤検知は見つかりませんでした。

＃4

IQを他の決定と区別するいくつかのことがあります。





NVDのCVEは、バージョン5.2.xから5.2.3、5.1.xから5.1.13、およびバージョン5.0.xから5.0.16にのみ適用可能であると述べていますが、Nexus IQのCVEの説明を見ると、私たちは、次のように表示されます。

諮問偏差お知らせ：Sonatypeセキュリティ研究チームがアドバイザリで述べたように、この脆弱性は、バージョン3.0.2.RELEASEとないバージョン5.0.xで導入されたことを発見しました。



この後に、この脆弱性のPoCが続き、バージョン3.0.5に存在することが報告されます。



フォールスネガティブは、依存関係チェックと依存関係トラックに送信されます。

＃5

依存関係チェックと依存関係追跡の誤検知を見てみましょう。



依存関係チェックは、NVDのフレームワーク全体に適用されるCVEを、それらのCVEが適用されないコンポーネントに反映するという点で際立っています。これは、CVE-2012-0394、CVE-2013-2115、CVE-2014-0114、CVE-2015-0899、CVE-2015-2992、CVE-2016-1181、CVE-2016-1182に適用され、依存関係チェックが「ねじ込まれ」ます。 struts-taglibへ：1.3.8およびstruts-tiles-1.3.8。これらのコンポーネントは、CVEで説明されているもの（要求処理、ページ検証など）とは何の関係もありません。これは、これらのCVEとコンポーネントに共通するのはフレームワークのみであるため、依存関係チェックでは脆弱性と見なされていました。



spring-txでの同じ状況：3.0.5、およびstruts-coreでの同様の状況：1.3.8。struts-coreの場合、DependencyCheckとDependencyTrackは、本質的に別個のフレームワークであるstruts2-coreに実際に適用できる多くの脆弱性を発見しました。この場合、Nexus IQは画像を正しく理解し、発行されたCVEで、struts-coreが廃止され、struts2-coreに移動する必要があることを示しました。

＃6

状況によっては、明示的な依存関係チェックおよび依存関係追跡エラーを解釈するのは不公平です。特に、CVE-2013-4152、CVE-2013-6429、CVE-2013-6430、CVE-2013-7315、CVE-2014-0054、CVE-2014-0225、CVE-2014-0225は、依存関係チェックと依存関係トラックです。スプリングコア：3.0.5と呼ばれる実際にはスプリングウェブ：3.0.5を指します。同時に、これらのCVEのいくつかが見つかりましたが、Nexus IQは、それにもかかわらず、IQが別のコンポーネントに対してそれらを正しく識別しました。これらの脆弱性はスプリングコアでは検出されなかったため、原則としてフレームワークに含まれていないとは言えず、オープンソースツールはこれらの脆弱性を正しく指摘しました（少し見落としただけです）。

結論

ご覧のとおり、特定された脆弱性の信頼性を手動で確認しても明確な結果は得られず、物議を醸す問題が発生します。その結果、NexusIQソリューションの誤検出率が最も低くなり、精度が最も高くなります。



まず、これは、Sonatypeチームがデータベース内のNVDから各CVE脆弱性の説明を拡張し、コンポーネントの特定のバージョンの脆弱性のクラスまたは機能を正確に指定して、追加の調査（たとえば、古いものの脆弱性のチェック）を実施したためです。ソフトウェアバージョン）。



結果への重要な影響は、NVDに含まれていなかったが、それでもSONATYPEマークが付いたSonatypeデータベースに存在する脆弱性によってもたらされます。State of Open Source Security Vulnerabilities2020によると発見されたオープンソースの脆弱性の45％はNVDに報告されていません。 WhiteSourceデータベースによると、NVDの外部で報告されたすべてのオープンソースの脆弱性の29％のみがそこで公開されるため、他の場所でも脆弱性を探すことが重要です。



その結果、依存関係チェックは多くのノイズを生成し、いくつかの脆弱なコンポーネントを見逃します。依存関係トラックは、ノイズが少なく、多数のコンポーネントを表示します。これにより、Webインターフェイスの目を傷つけることはありません。



それにもかかわらず、実践は、DevSecOpsを成熟させるための最初のステップとなるのはオープンソースであることを示しています。SCAを開発に組み込むために最初に考えることは、プロセスです。つまり、管理部門や関連部門と協力して、組織内で理想的なプロセスがどのように見えるかを考えます。最初は、組織にとって、依存関係チェックまたは依存関係トラックがすべてのビジネスニーズをカバーし、開発されたアプリケーションの複雑さが増すため、エンタープライズソリューションは論理的な継続となることが判明する場合があります。