SBOM、BitBucket、およびOWASP Dependency Trackについて

チュートリアル

私が関与している古い建築物と新しい建築物の博物館は、それらを保護することを検討するように強制しました。たとえば、古い依存関係がCVEになることも、堅牢なオープンソースプロジェクトが商業化することもあります。このようなシステムのライセンスと依存関係エコシステムをカタログ化するために、ソフトウェア資材（SBOM）のコンセプトが生まれました。このビルドアーティファクトは、それ自体が、構成要素が

  1. 悪用されやすいか、または
  2. 商業的すぎるか、または過剰な捕食的であるなどの望ましくない条件でライセンスされているかを判断するために分析されます。

この記事では、以下を使用してその脆弱性を制御する方法について説明します：

  1. SBOM生成用のBitBucketパイプ、および
  2. OWASPのDependency Trackがそれを分析する方法。

リスクを知る

コードやコンテナに潜むものを知らないことは幸せかもしれませんが、危険です。ただし、すべてのコンポーネントを依存性分析ツールに通すことで、圧倒的なフィードバックが得られます。依存関係の問題の量は、常に昨日よりも少ない方が良いという文化をチームに組み込むことが重要です。

ウィキペディアによると、「オープンウェブアプリケーションセキュリティプロジェクト（OWASP）は、IoT、システムソフトウェア、Webアプリケーションセキュリティの分野で、自由に利用できる記事、方法論、文書、ツール、技術を提供するオンラインコミュニティです。」したがって、彼らがシステムの脆弱性を追跡および分析するプラットフォームを提供していることは驚くべきことではありません。その最も印象的な機能は、メインダッシュボードです。

中央にある最大のグラフは、追跡されているすべてのプロジェクトの脆弱性の数を表示します。重要度が高い、中程度、低い脆弱性の指標は、そのすぐ下に表示されます。Dependency Trackは、1つまたは複数のソースから既知の脆弱性を取得します。これらの中で最も注目すべきは、アメリカ合衆国の国家脆弱性データベースからの共通脆弱性および露出（CVE）のリストです。各CVEには、未知、低、中程度、重要のレベルが割り当てられています。このリスク分析は、Dependency Trackによって、関連するソフトウェア部品表（SBOM）を入力として、定期的に裏で実行されます。

最大のグラフのすぐ下のセクションでは、ポリシー違反の詳細が示されており、ポリシーは重要だと考えるものに応じて設定されます。特定の依存関係を不要として登録することもできますし、特定のライセンスやライセンスのグループをダッシュボード化し、報告することを義務付けることもできます。このフィードバックメカニズムは、ポリシーごとに設定可能です。

上部のセクションでは、ポートフォリオの脆弱性、リスクのあるプロジェクト、脆弱なコンポーネント、そして時間にわたるリスクスコアが示されています。

さらに、監査の進捗状況、プロジェクトごとの脆弱性の推移、コンポーネントごとの脆弱性の推移など、ビュー、グラフ、統計情報がさらにありますが、代わりにBitBucketがDependency TrackにSBOMを生成して送信する方法に注目しましょう。

BitBucketがSBOMを準備します

SBOMの準備は、BitBucketのCI/CDパイプラインで行われ、プルリクエストがメインブランチにマージされた後に実行されます。これにより、ダッシュボードが常に最新の状態であることが保証されます。

私は、syftをラップし、CycloneDXのSBOMを生成するためのBitBucketのパイプを使用しました。コードとコンテナの調査のためのsyftコマンドにはわずかな違いがあります。

コードスニッフィング

プロジェクトのルートからコードを分析するためのsyftコマンドは次のとおりです：

syft --output cyclonedx-json=code-cdx-sbom.json -v --java-use-network true .

このコマンドは、SBOMをcode-cdx-sbom.jsonというファイルに出力し、インターネットからライセンス情報を取得するためにネットワークを使用します。例えば、中央のMavenリポジトリから取得します。

syft BitBucketパイプはshiftleftcyber（ありがとうございます！）から取得し、BitBucketパイプラインのスクリプトブロックに設定して、次のようにこのsyftコマンドをラップします：

YAML

 

syftプロジェクトのREADMEには、サポートされている言語の印象的な配列がリストされていますが、私はJavaとJavaScriptでのみ使用し、バックログにはPythonプロジェクトがあります。

あなたのコンテナに潜むものは？

レジストリからコンテナをスキャンするには、「docker login」の範囲内で次のコマンドを実行します：

syft --output cyclonedx-json=container-cdx-sbom.json docker.s2c.co.za/container:latest --from registry

対応するBitBucketパイプは：

YAML

 

all-layersスイッチは、syftにコンテナイメージのすべてのレイヤーを検査するよう指示し、最終製品だけでなくすべてを調べます。

BitBucketをデポジットの媒体として

残るのは、Dependency TrackがSBOMを取り込むことだけです。私はSBOMを生成するBitBucketパイプの姉妹パイプを使用しました：

YAML

 

私は三つの入力パラメータを指定しました：

  1. 依存関係トラックインスタンスのURL
  2. SBOMをロードするためのDependency TrackプロジェクトのID
  3. アップロードを許可するAPIキー

プロジェクトIDは、プロジェクト表示から「詳細を表示」をクリックすることで簡単に見つけることができます：

次に、一番下のオブジェクト識別子をコピーします：

APIキーは、左パネルの管理メニューからアクセスできる自動化チームの同じ名前のエントリフィールドにあります：

結論

過去のインシデントから、弱点の悪用はサービスの中断を引き起こし、隣接するシステムや産業にも影響を及ぼす傾向があることが教訓となりました。予期せぬ経費と不便を引き起こします。これに対処するために、開発者やリソースをチームの目標から逸らすことになります。

オープンプロジェクトのライセンスについては、さらに商用化され、組織が過去のライセンス料金を請求されることがあります。一方、要求されることもあります。競争上の優位性を得るために使用されている重要なIPをオープンソース化するように、捕食的なライセンス条件によって。

したがって、各開発者はこれらのリスクに対抗するための積極的な戦略を実装およびサポートする責任があります。BitBucketにコードがある場合、上記で概説したアプローチはシステムをプログラムに準拠させるのに役立ちます。ただし、Dependency Track APIはBitBucketへのアクセスを排他的に制限するものではなく、他のCI/CDパイプラインテクノロジからそれにソフトウェア資材のリストを取得する方法があるはずです。

Source:
https://dzone.com/articles/on-sboms-bitbucket-and-owasp-dependency-track