Black Duck Binary Analysis（BDBA）、Black Duck対応の統合アドオンは、ソフトウェアライブラリ、実行可能ファイル、コードベース内で使用されているベンダー提供のバイナリの、オープンソースのセキュリティ上のリスク、コンプライアンスリスク、品質リスクを識別します。BDBAは、さまざまなファームウェア形式、ファイルシステム/ディスクイメージ、インストール形式、およびさまざまな圧縮およびアーカイブ形式など、幅広いファイルタイプをサポートしています。Black Duck Binary Analysisでは、次のような操作を実行できます。

  • 事実上すべてのコンパイル済みソフトウェア、ファームウェア、モバイルアプリケーションまたは複数のインストーラ形式を、ソースにアクセスすることなく解析する。

  • 埋め込みオープンソースの使用状況と、バイナリ実行可能ファイルとライブラリのリスクを識別する。

  • バイナリの依存関係内で、コードの減衰を管理し、ソフトウェアの品質を向上させる。

  • 以前にスキャンされたバイナリの新たな脆弱性を監視する。

アーキテクチャの概要

Black Duck と統合された BDBA は、次のコンポーネントで構成されており、これらのコンポーネントが連携して Black Duck - Binary Analysis 機能を提供します。


BDBAアーキテクチャ

Black Duck 検出

Black Duck Detectは、Black Duckサーバー上のBDBAコンテナ内にあるBDBAスキャナにバイナリファイルをアップロードします。 Black Duck Detect は、バイナリファイルをスキャンしません。

Tip: スキャンできるバイナリの最大サイズは 100 GB です。

お客様のBlack Duck SCAサーバーに送信されたバイナリファイルは、お客様との契約に従ってBlack Duckによって機密情報として取り扱われます。Black Duckサーバーとのすべての通信は、デフォルトでHTTPSを介して行われます。具体的には、すべてのセッションデータがTLS1.2を使用して暗号化されます。常にお客様のサイトからBlack Duck SCAサービスとの接続を開始します。ホストされているBlack Duck SCAサービスからBlack Duckアプリケーションを呼び出すことはありません。お客様のBlack DuckサーバーにはHTTPS証明書が含まれており、Black Duckアプリケーションが証明書の公開キーを使用してすべての接続リクエストを開始します。

Black Duck Detectは、常にお客様の施設でローカルに実行されます。バイナリは会社のネットワーク環境内に留まり、会社の施設内にあるBlack Duck Binary Analysisコンテナにアップロードされます。

BDBAコンテナ

BDBAスキャナはバイナリファイルをスキャンし、.bdioファイルを生成します。このファイルは、バイナリファイルの署名を含んでおり、Black Duck Webアプリケーションに渡されます。その後、構成表（BOM）を生成します。構成表は、オープンソースコンポーネント/バージョンの詳細を示し、関連するリスク要因（セキュリティ上のリスク、ライセンス上のリスク、運用上のリスク）を提示します。Black Duckスキャン方法も同時に使用すると、バイナリ結果は、BDBA識別を指定するバイナリ一致タイプとともに単一の構成表に統合されます。

スキャンが完了すると、バイナリは直ちに削除されます。

BDBAがコンポーネントを識別する方法

以下の3つの方法を、あらゆるタイプのコンポーネントに適用できます。

  • hashsum：Javaおよびネイティブコンポーネントの場合です。JARファイルのチェックサムを使用し、Maven Centralから既知のコンポーネントを検索します。ファイルのチェックサムを使用し、Linuxディストリビューションに由来するコンポーネントを検索します。

  • signature：ファイルのフィンガープリントを既知のコンポーネントのデータベースと照合します。ネイティブコンポーネント（バイナリにコンパイルされたコード）、.NETバイトコード、Javaバイトコード、Goバイナリで動作します。

  • distro-package-manager：Linuxディストリビューションパッケージマネージャのデータベースから情報を取得し、コンポーネント情報を抽出します。また、.debや.rpmなどの配布パッケージファイルにも対応します。あらゆる言語のコンポーネントにも対応しています。

これらのメソッドのうち、macOSまたはiOSの実行ファイルであるか、またはそれらを含むネイティブコンポーネントに対してのみ使用されるものは次のとおりです。

  • cocoapod-package：ネイティブのObjective-CおよびSwiftバイナリから情報を抽出し、CocoaPodsパッケージマネージャ経由でダウンロードした既知のCocoaPodsプロジェクトと一致させます。CocoaPodsコンポーネントは、MacOSとiOSのアプリケーションから一致されます。

次の3つの一致メソッドは、Javaバイトコードでのみ使用されます。

  • pom：JARファイルの.pomファイルからMavenグループ名とアーティファクト名を使用し、コンポーネントを一致させます。

  • manifest：JARファイルのマニフェストファイルからMavenアーティファクト名を使用し、コンポーネントを一致させます。

  • jar-filename：JARファイル名から取得したMavenアーティファクト名を使用し、コンポーネントを一致させます。

また、言語固有またはプラットフォーム固有のコンポーネントに使用されるメソッドもあります。

  • python-package-manager：Python EggおよびWheelパッケージ内にあるメタデータを使用し、コンポーネントを一致させます。

  • ruby-package-manager：検出されたgemspecファイルを使用し、コンポーネントを一致させます。

  • pe32-fileinfo：バイナリに埋め込まれたWindows PE32メタデータを使用し、コンポーネントを一致させます。Microsoft PEのバージョン情報およびファイル情報の仕様を参照してください

次に、特殊ファイルで宣言されたコンポーネントをインポートするために使用されるメソッドがあります。

  • config-file：.bdba.yaml解析構成ファイル内のコンポーネント定義をスキャンで使用します。

  • sbom：スキャンに存在するSBOMドキュメント内のコンポーネント定義を使用します。

以前は個別のコンポーネントとして表示されていた一部のコンポーネントは、サブモジュールとして表示されるようになり、[モジュールファイル]の下に一覧表示されます。これは現在、.NETコンポーネントに適用されていますが、今後のリリースで拡張される可能性があります。