特許 6672457 ソフトウェア開発のためのソフトウェアリスク制御方法およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6672457

(24)【登録日】2020年3月6日

(45)【発行日】2020年3月25日

(54)【発明の名称】ソフトウェア開発のためのソフトウェアリスク制御方法およびシステム

(51)【国際特許分類】

   G06F 21/57 20130101AFI20200316BHJP

【ＦＩ】

   G06F21/57 370

【請求項の数】20

【全頁数】44

(21)【出願番号】特願2018-522794(P2018-522794)

(86)(22)【出願日】2016年11月10日

(65)【公表番号】特表2019-500676(P2019-500676A)

(43)【公表日】2019年1月10日

(86)【国際出願番号】US2016061312

(87)【国際公開番号】WO2017091360

(87)【国際公開日】20170601

【審査請求日】2018年12月14日

(31)【優先権主張番号】14/951,923

(32)【優先日】2015年11月25日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】518148641

【氏名又は名称】ソナタイプ インコーポレイテッド

【氏名又は名称原語表記】ＳＯＮＡＴＹＰＥ，ＩＮＣ．

(74)【代理人】

【識別番号】100105957

【弁理士】

【氏名又は名称】恩田 誠

(74)【代理人】

【識別番号】100068755

【弁理士】

【氏名又は名称】恩田 博宣

(74)【代理人】

【識別番号】100142907

【弁理士】

【氏名又は名称】本田 淳

(72)【発明者】

【氏名】ジャクソン、ウェイン

(72)【発明者】

【氏名】ハンセン、マイケル

(72)【発明者】

【氏名】フォックス、ブライアン

(72)【発明者】

【氏名】ホワイトハウス、ジェイミー

(72)【発明者】

【氏名】ディロン、ジェイソン

【審査官】 和平 悠希

(56)【参考文献】

【文献】 特開２０１４−２０３３５２（ＪＰ，Ａ）

【文献】 特開２０１３−１１８５１１（ＪＰ，Ａ）

【文献】 特開２００８−２８７３５２（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１２／００９００２５（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１３／０３１１４９６（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ２１／５７

(57)【特許請求の範囲】

【請求項1】

ソフトウェア・リポジトリを含むリポジトリ環境に向けられた不受理の可能性のあるソフトウェア・コンポーネントを制御するコンピュータに実装される方法であって、
ポリシー・ストレージにおいて前記リポジトリ環境に関連付けされた事前規定のリポジトリ・ポリシーであって、リスクと、前記リスクごとに、前記リスクに対して行われるアクションとを定義するとともに、前記リスクに対して行われる前記アクションが、少なくとも、通すアクションおよび通さないアクションから選択されるとともに、事前規定のプログラムに従って行われるステップ（pre-defined programmatic steps）である、前記事前規定のリポジトリ・ポリシーを用意するステップと、
ソフトウェア・コンポーネントに応答して、プロセッサによって、リクエストされた前記ソフトウェア・コンポーネントが前記ソフトウェア・リポジトリに対して新規であるかどうかを判定するステップと、
前記ソフトウェア・コンポーネントが前記ソフトウェア・リポジトリに対して新規ではないと判定されたときに、前記プロセッサによって、前記ソフトウェア・コンポーネントを通すステップと、
前記ソフトウェア・コンポーネントが前記ソフトウェア・リポジトリに対して新規であると判定されたときに、前記プロセッサによって、リスク照合部から、前記ソフトウェア・コンポーネントと一致するリスクを判定するステップと、
前記プロセッサによって、前記ソフトウェア・コンポーネントと一致すると判定された前記リスクを評価して、前記事前規定のリポジトリ・ポリシーで定義されている、前記ソフトウェア・コンポーネントと一致すると判定された前記リスクに対して行われる前記アクションを判定するステップと、
前記プロセッサによって、パスすると判定されたコンポーネントに対して、前記事前規定のリポジトリ・ポリシーで定義された前記通すアクションであって、前記ソフトウェア・コンポーネントの前記リスクが前記事前規定のリポジトリ・ポリシーにパスすると評価された場合には前記ソフトウェア・コンポーネントを前記ソフトウェア・リポジトリに加えることを含む、前記通すアクションを行うステップと、
前記プロセッサによって、不受理の可能性のあるソフトウェア・コンポーネントであるためにパスしないと判定されたコンポーネントに対して、前記ソフトウェア・コンポーネントの前記リスクが前記事前規定のリポジトリ・ポリシーにパスしないと評価されたときに、前記事前規定のリポジトリ・ポリシーで定義された前記通さないアクションを行うステップとを備える方法。

【請求項2】

前記事前規定のリポジトリ・ポリシーが、部分的に一致するソフトウェア・コンポーネントに対して行われる事前規定のアクションをさらに備えるとともに、
前記ソフトウェア・コンポーネントが前記ソフトウェア・リポジトリに対して新規であると判定されたときに、
前記ソフトウェア・コンポーネントが、前記リスク照合部にとって既知の前記コンポーネントのどれとも一致しないことが判定されると、
前記プロセッサによって、前記ソフトウェア・コンポーネント内部の次の層で、前記リスク照合部にとって既知のコンポーネントと一致する内部ソフトウェア・コンポーネントが判定されるまでまたは内部ソフトウェア・コンポーネントのいずれもが既知にならなくなるまで、内部ソフトウェア・コンポーネントの深層検査を反復的に実行するステップと、
既知のソフトウェア・コンポーネントと一致する内部ソフトウェア・コンポーネントに対して、前記リスクを判定する前記ステップを実行するステップと、
既知のソフトウェア・コンポーネントと一致する内部ソフトウェア・コンポーネントのリスクに対して、前記リスクを評価する前記ステップを実行するステップと、
既知のコンポーネントと一致する内部コンポーネントのリスクに対して、前記部分的に一致するソフトウェア・コンポーネントに対して行われる前記事前規定のアクションを行うステップと組み合わせて、前記事前規定のリポジトリ・ポリシーで定義された前記アクションを行うステップを実行するステップとをさらに備える請求項１に記載の方法。

【請求項3】

ユーザアクセスから隔離された検疫ストレージと、前記検疫ストレージのコンポーネントのログとをさらに備えるとともに、
前記プロセッサによって、前記ソフトウェア・リポジトリに格納されずに、検疫ストレージに格納されることにより、前記不受理の可能性のあるソフトウェア・コンポーネントであると判定された前記ソフトウェア・コンポーネントを分離して、前記ソフトウェア・コンポーネントが検疫済みであるという事実を格納するステップと、
前記ソフトウェア・コンポーネントに対するリクエストの受信に応答して、前記プロセッサによって、リクエストされた前記ソフトウェア・コンポーネントが前記検疫ストレージにあるかどうかをさらに判定して、前記ソフトウェア・コンポーネントが検疫済みであると判定されて、前記ソフトウェア・リポジトリ内にはないという検疫通知を行うステップと、をさらに備える請求項１に記載の方法。

【請求項4】

前記ソフトウェア・コンポーネントが検疫済みであると判定されたときに、
前記プロセッサによって、検疫済みコンポーネントの異なるバージョンであって、前記事前規定のリポジトリ・ポリシーにパスする異なるバージョンを判定するステップをさらに備えるとともに、
前記検疫通知が、前記事前規定のリポジトリ・ポリシーにパスした検疫済みコンポーネントの異なるバージョンを表示する、請求項３に記載の方法。

【請求項5】

検疫済みコンポーネントに対して、前記プロセッサによって、検疫済みコンポーネントを放棄されたものとして前記ソフトウェア・リポジトリに受け入れるべきかどうかの判定にユーザを導き、次に、放棄された検疫済みコンポーネントを検疫ストレージからソフトウェア・リポジトリに移すステップをさらに備える請求項３に記載の方法。

【請求項6】

前記リスクの前記判定が、
前記プロセッサによって、前記ソフトウェア・コンポーネントのメタデータに基づいてリスク・ルックアップ・キーを作成するステップと、
前記プロセッサによって、前記ソフトウェア・コンポーネントからの前記リスク・ルックアップ・キーに基づいて、前記ソフトウェア・コンポーネントの前記リスクを表示する情報を検索するステップとを備える請求項１に記載の方法。

【請求項7】

ソフトウェア・コンポーネントに対する前記事前規定のリポジトリ・ポリシーで定義された前記リスクが、前記ソフトウェア・コンポーネントが従属するライセンス、および前記ソフトウェア・コンポーネントのセキュリティ脆弱性を含み、
前記リスクの前記判定が、
前記プロセッサによって、前記ソフトウェア・コンポーネントからのメタデータに基づいて、いずれも前記ソフトウェア・コンポーネントに一意的な、ライセンス・ルックアップ・キーおよびセキュリティ脆弱性ルックアップ・キーを作成するステップと、
前記プロセッサによって、前記ソフトウェア・コンポーネントの前記ライセンス・ルックアップ・キーに基づいて、前記ソフトウェア・コンポーネントの前記ライセンスを表示する情報を検索するステップと、
前記プロセッサによって、前記ソフトウェア・コンポーネントの前記セキュリティ脆弱性ルックアップ・キーに基づいて、前記ソフトウェア・コンポーネントの前記セキュリティ脆弱性を表示する情報を検索するステップとを備える請求項１に記載の方法。

【請求項8】

前記ソフトウェア・コンポーネントが前記ソフトウェア・リポジトリに対して新規であると判定され、前記ソフトウェア・コンポーネントの前記リスクがすべて、エラーなしで前記事前規定のリポジトリ・ポリシーにパスすると評価されたときに行われる前記アクションが、
前記プロセッサによって、前記ソフトウェア・リポジトリに追加されている前記ソフトウェア・コンポーネントをログ記録するステップ、及び
前記プロセッサによって、電子メールを介して、前記新規のコンポーネントを通知するステップ、のうちの１つまたは複数を備える請求項１に記載の方法。

【請求項9】

ソフトウェア・リポジトリと通信するように動作可能なｉ／ｏインタフェースと、
前記ｉ／ｏインタフェースと協働して動作可能であり、かつ、請求項１に記載の方法を実行するように構成されたプロセッサとを備えるコンピュータ。

【請求項10】

請求項１に記載の方法を実行するための実行可能命令を備える非一時的なコンピュータ可読媒体。

【請求項11】

ソフトウェア・リポジトリを含むリポジトリ環境に向けられた不受理の可能性のあるソフトウェア・コンポーネントを制御するコンピュータに実装される方法であって、
ポリシー・ストレージに事前規定のリポジトリ・ポリシーを用意するステップであって、前記事前規定のリポジトリ・ポリシーは、前記ソフトウェア・リポジトリにとって容認できると見なされるリスクと容認できないと見なされるリスクとの一方または両方を定義するとともに、前記リスクごとに、前記リスクに対して行われるアクションであって、少なくとも通すアクションおよび通さないアクションから選択される前記リスクに対して行われるアクションであり、かつ、事前規定のプログラム・ステップであるアクションを定義する、前記事前規定のリポジトリ・ポリシーを用意するステップと、
ソフトウェア・コンポーネントを含む動作に応答して、プロセッサによって、前記ソフトウェア・コンポーネントごとに、リクエストされた前記ソフトウェア・コンポーネントが前記ソフトウェア・リポジトリに対して新規であるかどうかを判定するステップと、
前記ソフトウェア・コンポーネントが前記ソフトウェア・リポジトリに対して新規ではないと判定されたときに、前記プロセッサによって、前記ソフトウェア・コンポーネントを通すステップと、
前記ソフトウェア・コンポーネントが前記ソフトウェア・リポジトリに対して新規であると判定されたときに、
前記プロセッサによって、リスク照合部から、前記ソフトウェア・コンポーネントと一致するリスクを判定するステップと、
前記プロセッサによって、前記ソフトウェア・コンポーネントと一致すると判定された前記リスクを評価して、前記事前規定のリポジトリ・ポリシーで定義されているように、前記ソフトウェア・コンポーネントと一致すると判定された前記リスクに対して行われる前記アクションを判定するステップと、
前記プロセッサによって、前記事前規定のリポジトリ・ポリシーで定義された前記通すアクションを行うステップであって、前記ソフトウェア・コンポーネントの前記リスクが前記事前規定のリポジトリ・ポリシーにパスすると評価されたときに、前記ソフトウェア・コンポーネントを前記ソフトウェア・リポジトリに加えることを含む前記通すアクションを行うステップと、
前記プロセッサによって、施行の段階に対して、前記ソフトウェア・コンポーネントの前記リスクが前記事前規定のリポジトリ・ポリシーにパスしないと評価されたときに、前記事前規定のリポジトリ・ポリシーで定義された前記通さないアクションの組み合わせを行うステップとを備える方法。

【請求項12】

前記事前規定のリポジトリ・ポリシーが、部分的に一致するソフトウェア・コンポーネントに対して行われる事前規定のアクションをさらに含むとともに、前記ソフトウェア・コンポーネントが前記ソフトウェア・リポジトリに対して新規であると判定されたときに、
前記ソフトウェア・コンポーネントが、前記リスク照合部にとって既知の前記コンポーネントのどれとも一致しないことが判定されると、
前記プロセッサによって、前記ソフトウェア・コンポーネント内部の次の層で、前記リスク照合部にとって既知のコンポーネントと一致する内部ソフトウェア・コンポーネントが判定されるまでまたは内部ソフトウェア・コンポーネントのいずれもが既知にならなくなるまで、内部ソフトウェア・コンポーネントの深層検査を反復的に実行するステップと、
既知のソフトウェア・コンポーネントと一致する内部ソフトウェア・コンポーネントに対して、前記リスクを判定する前記ステップを実行するステップと、
既知のソフトウェア・コンポーネントと一致する内部ソフトウェア・コンポーネントの前記リスクに対して、前記リスクを評価する前記ステップを実行するステップと、
既知のコンポーネントと一致する内部コンポーネントのリスクに対して、前記部分的に一致するソフトウェア・コンポーネントに対して行われる前記事前規定のアクションを行うステップと組み合わせて、前記事前規定のリポジトリ・ポリシーで定義された前記アクションを行う前記ステップを実行するステップとをさらに備える請求項１１に記載の方法。

【請求項13】

ユーザアクセスから隔離された検疫ストレージと、前記検疫ストレージのコンポーネントのログとをさらに備えるとともに、
前記プロセッサによって、前記ソフトウェア・リポジトリに格納されずに、検疫ストレージに格納されることにより、前記不受理の可能性のあるソフトウェア・コンポーネントであると判定された前記ソフトウェア・コンポーネントを分離して、前記ソフトウェア・コンポーネントが検疫済みであるという事実を格納するステップと、
前記ソフトウェア・コンポーネントに対するリクエストの受信に応答して、前記プロセッサによって、リクエストされた前記ソフトウェア・コンポーネントが前記検疫ストレージにあるかどうかをさらに判定して、前記ソフトウェア・コンポーネントが検疫済みであると判定されて、前記ソフトウェア・リポジトリ内にはないという検疫通知を行うるステップとをさらに備える請求項１１に記載の方法。

【請求項14】

前記リポジトリ・ポリシーに従って、前記ソフトウェア・コンポーネントが前記不受理の可能性のあるソフトウェア・コンポーネントであると判定されたときに、
前記プロセッサによって、前記不受理の可能性のあるソフトウェア・コンポーネントの異なるバージョンであって、前記事前規定のリポジトリ・ポリシーにパスする異なるバージョンを判定するステップと、
前記ソフトウェア・コンポーネントが容認可能ではないことを表示し、前記事前規定のリポジトリ・ポリシーにパスする前記不受理の可能性のあるソフトウェア・コンポーネントの前記異なるバージョンを表示する通知を行うステップとをさらに備える請求項１１に記載の方法。

【請求項15】

前記不受理の可能性のあるソフトウェア・コンポーネントに対して、前記プロセッサによって、前記不受理の可能性のあるソフトウェア・コンポーネントを放棄されたものとしてビルドまたはコミットに受け入れるべきかどうかの判定にユーザを導き、次に、放棄された前記不受理の可能性のあるソフトウェア・コンポーネントを前記ソフトウェア・リポジトリに移して、前記不受理の可能性のあるソフトウェア・コンポーネントを前記ビルドまたはコミットで用いるステップをさらに備える請求項１４に記載の方法。

【請求項16】

前記リスクの前記判定が、
前記プロセッサによって、前記ソフトウェア・コンポーネントのメタデータに基づいてリスク・ルックアップ・キーを作成するステップと、
前記プロセッサによって、前記ソフトウェア・コンポーネントからの前記リスク・ルックアップ・キーに基づいて、前記ソフトウェア・コンポーネントの前記リスクを表示する情報を検索するステップとを備える請求項１１に記載の方法。

【請求項17】

ソフトウェア・コンポーネントに対する前記事前規定のリポジトリ・ポリシーで定義された前記リスクが、前記ソフトウェア・コンポーネントが従属するライセンス、および前記ソフトウェア・コンポーネントのセキュリティ脆弱性を含み、前記リスクの前記判定が、
前記プロセッサによって、前記ソフトウェア・コンポーネントからのメタデータに基づいて、いずれも前記ソフトウェア・コンポーネントに一意的な、ライセンス・ルックアップ・キーおよびセキュリティ脆弱性ルックアップ・キーを作成するステップと、
前記プロセッサによって、前記ソフトウェア・コンポーネントの前記ライセンス・ルックアップ・キーに基づいて、前記ソフトウェア・コンポーネントの前記ライセンスを表示する情報を検索するステップと、
前記プロセッサによって、前記ソフトウェア・コンポーネントの前記セキュリティ脆弱性ルックアップ・キーに基づいて、前記ソフトウェア・コンポーネントの前記セキュリティ脆弱性を表示する情報を検索するステップとを備える請求項１１に記載の方法。

【請求項18】

前記ソフトウェア・コンポーネントが前記ソフトウェア・リポジトリに対して新規であると判定され、前記ソフトウェア・コンポーネントの前記リスクがすべて、エラーなしで前記事前規定のリポジトリ・ポリシーにパスすると評価されたときに行われる前記アクションが、
前記プロセッサによって、前記ソフトウェア・リポジトリに追加されている前記ソフトウェア・コンポーネントをログ記録するステップ、及び
前記プロセッサによって、電子メールを介して、前記新規のコンポーネントを通知するステップ、のうちの１つまたは複数を備える請求項１１に記載の方法。

【請求項19】

ソフトウェア・リポジトリと通信するように動作可能なｉ／ｏインタフェースと、
前記ｉ／ｏインタフェースと協働して動作可能であり、かつ、請求項１１に記載の方法を実行するように構成されたプロセッサとを備えるコンピュータ。

【請求項20】

請求項１１に記載の方法を実行するための実行可能命令を備える非一時的なコンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本技術分野は、概して、ソフトウェア開発に関し、より具体的には、コンポーネントベースのソフトウェア開発で使用されるソフトウェア・コンポーネント・リポジトリに関する。

【背景技術】

【0002】

約１５年前、ソフトウェア開発者は、オープンソース・ソフトウェアをほとんど使用せずに、ソフトウェアの大部分またはすべてを開発者自身が書く傾向があった。それに比較すると、今日では、アプリケーションを備えるソフトウェア・コンポーネントの大半は、他者によって書かれている。今日のソフトウェア開発の分野では、他者によって作成されたソフトウェア・コンポーネントは、これまでよりもはるかに多く使用されており、この傾向は増加している。

【0003】

その結果、今日の開発者は、事実上、品質に対する責任をオープンソース・コミュニティに委ねている。オープンソース・ソフトウェア・コンポーネントに関する一般に普及している考え方は、多数の開発者がソフトウェア・コンポーネントを見ているのだから、ソフトウェア・コンポーネントは良質に違いないというものである。しかしながら、これは誤った認識である。オープンソース・ソフトウェアには多くの問題があることがある。

【発明の概要】

【発明が解決しようとする課題】

【0004】

さらに、今日の開発者は、彼らが使用しているオープンソース・ソフトウェア・コンポーネントについて認知（visibility）も理解もほとんどしていない。ソフトウェア開発用に利用可能なツールによって、オープンソースを使い易くなっているが、ツールによって、オープンソースおよびその潜在的問題が理解し易くなることはない。認知および理解の欠如をさらに複雑にしているのは、オープンソース領域からのソフトウェアが、他のオープンソース要素に依存する傾向があるという事実である。

【0005】

ソフトウェア・リポジトリは、オープンソースであろうとなかろうと、再利用されたり再利用可能な便利なソフトウェア・コンポーネント集を開発者に提供する既知の技術である。言いかえれば、ソフトウェア・リポジトリは、ソフトウェア開発者が使用するコンポーネントのストレージを提供する。

【0006】

従来のリポジトリ・マネージャは、ソフトウェア・コンポーネントを使用するためのストレージおよび交換の中心点として使用することがある。例えば、従来のリポジトリ・マネージャは、リモート・リポジトリをプロキシし、ローカル・リポジトリにコンポーネントをキャッシュする能力を提供し、リモート・リポジトリからソフトウェア・コンポーネントを繰り返し検索するのに必要な帯域幅および時間を節約する。ローカル・リポジトリをホストする能力は、組織が使用する便利なソフトウェア・コンポーネント集を組織に提供する。それにもかかわらず、ソフトウェア・コンポーネントの認知および理解に関する問題は残っている。

【課題を解決するための手段】

【0007】

そこで、１つまたは複数の実施形態は、コンピュータを提供し、このコンピュータは、ソフトウェア・リポジトリと通信するように動作可能なｉ／ｏインタフェースと、ｉ／ｏインタフェースと協働して動作可能なプロセッサとを含む。プロセッサは、以下のことを実行するように構成されている。

【0008】

ある方法は、ソフトウェア・リポジトリを含むリポジトリ環境に向けられた不受理の可能性のあるソフトウェア・コンポーネント（a potentially unacceptable software component）を制御する。ポリシー・ストレージでは、リポジトリ環境に関連付けされた、事前規定のリポジトリ・ポリシーが提供される。事前規定のリポジトリ・ポリシーは、リスクと、リスクごとに、そのリスクに対して行われるアクションとを定義するとともに、リスクに対して行われるアクションが、少なくとも、通す（pass）アクションおよび通さない（does-not-pass）アクションから選択され、かつ、これらのアクションが事前規定のプログラム・ステップである。ソフトウェア・コンポーネントに対するリクエストの受信に応答して、リクエストされたソフトウェア・コンポーネントがソフトウェア・リポジトリに対して新規であるかどうかが判定される。

【0009】

ソフトウェア・コンポーネントがソフトウェア・リポジトリに対して新規ではないと判定されたときに、ソフトウェア・コンポーネントは通される。
ソフトウェア・コンポーネントがソフトウェア・リポジトリに対して新規であると判定されたときに、リスク照合部から、ソフトウェア・コンポーネントと一致するリスクが判定される。ソフトウェア・コンポーネントと一致すると判定されたリスクを評価して、事前規定のリポジトリ・ポリシーで定義されているように、ソフトウェア・コンポーネントと一致すると判定されたリスクに対して行われるアクションを判定する。パス（合格）すると判定されたコンポーネントに対して事前規定のリポジトリ・ポリシーで定義された通すアクションが行われるが、通すアクションは、ソフトウェア・コンポーネントのリスクが事前規定のリポジトリ・ポリシーにパスすると評価されたときに、ソフトウェア・コンポーネントをソフトウェア・リポジトリに加えることを含む。ソフトウェア・コンポーネントのリスクが事前規定のリポジトリ・ポリシーにパスしないと評価されたときに不受理の可能性のあるソフトウェア・コンポーネントであるためにパスしないと判定されたコンポーネントに対して事前規定のリポジトリ・ポリシーで定義された通さないアクションが行われる。

【0010】

別の実施形態では、事前規定のリポジトリ・ポリシーは、部分的に一致するソフトウェア・コンポーネントに対して行われる事前規定のアクションをさらに含む。ソフトウェア・コンポーネントがソフトウェア・リポジトリに対して新規であると判定され、かつ、ソフトウェア・コンポーネントが、リスク照合部にとって既知のコンポーネントのどれとも一致しないことが判定されたときに、ソフトウェア・コンポーネント内部の次の層で、リスク照合部に知られている既知のコンポーネントと一致する内部ソフトウェア・コンポーネントが判定されるまで、内部ソフトウェア・コンポーネントの深層検査が反復的に実行される。リスクを判定するステップは、既知のソフトウェア・コンポーネントと一致する内部ソフトウェア・コンポーネントに対して実行される。リスクを評価するステップは、既知のソフトウェア・コンポーネントと一致する内部ソフトウェア・コンポーネントのリスクに対して実行される。既知のコンポーネントと一致する内部コンポーネントのリスクに対して、事前規定のリポジトリ・ポリシーで定義されたアクションを行うステップは、部分的に一致するソフトウェア・コンポーネントに対して行われる事前規定のアクションを行うステップと組み合わせて実行される。

【0011】

さらに別の実施形態では、ユーザアクセスから隔離された検疫ストレージと、検疫ストレージのコンポーネントのログと、が提供される。ソフトウェア・コンポーネントは、不受理の可能性のあるソフトウェア・コンポーネントであると判定されるが、ソフトウェア・リポジトリに格納されずに、検疫ストレージに格納されることにより分離され、ソフトウェア・コンポーネントが検疫済みであるという事実が格納される。ソフトウェア・コンポーネントに対するリクエストの受信に応答して、リクエストされたソフトウェア・コンポーネントが検疫ストレージにあるかどうかが判定されて、ソフトウェア・コンポーネントが検疫済みであると判定され、ソフトウェア・リポジトリ内にはないという検疫通知が提供される。

【0012】

さらに別の実施形態では、ソフトウェア・コンポーネントが検疫済みであると判定されたときに、システムによって、検疫済みコンポーネントの異なるバージョンが判定されるとともに、異なるバージョンが事前規定のリポジトリ・ポリシーにパスしたことが知られ、検疫通知が、事前規定のリポジトリ・ポリシーにパスした検疫済みコンポーネントの異なるバージョンをさらに表示する。

【0013】

さらに別の実施形態では、コンポーネントが検疫されたときに、ユーザは、検疫済みコンポーネントを放棄されたものとしてソフトウェア・リポジトリに受け入れるかどうかの判定に導かれ、次に、放棄された検疫済みコンポーネントは、リポジトリ・ポリシーにパスしていないにもかかわらず、検疫からソフトウェア・リポジトリに移される。

【0014】

さらなる実施形態では、リスクの判定は、ソフトウェア・コンポーネントのメタデータに基づいてリスク・ルックアップ・キーを作成するステップと、ソフトウェア・コンポーネントからのリスク・ルックアップ・キーに基づいて、ソフトウェア・コンポーネントのリスクを表示する情報を検索するステップとを含む。

【0015】

さらに別の実施形態では、ソフトウェア・コンポーネントに対する事前規定のリポジトリ・ポリシーで定義されたリスクは、ソフトウェア・コンポーネントが従属するライセンス、およびソフトウェア・コンポーネントのセキュリティ脆弱性を含む。リスクの判定は、ソフトウェア・コンポーネントからのメタデータに基づいて、いずれもソフトウェア・コンポーネントに一意的な、ライセンス・ルックアップ・キーおよびセキュリティ脆弱性ルックアップ・キーを作成するステップと、ソフトウェア・コンポーネントのライセンス・ルックアップ・キーに基づいて、ライセンス・ルックアップ情報プロバイダからソフトウェア・コンポーネントのライセンスを表示する情報を検索するステップと、ソフトウェア・コンポーネントのセキュリティ脆弱性ルックアップ・キーに基づいて、セキュリティ脆弱性情報プロバイダからソフトウェア・コンポーネントのセキュリティ脆弱性を表示する情報を検索するステップとを含む。

【0016】

さらに別の実施形態では、ソフトウェア・コンポーネントがソフトウェア・リポジトリに対して新規であると判定され、ソフトウェア・コンポーネントのリスクがすべて、エラーなしで事前規定のリポジトリ・ポリシーにパスすると評価されたときに行われるアクションは、ソフトウェア・リポジトリに追加されているソフトウェア・コンポーネントをログ記録するステップ、プロセッサによって、電子メールを介して、新規のコンポーネントを通知するステップ、のうちの１つまたは複数を含む。

【0017】

別の実施形態では、ソフトウェア・リポジトリを含むリポジトリ環境に向けられた不受理の可能性のあるソフトウェア・コンポーネントが制御される。ポリシー・ストレージが、リポジトリ環境およびアプリケーションの両方に関連付けされた事前規定のアプリケーション・ポリシーを提供し、事前規定のアプリケーション・ポリシーは、リポジトリに関連付けされたポリシーとは異なり、また、事前規定のアプリケーション・ポリシーは、他のアプリケーションに関連付けされたポリシーとは異なる可能性がある。事前規定のアプリケーション・ポリシーは、リスクと、リスクごとに、そのリスクに対して行われるアクションとを定義するが、リスクに対して行われるアクションは、少なくとも、通すアクションおよび通さないアクションから選択され、かつ、これらのアクションは事前規定のプログラム・ステップである。ソフトウェア・コンポーネントを含むアプリケーションについてアセットをコミットするアクションまたはビルドするアクションに応答して、ソフトウェア・コンポーネントごとに、リクエストされたソフトウェア・コンポーネントがアプリケーションに対して新規であるかどうかが判定される。

【0018】

ソフトウェア・コンポーネントがアプリケーションに対して新規ではないと判定されたときに、ソフトウェア・コンポーネントは通される。
ソフトウェア・コンポーネントがアプリケーションに対して新規であると判定されたときに、リスク照合部から、ソフトウェア・コンポーネントと一致するリスクが判定される。ソフトウェア・コンポーネントと一致すると判定されたリスクを評価して、事前規定のアプリケーション・ポリシーで定義されているように、ソフトウェア・コンポーネントと一致すると判定されたリスクに対して行われるアクションを判定する。パスすると判定されたコンポーネントに対して事前規定のアプリケーション・ポリシーで定義された通すアクションが行われるが、通すアクションは、ソフトウェア・コンポーネントのリスクが事前規定のアプリケーション・ポリシーにパスすると評価されたときに、ソフトウェア・コンポーネントをソフトウェア・リポジトリに加えることを含む。ソフトウェア・コンポーネントのリスクが事前規定のアプリケーション・ポリシーにパスしないと評価されたときに、不受理の可能性のあるソフトウェア・コンポーネントであるためにパスしないと判定されたコンポーネントに対して事前規定のリポジトリ・ポリシーで定義された通さないアクションが行われる。

【0019】

さらなる実施形態は、上記の実施形態のうちの１つまたは複数に従うコンピュータに実装される方法である。
さらに別の実施形態は、コンピュータによって実行するための命令を含む非一時的なコンピュータ可読媒体であり、これらの命令は、上述のコンピュータに実装される方法を含む命令であって、プロセッサでこの方法を実施するための命令である。

【0020】

上記実施形態のうちの１つ、もしくは２つ以上の組み合わせ、またはすべては、組み合わせることも可能であるし、また、単一の実施形態として提供することが可能である。
さらに、前述の要約の目的は、米国特許商標庁および一般大衆、特に特許または法律用語または語法に馴染みのない当技術分野の科学者、エンジニア、および実務家が大まかな閲覧により、本出願の技術的開示の性質および本質を速やかに判定できるようにすることである。この要約は、特許請求の範囲によって判断される本出願の発明を定義するように意図するものでも、いかなる形でも本発明の範囲に関して限定することを意図するものでもない。

【0021】

添付図面では、同じ参照数字は同一のまたは機能的に類似する要素を指し、添付図面は、以下の詳細な説明とともに本明細書に組み込まれて本明細書の一部をなし、添付図面は、様々な例示的な実施形態をさらに図示して、これら実施形態に従って様々な技術的思想および利点を説明するのに役立つ。

【図面の簡単な説明】

【0022】

【図1】従来のリポジトリ環境におけるフローを図示するデータ流れ図である。

【図2】リポジトリ環境用のソフトウェアを制御するためのコンピュータ・システムにおけるフローを図示するデータ流れ図である。

【図3】リポジトリ・ポリシーを用いてコンポーネントを評価する手順を図示するフローチャートである。

【図4】アプリケーション・ポリシーを用いてコンポーネントを評価する手順を図示するフローチャートである。

【図5】動的分析同期モードを図示するフローチャートである。

【図6】動的分析非同期モードを図示するフローチャートである。

【図7】リクエストされたソフトウェア・コンポーネントを提供する手順を図示するフローチャートである。

【図8】アプリケーションをビルドする手順を図示するフローチャートである。

【図9】検疫への、および検疫からのソフトウェア・コンポーネントのフローを図示するデータ流れ図である。

【図10】コンピュータ・システムの該当する部分を図示するブロック図である。

【発明を実施するための形態】

【0023】

Ｉ．序論
概略的には、本開示は、アプリケーションが、ソフトウェア・リポジトリに格納された様々な自己完結型ソフトウェア・コンポーネントを含むソフトウェア開発に関する。このソフトウェア・リポジトリは、様々なアプリケーションをサポートすることが可能であり、開発者はソフトウェア・リポジトリに追加することができ、また、ソフトウェア・コンポーネントは、開発者が使用および再利用するために提供される。ソフトウェア・コンポーネントの潜在的リスクを検出し、それらがリポジトリに流入することを防ぎ、かつ／または、アプリケーションなどに流出すること、または公開されるといったようなことを防ぐ方法が提供される。この方法およびシステムは、リポジトリ・マネージャと連携して有利に作用することができる。事前規定の基準に合格しないソフトウェア・コンポーネントを自動的ブロック、検疫、制限、または通知するためのソフトウェア開発にとって適切なステップを重大な局面で行うことによって、また可能であれば不合格の理由を表示したり、かつ／または容認可能なソフトウェア・コンポーネントを示唆したりすることによって、リポジトリまたはアプリケーションに対して容認できないとすでに見なされたリスクを有するソフトウェア・コンポーネントの消費（流入）および公開（流出）を低減および／または防止することができ、リスクが大きい挙動が劇的に低減され、全体的なソフトウェア開発効率が大幅に向上する。

【0024】

より具体的には、本発明の様々な概念および技術的思想が、新たなソフトウェア・コンポーネントを取得するシステム、デバイス、および方法で具体化されている。この具体化は、組織と新たなソフトウェア・コンポーネントの供給との間に位置し、新たなソフトウェア・コンポーネントが組織に到達する直前に、および／または、ソフトウェア・リポジトリまたはアプリケーションに入り込む可能性があるソフトウェア・コンポーネントがリリースされる直前に、および／または新たなソフトウェア・コンポーネントがそれ以外の方法で組織のソフトウェア・リポジトリ、またはアプリケーションに流布する直前に、それらを評価する。

【0025】

概念は、システムが、リスクを有する可能性があるソフトウェア・コンポーネントを通す、または通さないための任意の基準を確立し、利用できるようにすることである。このようなリスクは、例えば、ソフトウェア・コンポーネントがセキュリティテストまたは精査にパスしたとしても、セキュリティ上の脆弱性を有するかどうかなどのセキュリティ脆弱性、および／またはソフトウェア・コンポーネントによって要求されるライセンスである可能性がある。ソフトウェア・コンポーネントが事前規定のリスクを有する場合、システムは、ソフトウェア・コンポーネントをブロックするなど、不合格に対応したアクション、および／またはリスクのタイプに対応したアクション、または本明細書に記載の他の事前規定のプログラム・ステップを行うことができる。

【0026】

概略的には、１つまたは複数の実施形態は、問題があることに開発者が気付くことがないインバウンドソフトウェア・コンポーネントや、会社または組織のポリシーなどと互換性がないインバウンドソフトウェア・コンポーネントの引き入れに対抗するガードとして機能することができる。アウトバウンド側では、同様のチェックが行われ、アウトバウンドソフトウェア・コンポーネント（リポジトリ内にある場合もある）が、特定のアプリケーションにカスタマイズすることが可能な、確立されたテストに必ずパスしたものとする。ライセンス・リスクの一例として、システムがＡｐａｃｈｅ２．０またはＧＰＬ Ｖ３のライセンスアイテムを許可したくない場合には、それらをブロックすることができる。セキュリティ脆弱性の一例として、ソフトウェア・コンポーネントが低レベルと格付けされた脆弱性を有する可能性があるのに、アプリケーションが重大レベルの脆弱性しかブロックしない場合が考えられる。また、ポリシーは、ある特定の年数を上回るか、または、ある特定の年数を下回るコンポーネントを却下する、またはオープンソース・コンポーネントをすべて却下する、といったようなバリエーションを含むことができる。

【0027】

本明細書でさらに以下で説明するように、本発明の様々な技術的思想およびその組み合わせを有利に用いて、ユーザが自身のシステムにとって適切なポリシーを確立することが可能になり、ユーザは、ある種のリスクを有するコンポーネントを許可し、その他のものを却下することができる。

【0028】

さらに、例示的な実施形態に従って、上述の課題を解決する方法およびシステムが提供される。
ＩＩ．問題提示および観察結果
リポジトリ・マネージャは、ソフトウェア・コンポーネントの任意の数のリポジトリを管理するための機能を提供する。典型的なリポジトリ・マネージャは、２つのプライマリー・フローを有する。

【0029】

第１のフローは、別の上流のリポジトリ（別のリポジトリ・マネージャの一部である場合が多い）のキャッシング・プロキシとして機能する。このフローでは、クライアントは、ローカル・リポジトリからの特定のソフトウェア・コンポーネントをリクエストし、このローカル・リポジトリが、リクエストされたコンポーネントが利用可能かどうかを判定する。利用可能であれば、リポジトリ・マネージャは、クライアントにコンポーネントを提供する。利用可能でなければ、リポジトリ・マネージャは、以前に確立された上流のリポジトリからコンポーネントを取り出し、コンポーネントを（プロキシ・リポジトリで）ローカルにキャッシュし、次に、クライアントにコンポーネントに提供する。

【0030】

第２のフローは、リポジトリ・マネージャのユーザによる、リポジトリ・マネージャ内の特定のストレージ場所に関連付けされた、ホストされたリポジトリへのコンポーネントの公開を可能にする。このフローでは、クライアントは、リポジトリ・マネージャが事前設定された場所にソフトウェア・コンポーネントを格納することをリクエストする。コンポーネントがアップロードされて格納されると、次に、ターゲット・リポジトリは、リポジトリのプロキシ−キャッシュ形式と同様に、他の消費者に対する配布点となることができる。

【0031】

ここで、図１の、従来のリポジトリ環境におけるフローを図示するデータ流れ図を参照する。図１には、クライアントＡ１０１と、クライアントＢ１０３と、第１のフロー１０７と、第２のフロー１０９と、リポジトリ・マネージャ１１１と、プロキシ・リポジトリ１１３と、ホストされたリポジトリ１２１と、ホストされたリポジトリ内のコンポーネントおよびメタデータ１１９と、上流のリポジトリ１０５と、上流のリポジトリ内のコンポーネントおよびメタデータ１１７と、がある。

【0032】

第１のフロー１０７において、クライアントＡ１０１が、リポジトリ・マネージャ１１１からのソフトウェア・コンポーネント（１１７または１１９）をリクエストした。リポジトリ・マネージャ１１１は、リクエストされたコンポーネントがホストされたリポジトリ１２１で利用可能かどうか判定する。リクエストされたコンポーネント１１９がホストされたリポジトリ１２１で利用可能ならば、リポジトリ・マネージャは、コンポーネント１１９をクライアントＡに提供する。リクエストされたコンポーネント１１７がホストされたリポジトリ１２１で利用可能でなければ、リポジトリ・マネージャ１１１は、上流のリポジトリ１０５からコンポーネント１１７を取り出し、コンポーネントを（プロキシ・リポジトリ１１３で）ローカルにキャッシュし、次に、コンポーネント１１３をクライアントＡ１０１に提供する。第１のフローは、キャッシング・プロキシ・フローと呼ばれることがある。これは、おそらく上流のリポジトリ１０５によって配布可能になったサード・パーティの、オープンソース・コンポーネントであるソフトウェア・コンポーネントの典型的なフローである。

【0033】

第２のフロー１０９において、クライアントＢ１０３は、リポジトリ・マネージャ１１１が、ホストされたリポジトリ１２１によって表される事前設定された場所に、ソフトウェア・コンポーネント１１９を格納することをリクエストする。ソフトウェア・コンポーネント１１９がアップロードされて格納されると、次に、ホストされたリポジトリ１１９は、他の消費者、典型的にはホストされたリポジトリ１２１をホストする組織の開発者であって、そこに格納されたコンポーネントをリクエストする可能性がある開発者に対する配布点となることができる。このソフトウェア・コンポーネント１１９は、クライアントＢが開発したコンポーネントであってもよいし、ごく最近では、他の場所を起源とした、アップロードする前にクライアントＢによって自身の開発環境に挿入された、サード・パーティのコンポーネントである可能性が高い。

【0034】

オープンソース・ソフトウェアの使用が大幅に増加する以前は、アプリケーションの作成に使用されるサード・パーティのソフトウェア・コンポーネントの数はわずかであった。加えて、これらのコンポーネントの危険度合は低い場合が多かった。このため、このようなサード・パーティのソフトウェアの品質を概して無視している組織により想定されたリスクは、取るに足らないものであった。しかしながら、オープンソースの使用が増えるにつれて、その変遷パターンは劇的に変化した。例えば、２０００年には、代表的なアプリケーションは、１０％未満のサード・パーティのコンポーネントで構成されていた。２０１５年には、代表的なアプリケーションは、８０％〜９０％のサード・パーティのコンポーネントで構成されている。

【0035】

アプリケーション構成のこの変化は、多大な恩恵をもたらした。なぜなら、ソフトウェア開発者は、オープンソース・ソフトウェアのエコシステムが提示可能な多様な特化および専門知識が活用できるからである。この現在大いにアウトソーシングされているモデルの課題は、品質を検証する最終的な責任が、依然としてオープンソース・コンポーネントを実際に使用しているチームの責任になっていることである。しかしながら、このような検証のための非常に限られたツールが存在するが、重大な局面では言うまでもなく、事前規定のアクションおよび、本明細書に記載のシステムおよび方法が提供する実施可能な改善を用いた品質の自動検証を有するものはない。

【0036】

劣悪な、または欠陥のあるソフトウェア・コンポーネントおよびアプリケーションの使用を防止するという課題に対する共通の対応は、使用されるソフトウェアを人間が手動で見直すことである。開発チームは、コンポーネントの適合性または受容性についての知識がない場合が多い。組織によっては、ソフトウェア・コンポーネントを手動でチェックする大規模な、人的資源による集中的な評価プロセスを有するものもある。

【0037】

現行のアプローチには問題がある。開発者は開発のかなり前に、承認を待つことを余儀なくされるので、大幅な遅滞につながる場合が多く、悪くすると、見直しプロセスを完全に行わない場合もあり得る、開発者任せにつながる可能性がある。ソフトウェア開発のペースが絶えず加速しているので、遅滞をもたらすプロセスは、コスト効率の著しい低下をもたらす場合が多く、最終的に開発を行っている組織の競争上の優位性を弱体化させてしまう。

【0038】

現在機能していないことは、制御が適所にないということであり、しばしば行われることは、セキュリティを施行するために、（上流のリポジトリへのアクセスを禁止して）インターネットからリポジトリを遮断して、開発前に新たなコンポーネントを手動で十分に再検討し、パスしたものをリポジトリ内に入れて、開発者が使用するということである。従来のチェックの使用は面倒であり、様々なワークアラウンドを大量に生み出しているが、最終製品に関するものではない。

【0039】

ＩＩＩ．アプローチの態様
Ａ．概念
前節で説明した問題に対する解決策は、上記課題を解決しながら、ソフトウェア・コンポーネントの認知および理解を高めるものである。本明細書に開示された実施形態は、適切なポイントに自動化の効果的な利用を導入して、ソフトウェア・コンポーネントの中間用途または最終的用途に合わせてカスタマイズされた、サード・パーティおよびオープンソースのソフトウェア・コンポーネントの品質検証プロセスを施行することで、自らが所望するものを使用するといったような、典型的な開発者の行動に適合させながら、遅延および確認誤りを減らす。リポジトリに格納する前に、および／または展開する前にソフトウェア・コンポーネントの属性およびリスクを知ることが可能になったので、本明細書に開示された方法およびシステムは、問題のコンポーネントのために利用可能なデータを用いて、ルールセットを含むユーザ設定可能な、事前規定のポリシーを自動的に処理することができ、開発者によるソフトウェア・コンポーネントの意図した用途に合わせて、事前規定の、ユーザ設定可能なアクションを行う。これにより、その間の開発者によるワークアラウンドの必要を回避しつつ、通常の遅滞および誤りが低減され、開発プロセスの適切なポイントでのコンポーネント選択の不十分な決定が回避されるため、開発効率が大幅に向上する。可能であれば、これらの初期の不十分な決定を回避すると、計画外および予定外の開発作業が大幅に減少される。コンポーネント選択の不十分な決定が回避されたことを確実にするために、他の適切なポイントでチェックを行うことにより、開発プロセスがさらに強化される。

【0040】

状況によっては、開発者がリポジトリからソフトウェア・コンポーネントを検索している場合もある。最終的には、リポジトリは、ソフトウェア開発ファイル・システムとして見直しされるだけの場合もある。このシステムは、リポジトリ・マネージャだけにではなく、開発者がソフトウェアを持ち込むために用いる、リポジトリに匹敵し得るあらゆる方法／システムにも提供することができる。このシステムは、任意の開発者による展開ツールに、もしくはアプリケーションを公開するためのツールに、またはその他の統合されたコンポーネント群に提供することもまた可能である。

【0041】

ソフトウェア開発ライフ・サイクルの状況では、リポジトリ・マネージャは、様々なクライアントおよび開発用のソフトウェア・コンポーネント、ならびにプロキシ−キャッシュ形式のリポジトリだけでなくローカル・ストレージベースのリポジトリ（一般に「ホストされたリポジトリ」とも呼ばれる）とも組み合わせられる場合が多い操作上のツールを提供することができる。リポジトリ・マネージャは開発ライフ・サイクルの中心であるため、適切なソフトウェア・コンポーネントが使用されていることを確認するための便利なコントロールポイントとして使用することができる。

【0042】

Ｂ．アーキテクチャ
ここで、図２の、リポジトリ環境用のソフトウェアを制御するためのコンピュータ・システムにおけるフローを図示するデータ流れ図を参照する。図２は、クライアントＡ２０１と、クライアントＢ２０３と、第１のフロー２０７と、第２のフロー２０９と、ファイアウォールを有するリポジトリ・マネージャ２１１と、プロキシ・リポジトリ２１３と、ホストされたリポジトリ２２７と、随意に検疫ストレージ２２９と、上流のリポジトリ２０５とを図示する。ここではコンポーネントおよびメタデータ２１５によって表されているコンポーネントが、ホストされたリポジトリ２２７に格納されている。ここではコンポーネントおよびメタデータ２３１によって表されているコンポーネントが、上流のリポジトリ２０５に格納されている。

【0043】

第１のフロー２０７では、クライアントＡ２０１が、本明細書でさらに詳述するファイアウォールを含むリポジトリ・マネージャ２１１からのソフトウェア・コンポーネント（２１５または２３１）の従来のリクエストを行う。これは開発環境であるため、ソフトウェア・コンポーネントは標準バージョン、例えば、「ｅｍｂｅｒ−１．１．２−ｎｕｐｋｇ」として指定されていると仮定する。リポジトリ・マネージャ２１１は、リクエストされたコンポーネントがホストされたリポジトリ２２７で利用可能かどうかを判定する。リクエストされたコンポーネント２１５がホストされたリポジトリ２２７で利用可能ならば、リポジトリ・マネージャ２１１は、通常の技術に従ってコンポーネント２１５をクライアントＡに提供する。リクエストされたコンポーネントがホストされたリポジトリ２２７で利用可能でなければ、リポジトリ・マネージャ２１３は、上流のリポジトリ２０５からコンポーネント２３１を取り出す。しかしながら、できる限りコンポーネント２３１をクライアントＡ２０１に提供し、コンポーネントをリポジトリ２２７に保存する前に、リポジトリ・マネージャ２１１は、リスク・データ（ここでは、セキュリティ脆弱性リスク・データ２１９およびソフトウェア・ライセンス・リスク・データ２１７によって表されている）を用いて、コンポーネントのリスクを判定し、コンポーネント２３１が、リポジトリ・ポリシー２２３ですでに確立されている（インバウンドコンポーネントの処置に関する）ルールにパスするかどうかを判定する。コンポーネント２３１がリポジトリ・ポリシー２２３にパスすれば、リポジトリ・マネージャは、通常のステップを行い、例えば、（プロキシ・リポジトリ２１３内で）ローカルにコンポーネントをキャッシュし、次に、コンポーネント２３１をクライアントＡ２０１に提供する。コンポーネント２３１がリポジトリ・ポリシー２２３にパスしなければ、リポジトリ・ポリシー２２３で確立された、パスしないインバウンドコンポーネントを処置するアクションを行うことになる。以下でより詳細に開示するように、このようなステップは、例として提供される以下のうちの、すなわち、コンポーネント２３１がクライアントＡに提供されないようにブロックすること、コンポーネント２３１の不合格の理由をクライアントＡ２０１に通知すること、コンポーネント２３１を検疫ストレージ２２９に移動させること（放棄により、後でホストされたリポジトリに移動させる可能性がある）、容認可能なコンポーネントの代替バージョンを提案すること、コンポーネントの深層検査２２１を実行して、部分的に一致するリスク（例えば、コンポーネント内に含まれているコンポーネントのリスク）を判定すること、部分的な一致ごとに、部分的な一致をブロックすることを繰り返すこと、およびこれらの変形例および組み合わせをできる限りまとめて行うこと、のうちの１つまたは複数とすることができる。結果として、クライアントＡ２０１の観点からすると、コンポーネントのリクエストは、リスクがない限り、従来のリクエストと同じように作用する。さらに、リスクがある場合には、クライアントＡ２０１の開発者には、リポジトリ・ポリシーにパスするコンポーネントを選択するためのオプションおよび情報を提供することができる。

【0044】

第２のフロー２０９において、クライアントＢ２０３は、リポジトリ・マネージャ２１１が、ホストされたリポジトリ２２７によって表される事前設定された場所に、ソフトウェア・コンポーネント２１５を格納することを（通常通り）リクエストする。継続的インテグレーション（ＣＩ）プロセスによって気付くような、アップロードの原因となる理由、またはアプリケーションの完全なビルドや部分的なビルドの理由が他に存在する可能性がある。以下でより詳細に説明するように、リポジトリ・マネージャ２１１は、コンポーネントがリポジトリ・ポリシー２２３ですでに確立されているルールにパスするかどうか、またはコンポーネントがアプリケーションに向けられている場合には、コンポーネントが、アプリケーションに固有の所定のアプリケーション・ポリシー２２５Ａ、２２５Ｂにパスするかどうかを判定する。ソフトウェア・コンポーネント２１５がアップロードされて格納され、かつ／または、アプリケーションがビルドされると、次に、ホストされたリポジトリ２２７は、他の消費者に対する配布点となることができる。しかしながら、できる限りコンポーネントをアップロードする前に、リポジトリ・マネージャ２１１は、リスク・データ（例えば、セキュリティ脆弱性リスク・データ２１９およびソフトウェア・ライセンス・リスク・データ２１７）を使用して、コンポーネントのリスクを判定し、コンポーネントが、特定のアプリケーションに関連付けされたアプリケーション・ポリシー２２５Ａまたは２２５Ｂで（アウトバウントのコンポーネントの処置に関して）すでに確立されているルールにパスするかどうかを判定する。コンポーネント２３１がアプリケーション・ポリシー２２５Ａまたは２２５Ｂにパスすれば、リポジトリ・マネージャ２１１は、通常のステップを行い、例えば、（ホストされたリポジトリ２２７内で）ローカルにコンポーネントを格納し、次に、ビルドまたはコンポーネントをクライアントに利用可能にする。アップロード、またはビルドされているコンポーネントがアプリケーション・ポリシー２２５Ａまたは２２５Ｂにパスしなければ、次に、アプリケーション・ポリシー２２５Ａまたは２２５Ｂで確立された、パスしないアウトバウンドコンポーネントを処置するアクションを行う。以下でより詳細に開示するように、このようなステップは、例として提供される以下のうちの、すなわち、とにかく（内部開発用途に適したものを）ビルドすること、コンポーネント２３１がビルドで使用されたり、アップロードされないようにブロックすること、コンポーネントの不合格の理由をクライアントＢ２０３に通知すること、コンポーネントを検疫ストレージ２２９に移動させる（放棄により、後でホストされたリポジトリ２２７に移動させる可能性がある）、アプリケーション・ポリシー２２５Ａまたは２２５Ｂに容認可能なコンポーネントの代替バージョンを提案すること、コンポーネントの深層検査２２１を実行して、部分的に一致するリスク（例えば、コンポーネント内に含まれているコンポーネントのリスク）を判定すること、部分的な一致ごとに、部分的な一致をブロックすることを繰り返すこと、およびこれらの変形例および組み合わせをできる限りまとめて行うこと、のうちの１つまたは複数とすることができる。

【0045】

リポジトリ・マネージャ２１１およびそのプロキシ・ポジトリ２１３、およびホストされたリポジトリ２２７は、アプリケーションの部分、さらにはそれ自体がアプリケーション全体であるソフトウェア・コンポーネントの部分であるソフトウェア・コンポーネントのための、ローカルの（例えば、高速ネットワーク接続が通信ノード間で利用可能な）ストレージ倉庫として機能することができる。ソフトウェア開発および動作パイプラインの状況では、このローカルな部分の倉庫は、非常に高性能かつ信頼度の高いアプリケーションのビルドを提供し、最終的には、全体の開発効率が大幅に向上する。

【0046】

リポジトリ・マネージャ２１１は、ソフトウェア・コンポーネント（アプリケーションのアセンブリ、およびその結果生じるアプリケーション自体で使用される部分）の共通の出入口ポイントと見なすことができる。それは、不受理の可能性のあるソフトウェア・コンポーネントを制御する方法／システムを統合するための理想なポイントである。

【0047】

ソフトウェア・コンポーネント２１５がリポジトリ２２７内部に格納されると、再評価せず、後で追い出さないようにする方がよい。その理由は、ビルドは、ソフトウェア・コンポーネントがライブラリ内に存在し続けることに依存しており、追い出してしまうと、ビルドが破壊されてしまうおそれがあるためである。追い出すことは可能であるが、追い出すことにより効率が下がり、開発者側に混乱を招くので、適切なやり方ではない。適切なやり方は、ソフトウェアを常に完全にクリーンに保とうとするのではなく、ビルドの時点でコンポーネントを捕捉することである。このシステムでは、ソフトウェア・コンポーネントがリポジトリ２２７に格納されると、ソフトウェア・コンポーネントは、十分にクリーンであるものと仮定する。

【0048】

本方法およびシステムは、リポジトリ・マネージャ２１１内のソフトウェア・コンポーネント、およびリポジトリ・マネージャ２１１からのソフトウェア・コンポーネントに関連付けされた流路（ここでは第１の流路２０７および第２の流路２０９によって表された）に組み込むことができる。

【0049】

Ｃ．リスク、ポリシー、およびアクション
このようなシステムおよび方法は、容認可能であると見なされるリスクおよび見なされないリスク、ならびにパスしないリスクに対して行われるアクションを確定するように事前規定されたポリシー２２３、２２５Ａ、２２５Ｂで具体化されたルールのセット上で機能することができる。例えば、リポジトリ・マネージャ２１１を通してソフトウェア・リポジトリ２１３、２２７を出入りするコンポーネントおよびアプリケーションは、容認可能性について評価することができる。コンポーネントまたはアプリケーションのリスクが容認可能であると見なされたときに、事前規定のポリシーで定義されているように、ある一定の、ユーザ設定可能な、事前規定の（プログラム可能な）アクションを行うことができる。コンポーネントまたはアプリケーションのリスクが容認できないと見なされたときに、やはり事前規定のポリシーで定義されているように、異なるアクションのセットを行うことができるが、これは、容認できないコンポーネントまたはアプリケーションの配信または格納を防止する場合が多い。しかしながら、システムのユーザが所望する動作に応じたアクションが可能である。

【0050】

コンポーネントまたはアプリケーションのリスクが容認可能であると見なされるか否かに応じて事前規定されたアクションを行うことによって、劣悪な、または欠陥のあるソフトウェア・コンポーネントの使用を自動的に防止し、その一方で、間違いの内容、または改善策に関して、開発者に瞬時にフィードバックすることが可能である。

【0051】

これは、非常にスケーラブルな制御形態を提供し、開発コストおよびアプリケーション・ポートフォリオのリスクを劇的に低減し、開発全体および操作上の効率性および開発者の行動を大幅に改善することができる。

【0052】

１．リスク
何らかの理由でリポジトリに入って来るコンポーネントは、自動的に分析され、コンポーネント上で利用可能なリスク・データと照合することができる。リスク・データは、セキュリティ脆弱性、ソフトウェアのライセンスの詳細、および／またはコンポーネントに関連付けされている可能性のあるメタデータからのその他の詳細などのリスクを含む場合がある。

【0053】

本方法とシステムは、既知の技術に従って、コンポーネントのメタデータから、コンポーネントを一意的に識別するために使用される既知の「マーカ」を抽出することができる。コンポーネントの識別を用いて、そのコンポーネントに関連付けされた情報を索引することができる（すなわち、リスクと照合させることができる）。例えば、セキュリティ脆弱性リスク・データ２１９は、コンポーネントの識別と、そのコンポーネントについて（既知であるとして）報告されたセキュリティ・リスクとを関連付けすることができる。別の例として、ソフトウェア・コンポーネントのメタデータは、ソフトウェア・コンポーネントに要求される１つまたは複数のライセンスを列記することができる。または、コンポーネントの識別を用いて、コンポーネントに関連付けされたライセンスを索引することができる。例えば、ソフトウェア・ライセンス・リスク・データ２１７は、コンポーネントの識別と、そのソフトウェア・コンポーネントに賦与されているライセンスとを関連付けすることができる。この例では、プロセスはリポジトリ・マネージャ２１１で実施されるが、リポジトリ・マネージャとは別個の、例えば、データ・サービスとして実施することが可能である。ソフトウェア・コンポーネントに関連付けされたセキュリティ脆弱性を識別するための技術、およびソフトウェア・コンポーネントに関連付けされたライセンスを識別するための技術は既知である。

【0054】

評価するリスクのタイプをセキュリティ脆弱性およびソフトウェア・ライセンスに限定する必要はない。あらゆる任意のデータを既知のコンポーネントに添付することができる。データが添付される場合には、システムはそのデータを評価し、それに対してアクションを行うことができる。セキュリティ脆弱性に関しては、ルールは、ソフトウェア・コンポーネントと一致するとして報告されたセキュリティ脆弱性リスク・データを参照する。ソフトウェア・ライセンスに関しては、ルールは、ソフトウェア・コンポーネントと一致するとして報告されたソフトウェア・ライセンスの詳細を参照する。

【0055】

ソフトウェア開発者は通常、様々なソースのいずれかからソフトウェア・コンポーネントを引き入れる。知られているように、ソフトウェア・コンポーネントは常にメタデータを有する。ソフトウェア・コンポーネントについての一意的な識別子（例えば、本明細書では、ルックアップ・キーとも呼ばれることがあるルックアップ・フィンガープリント）を入力し、フィンガープリントと一致するリスクをフィードバックする表を提供することができる。ソフトウェア・コンポーネントと一致するリスクについてのこの情報は、評価の一部として使用される。ライセンスについては、システムは、コンポーネントを識別し、（例えば、従来の技術を用いたハッシュ値に基づいて）コンポーネントに一意的なフィンガープリントを作成することができるが、これは、そのコンポーネントに関連付けされたライセンスを表示する情報を索引するために用いられるルックアップ・キーである。

【0056】

以下は、セキュリティ脆弱性リスク・データ２１９の単純な、簡略化した例であるが、それは、包括的であることを意図したものではなく、変形例を示唆することを意図したものである。

【0057】

【表1】

以下は、ソフトウェア・ライセンス・リスク・データ２１７の簡略化した例であるが、それは、包括的であることを意図したものではなく、変形例を示唆することを意図したものである。

【0058】

【表2】

オープンソース・プロジェクトは、折り畳まれるべき他のものに依存する傾向があり、したがって、例えば、ＢＳＤ、およびＣＤＤＬ１．０と、任意選択でＣＤＤＬ１．０またはＧＰＬと組み合わされ得るＡＰＡＣＨＥライセンスであってよい。ライセンスの組み合わせを判定し、ソフトウェア・ライセンス・リスク・データ２１７ストレージに格納することができる。

【0059】

ソフトウェア・ライセンス・リスク・データは、ソフトウェア・コンポーネントまたはそのメタデータにおいて直接利用可能である場合が多い。
上記からわかるように、ソフトウェア・コンポーネントはそのリスク・データと一致している。

【0060】

２．ポリシーおよびリスク対アクション
ソフトウェア・コンポーネントと一致するリスクは、コンポーネントの処置を判定するための事前規定の設定可能なルールのセットから以前に準備された、事前規定のポリシーに対して評価される。ソフトウェア・コンポーネントは、ソフトウェア・コンポーネントが一致するリスクに基づいて、容認可能な基準にパスするか、または不合格になると見なすことができる。次に、コンポーネントがパスしたか、パスしなかったかに依存して、次節で説明するように、設定済みの通さないアクション、または通すアクションの所定のセットを行うことができる。

【0061】

設定可能なルールは、ポリシー２２３、２２５Ａ、２２５Ｂに格納することができる。ポリシーは、事前規定のルールに基づいてユーザ設定可能である。ルールは、リスクと、アクションおよび処置とを関連付けする。処置は、通す（パス）、または通さない（パスしない）、とすることができるが、他の処置を提供することも可能である。パスしないコンポーネントについては、システムは、事前規定のプログラム・ステップを行うことができる。これに対し、パスするコンポーネントについては、システムは、通常のプロセスに従って、例えば、コンポーネントを格納したり、アプリケーションをビルドしたり、などすることができる。例えば、コンポーネントに関する既知のメタデータがあれば、既知のセキュリティ脆弱性リスクのリストを提供することができる。ルールは、セキュリティ脆弱性が所定のレベルよりも大きい場合には、コンポーネントは不合格であると仮定する。別の例として、ルールは、ソフトウェア・コンポーネントが特定のソフトウェア・ライセンス（例えば、ＧＰＬ、ＥＧＰＬ）のいずれかと一致する場合には、そのソフトウェア・コンポーネントは合格（あるいは代替的に不合格）とすることができる。これらのルールは、単一のコンポーネントと一致する複数のリスクを処理するように、ポリシーを実施するためにまとめることが可能であり、この場合、後に続くアクションは、最も制限的なアクションである。

【0062】

以下は、例示的なリポジトリ・ポリシーまたはアプリケーション・ポリシーで規定されたルールの単純な例であるが、包括的であることを意図したものではない。

【0063】

【表3】

システムは、コンポーネントがパスしない何らかのリスクを有する場合には、それを通さないように設定することができる。

【0064】

図２の図は、リポジトリ２２３のためのポリシー、および、それぞれの異なるアプリケーションのための異なるポリシー２２５Ａ、２２５Ｂを提供する。アプリケーション・ポリシーは、リポジトリ・ポリシーのサブセットであることが見込まれる。例えば、ＧＰＬコンポーネントはリポジトリ・ポリシーに従ってリポジトリ内に受け入れられる可能性があるが、特定のアプリケーションがＧＰＬに適していない可能性がある。したがって、リポジトリ・マネージャ２１１は、アプリケーション・ポリシーの特定の１つの下ではコンポーネントを通さないが、アプリケーション・ポリシーの異なる１つの下ではコンポーネントを通すことになる。

【0065】

３．通さないアクションのためのポリシーおよびプログラム・ステップ
現代の組織が頻繁にインテグレーションおよびビルドを試みていることで、システムは、アプリケーション（またはアプリケーション内のいくつかのコンポーネント群）が、例えば、ビルドの各ポイントでポリシーにパスするかどうかを頻繁に評価することが可能である。この代わりに、またはこれに加え、システムは、リリースの直前に評価することができる。これらは、開発作業フローの様々なポイントで、それぞれのポイントに対して対応し、かつ、事前設定されたアクションの、場合によっては異なるセットを用いて設定することができる。

【0066】

リポジトリ・マネージャ２１１は、ポリシーを利用して、開発リリースプロセスの様々な段階でポリシーを施行することができる。同じプログラム・ステップを開発リリースプロセスのすべての段階で利用することができる。あるいは、ポリシーは様々な段階で様々なプログラム・ステップを指定することができ、それは異なる施行ポイントであると見なされる。例えば、ポリシーは、施行ポイントのそれぞれで、通さないアクションのためのプログラム・ステップを指定することができる。プログラム・ステップの他の例も実施可能である。この柔軟性により、ポリシーに違反する状況で理想的なアクションを起こすことが可能になり、開発プロセスの制御の効率性および有効性の向上につながる。

【0067】

ポリシーは、通さないアクションのためのプログラム・ステップを指定することができ、これにより、施行の段階とプログラム・ステップとが相互に関連付けされる。以下は、通さないアクションのための事前規定のプログラム・ステップの単純な例であるが、包括的であることを意図したものではなく、変形例を示唆することを意図したものである。

【0068】

【表4】

施行の段階は、例えば、コンポーネントを評価させる開発者環境ツールから判定することができる。例えば、リポジトリ・マネージャからの新たなコンポーネントのリクエストは、施行を「開発する」段階と見なすことができ、評価を開始する継続的インテグレーション（ＣＩ）ツールは、施行を「ビルドする」段階と見なすことができ、内部テストの評価を開始するビルド・ツールは、施行の「段階をリリースする」段階と見なすことができ、アプリケーション・リリースの評価を開始するビルド・ツールは、施行を「リリースする」段階と見なすことができ、以前にリリースされたリリースを再作成する試みはすべて、施行を「操作する」段階と見なすことができる。

【0069】

ユーザは、事前規定のプログラム・ステップおよびそれらの組み合わせを修正することにより、かなり簡単にアクションを設定することができることに留意されたい。プログラム・ステップについてもまた、本明細書でより詳細に説明する。

【0070】

コンポーネントがパスしなかった場合の一般的なアクションの１つは、コンポーネントがユーザに提供されるのをブロックすることであるが、他の事前規定の、ユーザ設定可能なアクションもサポートされている。

【0071】

リポジトリ・マネージャ２１１は、従来、新たな更新されたアプリケーションを公開するために使用されている。動作時には、アプリケーション・ポリシーに不合格であったアプリケーションは、アプリケーションを修正できるように、エラーおよび通知を添付して公開しないようにすることが適切なやり方である。

【0072】

必要ならば、通さないアクションに関して上述したラインに沿って、通すアクションのための事前規定のプログラム・ステップを指定することができる。
４．深層検査
（以前にそのコンポーネントに遭遇していたために）コンポーネントに関してすでに知られているデータに加えて、コンポーネントがまだ知られていない場合などに、すでに知られている、未知のコンポーネント内部のコンポーネントを識別するために、ソフトウェア・コンポーネント内部のソフトウェア・コンポーネントの深層検査２２１を実行することができる。静的なアプリケーション・セキュリティ・テスト（ＳＡＳＴ）および動的なアプリケーション・セキュリティ・テスト（ＤＡＳＴ）などがツールの例である。内部コンポーネントを識別する深層検査については、Ｓｏｎａｔｙｐｅ，Ｉｎｃ．に譲渡された、米国特許第８，８２５，６８９号明細書に開示されている。

【0073】

コンポーネントの「深層検査」２２１に関して、前節の大部分は、既知の標準バージョンのコンポーネントを扱っており、それらは、サプライヤからのオリジナル版をビット単位で複製したものである。しかしながら、開発者がソフトウェア・コンポーネントの一部を変更または修正したことで、元のコンポーネントからわずかに変更されているため、コンポーネントが容易に識別できなくなる場合がある。

【0074】

コンポーネントを識別することができない場合には、深層検査２２１が内部コンポーネントを識別する。例えば、既知の技術を使用して、元のコンポーネントとの類似点を採点することが可能であり、この採点スコアをリポジトリ・ポリシー２２３またはアプリケーション・ポリシー２２５Ａ、２２５Ｂの一部として組み込むことが可能である。言いかえれば、元のコンポーネントと１００％一致しないものがあれば、不合格になる（おそらく、バックドアやトロイの木馬ウイルスが存在する）可能性がある。深層検査は、既知のコンポーネントと同一ではないが、類似したものを対象にしたものである。このように、元のコンポーネントと１００％一致しないコンポーネントは、その元のコンポーネントに適用されている所定のポリシーの下で評価することができる。

【0075】

ポリシーは、部分的に一致するコンポーネントの処理方法を前もって決めることができる。コンポーネントが正確に一致している場合には、コンポーネントが正確に一致しておらず、そのコンポーネントに関して深層検査が実行される場合よりも迅速にポリシーを適用することが可能である。ソフトウェア・コンポーネントに対して深層検査２２１が実行されると、システムは、ソフトウェア・コンポーネントの最外層から開始して、この層のフィンガープリントの識別を試みる。そのフィンガープリントが既知ではない場合には、システムは、この最も外側のコンポーネントから次の内側の層のコンポーネントの中に割り込んで、この、次の内側の層の１つ１つのコンポーネントのフィンガープリントの識別を試みる。コンポーネントが、ある層で識別されると、評価は終了する。その時まで、深層検査２２１は再帰的に続行される。

【0076】

概して言えば、大半のコンポーネントは既知になるが、なかには外れ値もあることが予想される。異なるものが１つ（または複数個）あれば、その時こそ、部分的に一致するアルゴリズムおよび採点が威力を発揮し、その後、識別されるコンポーネントの１つ１つにポリシーが適用されるのである。

【0077】

ソフトウェア・コンポーネントがパスするか、不合格になるのかは、内部コンポーネントについてのリスク・データを合成して判定される。
加えて、ポリシーはそれぞれ、部分的に一致するコンポーネントについて、どれくらい一致していなければならないか、または不合格になるのかを定義することができる。例えば、部分的に一致するコンポーネントが少なくとも８０％一致しない場合には、不合格になる可能性がある。例えば、最外層が一致していると、そのときはそれ以上深く検査する必要はない。なぜなら、システムは、一致したソフトウェア・コンポーネント内の（すべての層の内部コンポーネントを含む）全コンポーネントについての情報をすべて以前に識別したからである。

【0078】

５．検疫
いくつかの実施では、インバウンドであるが、リポジトリ・ポリシー２２３に不合格であったソフトウェア・コンポーネント２３１は、検疫ストレージ２２９に入れておくことが可能であり、ソフトウェア・コンポーネントが検疫されているという事実もまたログなどに格納される。続いて、検疫されたソフトウェア・コンポーネントログに対して、リクエストされたソフトウェア・コンポーネントと照合することができることにより、ユーザが定義したポリシーと照合したり、すでに検疫済みのリクエストされたソフトウェア・コンポーネントを不合格にするために深層検査を行ったりする必要がない。

【0079】

ソフトウェア・コンポーネントがブロックされると、検疫に入れておくことが可能であり、これにより、ユーザは、検疫済みのソフトウェア・コンポーネントをさらに深く評価することが可能になる。いくつかの実施では、ユーザが検疫ストレージ２２９からリポジトリ２２７にソフトウェア・コンポーネントをわざわざ移動させることを含めて、検疫を放棄することができる。これにより、広範な、全般的なポリシーに不合格であったソフトウェア・コンポーネントが、それ自体のメリットによるポリシーに取り込まれていない理由のため、リポジトリに含まれることが可能になる。

【0080】

ＩＶ．コンポーネントおよびフローの詳細な説明
本明細書に開示された全体的な設計により、評価をリポジトリ・マネージャに組み入れることが可能になり、あるいは、他の開発ツールおよび／またはビルド・ツールに組み入れることが可能になる。図３、図４は、（リポジトリへの）インバウンドコンポーネント、および（例えば、アプリケーションへの）アウトバウンドコンポーネントの評価をそれぞれ図示する。図３に関してさらに説明するように、インバウンドコンポーネントは、リポジトリ・ポリシーを用いて評価される。図４に関してさらに説明するように、特定のアプリケーションを意図した一つ以上のアウトバウンドコンポーネントは、アプリケーションに特定のアプリケーション・ポリシーを用いて評価される。図５および図６は、ポリシーに対する分析が、図５におけるように、同時性である（例えば、コンポーネントが評価され、コンポーネントが処置される前にアクションが行われる）か、または、図６におけるように非同期性である（例えば、コンポーネントが評価され、コンポーネントが標準的な処置に従ってすでに処理された後にアクションが行われる）変形例を図示する。図７および図８は、図３のインバウンドフローおよび図４のアウトバウンドのフローがそれぞれ、開発ツールおよび／またはビルド・ツールからどのように開始されるかを図示する。

【0081】

データフローは、本明細書に記載の技術的思想をさらによく理解するための例として、ここに図示されている。実際の実施は、データフローの１つまたは複数の部分を省略することが可能であり、かつ／または、本明細書に記載の範囲および趣旨の範囲内にある他のデータフローを含む場合がある。

【0082】

ここで、リポジトリ・ポリシーを用いてコンポーネントを評価する手順３０１を図示するフローチャートである図３を参照する。図３では、手順３０１は、リスク照合部３２１を含む。リスク照合部３２１において、手順３０１は、評価されるコンポーネントが、リスクの一致について評価されたことがすでにわかっているコンポーネントであるかどうか、すなわち、コンポーネントがリスクについて評価されたかどうかを判定３０５する。

【0083】

コンポーネントがリスクの一致についてすでに評価されたことがわかっていれば（３０５→Ｙｅｓ）、手順３０１は、コンポーネントをリスク・データと照合３１３することを試みる。例えば、コンポーネントのハッシュまたはバイナリ署名は、既知の技術を用いてルックアップ・キーを作成するために使用することができる。次に、ルックアップ・キーに基づいて、リスク（セキュリティ脆弱性および／またはソフトウェア・ライセンスなどの）が存在する場合には、それらはコンポーネントと一致し、判定することができる。メタデータで利用可能なデータはすべて、様々なリスクを判定するために使用可能であることに留意されたい。

【0084】

コンポーネントがリスクと一致することがわかっていなければ（３０５→Ｎｏ）、手順３０１のいくつかの実施形態は、深層検査を含むことができる。評価されているコンポーネント内部のソフトウェア・コンポーネントは、コンポーネントがすでに知られている層まで、層ごとに評価される。深層検査では、手順３０１は、ソフトウェア・コンポーネント内の次の層に、内部コンポーネントが何かあるかどうかを判定３０７することになる。次の層に一つ以上の内部コンポーネントがあれば、評価されているコンポーネント内のコンポーネントを識別するために深層検査が実行される。次の層で識別された一つ以上のコンポーネントは、次に、リスクについて、反復的に評価される。次の層に内部コンポーネントがなければ、評価後、コンポーネントおよびその内部コンポーネント（存在する場合）にまだ遭遇していないので、手順３０１は、評価されているコンポーネントが、不受理の可能性があると表示３０９する。深層検査を介して判定されるコンポーネントのリスクには、このコンポーネント内のコンポーネントのリスクが含まれる。例えば、組織は、軽微な修正を加えてオープンソース・コンポーネントを再ビルドする場合がある。これらの変更により、コンポーネントが標準バージョンと一致しなくなる。このようなことが起こった場合、深層検査を用いて、コンポーネントが既知のコンポーネントに「似ている」かどうかを判定することができる。その類似の度合いに基づいて、採点スコアを割り当てることができる。この採点スコアは、事実上、ルールセットの一部として評価することが可能なコンポーネントに関連付けされた別のデータである。例えば、一部のユーザは、既知のコンポーネントだけが使用可能であるか、または、おそらく部分的に一致するコンポーネント（例えば、８０％、９０％、９９％の一致）はＯＫであると決定するかもしれない。このため、評価のために提出されるコンポーネントはすべて、部分的に一致、正確に一致、または一致しない、のどれかとすることが可能である。「一致状態」は真であるか、または偽であり、「部分的な一致の採点スコア」は、１００％未満のある値を有する。

【0085】

手順３０１が、コンポーネントと一致するリスク（また、深層検査されたのであれば、このコンポーネント内のコンポーネントのリスク）を判定したら、一致したリスクが事前規定のリポジトリ・ポリシーに対して評価３１５され、そのリスクに対して行われるアクションを判定する。リスクがすべてリポジトリ・ポリシーに従って、「パスする」と判定されれば、手順３０１は、次に、事前規定のリポジトリ・ポリシーで定義された通すアクションを行う３１７。リポジトリ・ポリシーにパスしたコンポーネントは、容認可能であると見なされ、通常通りに、リポジトリに追加することができる。リポジトリ・ポリシーにパスしないリスクを有するコンポーネントは、容認できないと見なされ、事前規定のリポジトリ・ポリシー、すなわち、通さないアクションのための任意の事前規定のプログラム・ステップで定義された通さないアクションを行う３１９ことができる。上述したように、随意に、通すアクション、および／または通さないアクションのための事前規定のプログラム・ステップは、開発者ツールの段階に基づいて定義することができる。

【0086】

ここで、アプリケーション・ポリシーを用いてコンポーネントを評価する手順を図示するフローチャートである図４を参照する。図４では、手順４０１は、リスク照合部４１９を含む。リスク照合部４１９において、手順４０１は、評価されるコンポーネントが、リスクの一致について評価されたことがすでにわかっているコンポーネントであるかどうか、すなわち、コンポーネントがリスクについて評価されたかどうかの判定４０３をする。

【0087】

コンポーネントがリスクの一致についてすでに評価されたことがわかっていれば（４０３→Ｙｅｓ）、手順４０１は、コンポーネントをリスク・データと照合４１１することを試みる。例えば、コンポーネントのハッシュまたはバイナリ署名は、既知の技術を用いてルックアップ・キーを作成するために使用することができる。次に、ルックアップ・キーに基づいて、リスク（セキュリティ脆弱性および／またはソフトウェア・ライセンスなどの）が存在する場合には、それらはコンポーネントと一致し、判定することができる。メタデータで利用可能なデータはすべて、様々なリスクを判定するために使用可能であることに留意されたい。

【0088】

コンポーネントがリスクと一致することがわかっていなければ（４０３→Ｎｏ）、手順４０１のいくつかの実施形態は、深層検査を含むことができる。この深層検査は、図３に関して説明したものと同様である。評価されているコンポーネント内部のソフトウェア・コンポーネントは、コンポーネントがすでに知られている層まで、層ごとに評価される。深層検査では、手順４０１は、ソフトウェア・コンポーネント内の次の層に、内部コンポーネントが何かあるかどうかを判定４０５することになり、これが、反復的に評価４０９される。次の層に内部コンポーネントがなければ、評価後、コンポーネントおよびその内部コンポーネント（存在する場合）にまだ遭遇していないので、手順４０１は、評価されているコンポーネントが、不受理の可能性があると表示４０７する。深層検査を介して判定されるコンポーネントのリスクには、このコンポーネント内のコンポーネントのリスクが含まれる。

【0089】

手順４０１が、コンポーネントと一致４１１するリスク（また、深層検査されたのであれば、このコンポーネント内のコンポーネントのリスク）を判定したら、一致したリスクが事前規定のアプリケーション・ポリシーに対して評価４１３され、そのリスクに対して行われるアクションを判定する。リスクがすべてアプリケーション・ポリシーに従って、「パスする」と判定されれば、手順４０１は、次に、事前規定のアプリケーション・ポリシーで定義された通すアクションを行う４１５。アプリケーション・ポリシーにパスしないリスクを有するコンポーネントは、容認できないと見なされ、事前規定のアプリケーション・ポリシー、すなわち、通さないアクションのための任意の事前規定のプログラム・ステップで定義された通さないアクションを行う４１７ことができる。上述したように、随意に、通すアクション、および／または通さないアクションのための事前規定のプログラム・ステップは、開発者ツールの段階に基づいて定義することができる。

【0090】

図５および図６は、ルール評価およびアクションの実行を処理するための、同期モードおよび非同期モードの変形例をそれぞれ図示する。
ここで、図５を参照して、動的分析同期モードを図示するフローチャートについて記載し、説明することにする。同期モードプロセス５０１では、リポジトリ・ポリシーを用いたコンポーネントの評価５０３が実行され、コンポーネントの標準的な処置が発生し得る前に、プロセス５０１は、どちらのアクションを行うべきか（例えば、コンポーネントをブロックするか、または通すか）を判定５０５する。

【0091】

ここで、図６を参照して、動的分析非同期モードを図示するフローチャートについて記載し、説明することにする。非同期モードプロセス６０１では、ソフトウェア・コンポーネントの標準的な処置が実行６０３され、これにより、例えば、リクエストしている下流のクライアントに配信されることになる場合がある。標準的な処置６０３と並行して、または標準的な処置６０３の後のある時点で、評価６０５が実行され、その後、ソフトウェア・コンポーネントのリスクに対応するアクションを判定６０７する。

【0092】

非同期モードの変形例を用いる場合には、コンポーネント（容認可能であっても、または容認可能でなくてもよい）は、標準的な処置の実行６０３を介してリポジトリ・マネージャのユーザに提供することが許可される。次に、非同期的な手順６０１は、リポジトリ・ポリシーを用いてコンポーネントを評価６０５する。評価６０５が完了すると、手順６０１は、コンポーネントがパスしたか否かに基づいて、行うべきアクションを判定６０７する。例えば、アクションは、電子メールなどを介して、ユーザ群に、例えば、すでに配信されたコンポーネントが実際はポリシーに不合格であったことを警報することであってもよい。

【0093】

ここで、リクエストされたソフトウェア・コンポーネントを提供７０１する手順を図示するフローチャートである図７を参照する。図７は、統合開発環境（ＩＤＥ）状況におけるインバウンドコンポーネントのフローを図示する。ＩＤＥの代わりに他の開発ツールを使用することが可能であることが認識されるであろう。図７では、リポジトリ・ポリシーを用いたコンポーネントの評価７１１が、上述した、図３に対応している。

【0094】

リクエストされたソフトウェア・コンポーネントを提供する手順７０１は、例えば、ソフトウェア・コンポーネントに対する開発者のリクエストを受信７０３する開発者が使用する開発ツール、または他の操作上のツールを用いて、開始することが可能であり、指定されるソフトウェア・コンポーネントは、標準（通常は、番号が付された）バージョンである。手順７０１は、開発者のコンポーネントに対するリクエストの結果、そのコンポーネントが入ることになるリポジトリに対して、コンポーネントが新規であるかどうかを判定７０５する。このようなリポジトリは、正式にホストされたリポジトリである場合もあろうし、それほど正式でなく、開発者を対象とした、指定されたソフトウェア・コンポーネント集である場合もあろう。

【0095】

コンポーネントがリポジトリに対して新規でなければ（７０５→Ｎｏ）、手順７０１は、リポジトリ内にあるコンポーネントに対する通常のアクションを行う。例えば、リクエストされたコンポーネントは、リポジトリから検索され、例えば、開発ツールまたは操作上のツールを介して、開発者に渡される。

【0096】

コンポーネントがリポジトリに対して新規であれば（７０５→Ｙｅｓ）、手順７０１は、上流のリポジトリからコンポーネントを入手７０９する。上流のリポジトリからコンポーネントを検索するための技術は既知である。次に、上流のリポジトリから検索したコンポーネントは、コンポーネントが入れられるリポジトリに対して、リポジトリ・ポリシーを用いて評価７１１される。評価７１１の一例が、図３に示されている。リポジトリ・ポリシーを用いた評価７１１は、ポリシーに従ったコンポーネントに対するアクション、すなわち、コンポーネントがポリシーにパスするか、パスしないか、を返信する。

【0097】

コンポーネントがリポジトリ・ポリシーにパスすれば（７１１→コンポーネントはパス）、手順７０１は、リポジトリ内にないコンポーネントに対する通常のステップ７１３を行う。例えば、リクエストされたコンポーネントは、リポジトリに格納され、開発ツールまたは操作上のツールなどを介して、開発者に渡される。

【0098】

コンポーネントがリポジトリ・ポリシーにパスしなければ（７１１→パスしない）、手順７０１は、リポジトリ・ポリシーで事前規定されたプログラム・ステップ７１５を行う。例えば、このようなプログラム・ステップは、以下のうちの１つまたは複数を含む場合がある。すなわち、コンポーネントがリポジトリに格納されないようにブロックする、コンポーネントがパスしないことをリクエスト者に通知する、不合格になった試みおよびコンポーネントについて管理者に通知する、リポジトリ・ポリシーにパスする示唆された代替コンポーネントについてリクエスト者に通知する、等々である。コンポーネントがパスしないという通知は、コンポーネント内で識別されたリスクを含むことが可能であり、使用すべきより良いコンポーネントを判定するのに役立てることができる。いくつかの実施形態では、リクエスト者は、もともとリクエストしたコンポーネントの代わりにリクエストする代替コンポーネントを選択することができる。その場合には、プロセス７０１は、リクエストされたコンポーネントとして代替コンポーネントを評価７０３〜７１９する。手順は、通すアクション、または通さないアクションが行われたときに、終了７１７、７１９する。

【0099】

いくつかの変形例では、手順は、パスしないコンポーネントについてのフィンガープリントのログを格納する。手順は、リポジトリにないコンポーネントが、パスしないコンポーネントについてのフィンガープリントのログにあるかどうかをチェックし、リポジトリ・ポリシーを用いたコンポーネントの評価７１１をスキップすることができ、指定された通さないアクション７１５を行う。

【0100】

パスするフィンガープリントのログは、必ずしも格納しなくてもよい。なぜなら、このようなコンポーネントは、以前にリポジトリに格納されているはずであり、したがって、リポジトリに対して新規にはならないからである。しかしながら、希望する場合には、パスするコンポーネントに相当するログを保存することができる。

【0101】

ここで、アプリケーションをビルドする手順を図示するフローチャートである図８を参照する。図８は、ビルドの状況における一つ以上のアウトバウンドコンポーネントのフローを図示する。ビルドの状況は、例えば、ビルド・ツール、開発ツール、継続的インテグレーション（ＣＩサーバ）などとすることができる。一つ以上のコンポーネントが、公開、リリース、ビルドなど（開発者からのアウトバウンドとして理解される）におけるような、特定のアプリケーションに向けられることを意図した、他の開発ツールを使用することが可能であることが認識されるであろう。図８では、アプリケーション・ポリシーを用いたコンポーネントの評価８０９が、上述した、図４に対応している。

【0102】

アプリケーションをビルドする手順８０１は、例えば、ビルド・ツールもしくは開発ツール、または他の操作上のツールが、アセットをコミットする準備が完了しているか、またはコンポーネントを含むアプリケーション（もしくはアプリケーションの一部）をビルドする準備が完了していることを指示されると、開始することができる。ビルド・ツールまたは開発ツールの好都合な一例が、継続的インテグレーション（ＣＩ）サーバである。アセットをコミットする準備が完了しているか、または、ビルド（もしくは部分的なビルド）で指定されている一つ以上のソフトウェア・コンポーネントは、標準バージョンであり、アプリケーションもまた指定されたバージョンである。手順８０１は、コンポーネントが、それが含まれることになるアプリケーションに対して新規であるかどうかを判定８０５する。コンポーネントは、すでにリポジトリにあっても（または、なくても）よい。コンポーネントは、アプリケーション・ポリシーに基づいたアプリケーションに適切であっても（または、適切でなくても）よい。

【0103】

コンポーネントがアプリケーションに対して新規でなければ（８０５→Ｎｏ）、手順８０１は、アプリケーション内ですでに使用されていたコンポーネントに対する通常のアクション８２１を行う。例えば、最終的な成果物をビルドしたり、アプリケーションに含めたり、などする通常のステップは、開発ツールまたは操作上のツールを介して行われる。

【0104】

コンポーネントがアプリケーションに対して新規であれば（８０５→Ｙｅｓ）、手順８０１は、アプリケーション・ポリシーを用いて、コンポーネントがビルドされることになるアプリケーションについて、コンポーネントを評価８０９する。評価８０９の一例が、図４に示されている。アプリケーション・ポリシーを用いた評価８０９は、ポリシーに従ったコンポーネントに対するアクション、すなわち、コンポーネントがポリシーを通すか、通さないか、を返信する。

【0105】

コンポーネントがアプリケーション・ポリシーにパスすれば（８０９→コンポーネントがパスする）、手順８０１は、そのコンポーネントに対して、例えば、アプリケーションに含まれることになる最終的な成果物をビルドするための通常のステップ８０７を行う。手順８０１は、コンポーネントがまだリポジトリ内になければ、リポジトリ内にもコンポーネントを格納する。

【0106】

コンポーネントがアプリケーション・ポリシーにパスしなければ（８０９→パスしない）、手順８０１は、アプリケーション・ポリシーで事前規定されたプログラム・ステップ８１１を行う。例えば、このようなプログラム・ステップは、以下のこと、すなわち、不合格になったコンポーネントについてユーザに通知すること、随意に、不合格になったコンポーネントをとにかくコミットすること、随意に、リスクについての警告とともにコンポーネントをビルドに含めること、のうちの１つまたは複数を含む場合がある。図７で図示されているように、アプリケーション・ポリシーにパスする示唆された代替コンポーネントおよび／または類似したものについてユーザに通知することもまた可能であり、不合格になったコンポーネントの代わりに、示唆された代替案を選択、使用することもできる。コンポーネントがパスしなかったという通知は、コンポーネント内で識別されたリスクを含むことが可能であり、使用すべきより良いコンポーネントを判定するのに役立てることができる。

【0107】

手順８０１は、ビルド、コミットなどのために評価すべきコンポーネントがさらにあるかどうかを判定８１３する。このような手順は、通常、単一のビルドで複数のコンポーネントを含むか、または、同じアプリケーションに関してコミットする。評価すべきコンポーネントが他にもあれば（８１３→Ｙｅｓ）、手順８０１は、ビルドまたはコミットのための次のコンポーネントを入手８１５し、次のコンポーネントについての評価を繰り返す。

【0108】

ビルド、コミットなどについて評価すべきコンポーネントが他になく８１３、かつ、一つ以上のコンポーネントがすべてパスする場合には、手順８０１は、通常のステップ８１７を行って、指定されたアプリケーションをコミットおよび／またはビルドする。手順８０１は、パスしないコンポーネントがある場合であっても、随意に通常のステップ８１７を行って、指定されたアプリケーションをコミットおよび／またはビルドすることが可能であることに留意されたい。アプリケーション・ポリシーは、不合格になったコンポーネントがある場合には、とにかくビルドすべきか否かを指定することができる。

【0109】

アプリケーションをコミット／ビルドして、最終的な成果物などをビルドする通常のステップのための技術は既知である。コンポーネントがすべて評価された後に、ビルドが行われた（またはスキップされた）ときに、手順は終了８１７する。

【0110】

いくつかの変形例では、手順は、アプリケーション・ポリシーにパスしないコンポーネントについてのフィンガープリントのログを格納する。手順は、アプリケーションに対して新規ではないコンポーネントが、アプリケーション・ポリシーにパスしないコンポーネントについてのフィンガープリントのこのアプリケーションのログにあるかどうかをチェックし、アプリケーション・ポリシーを用いたコンポーネントの評価８０９をスキップすることができ、指定された通さないアクション８１１を行う。

【0111】

アプリケーション・ポリシーにパスするコンポーネントのログは、保持することが可能である。
Ｖ．実施例および変形例
以下の例示的なユースケース、ポリシー管理の例、およびいくつかの変形例は、様々な実施の詳細および利点を実証するのに十分に適している。理解されるように、このシステムは、開発者による不十分な判定を前もって防ぐことができ、また、より優れたウイルス対抗手段を前もって有することにより、開発環境全体にわたるリスク・プロファイルを低減することもまた可能である。

【0112】

Ａ．新たなコンポーネントがポリシーにパスするインバウンドユースケース
開発者が、リポジトリに対して新規であり、開発者には知られていないが、リポジトリ・ポリシーにパスしているコンポーネントをリクエストする例を考える。コンポーネントが新規であり、ポリシーにパスしているという事実は、ソフトウェア開発者にはトランスペアレントである。

【0113】

この例では、本明細書に開示されている本システムおよび方法でリポジトリ・マネージャを使用する環境がすでに存在している。開発者側から見れば、開発者は、例えば、ＩＤＥを介して、以前にこのリポジトリへ検索されていない可能性がある新たなコンポーネントをリクエストし、コンポーネントが（ポリシーにパスするので）開発者に配信される。開発者にとってトランスペアレントなことは、ＩＤＥがリポジトリからのコンポーネントをリクエストし、リポジトリは、そのコンポーネントをローカルに有していないことがわかっており、そのため、リポジトリは、上流のリポジトリから（既知の技術に従って）リクエストされたコンポーネントを入手し、次に、リポジトリがリクエストしている開発者にコンポーネントを提供する前に、本明細書に記載のシステムおよび方法は、リポジトリ・ポリシーを評価し、コンポーネントがパスする場合には、次に、通常は（ポリシーごとに）、リポジトリ・マネージャは、コンポーネントをローカルに格納し、ソフトウェア・コンポーネントをリクエストした開発者にそれを配信することが許可される、ということである。コンポーネントがポリシーにパスする場合、本システムおよび方法は、開発者に完全にトランスペアレントである。

【0114】

それに比較すると、コンポーネントを禁止するブラックリストなどの従来の技術では、開発者には、コンポーネントが以前に承認されたことがないという理由で、コンポーネントの検索が許可されない。おそらく、開発者は、次に、手動によるワークフローをトリガする特定のコンポーネントを許可するようにリクエストするが、これは、通常速度が遅く、自動化されておらず、相応して手動によりアクションを実行しなければならないため、開発効率の著しい低下をもたらす場合が多い。許可が与えられていれば、開発者はコンポーネントを検索することになるが、許可が与えられていなければ、開発者はおそらく、別のバージョンを試みるか、または、おそらくさらに悪いことには、他の手段によってコンポーネントをダウンロードし、無頓着にそれを使用することにより、従来のプロセスを完全に回避しようとするかもしれない。開発者が、手動によるプロセスに違反している可能性があることを理解せずに、単に作業を済ませようとするときに、このような回避をすることは、かなり一般的なことである。

【0115】

Ｂ．新たなコンポーネントがリポジトリ・ポリシーにパスしないインバウンドユースケース
開発者が、リポジトリに対して新規であるコンポーネントをリクエストし、開発者には知られていないが、ソフトウェア・コンポーネントがリポジトリにとって容認できない例を考える。コンポーネントがポリシーにパスしないという事実は、ソフトウェア開発者に速やかに通知され、この例では、通知にはソフトウェア・コンポーネントが不合格である理由が含まれている。

【0116】

この例では、本明細書に開示されている本システムおよび方法でリポジトリ・マネージャを使用する環境がやはりすでに存在している。この例では、リポジトリ・ポリシーは、ＭＩＴライセンスを有するソフトウェア・コンポーネント、または重大なセキュリティ脅威は容認しないが、それ以外のものはすべて容認される。開発者は、ソフトウェア・コンポーネントをリクエストするが、開発者は、このソフトウェア・コンポーネントのライセンスもしくはセキュリティ脅威に、または、ソフトウェア・コンポーネントがソフトウェア・リポジトリ内にある可能性があるかどうかかにさえも、気づいていないか、または関心がない。開発者側から見ると、開発者は、例えば、ＩＤＥを介して、コンポーネントの標準バージョンをリクエストする。開発者は、コンポーネントが、例えば、ＭＩＴライセンスを必要とするため、および重大なセキュリティ脅威があるため、それが容認できないこと（コンポーネントがポリシーにパスしない理由）を通知される。開発者にトランスペアレントなことは、ＩＤＥがリポジトリからのコンポーネントをリクエストし、リポジトリは、上流のリポジトリ（既知の技術に従って）からリクエストされたコンポーネントを入手し、次に、リポジトリがリクエストしている開発者にコンポーネントを提供する前に、本明細書に記載のシステムおよび方法は、リポジトリ・ポリシーを評価し、コンポーネントがパスしない場合には、通常は（ポリシーごとに）、リクエストされたコンポーネントが格納されないようにブロックされ、コンポーネントをリクエストした開発者は不合格について、およびコンポーネントがパスしなかった理由について通知を受ける、ということである。本システムおよび方法は、コンポーネントがポリシーを通らない理由すべてについて開発者に知らせることにより、開発者が、リクエストされたソフトウェア・コンポーネントによって提示されたすべてのリスクをより良好に回避するコンポーネントに関する適切な判断を速やかに下すことができるようにする。

【0117】

それに比較すると、従来の技術では、開発者には、コンポーネントが新規であるという理由で、コンポーネントの検索が許可されない。このとき、開発者は、次に、特定のコンポーネントを許可するようにリクエストする。許可が与えられなければ、開発者は、おそらく別のバージョンを試みるであろう。しかしながら、許可がないことは、不合格の１つの理由を表示する場合がある（し、表示しない場合もある）。開発者が選択した代替バージョンは、１つのリスクを解決することができるかもしれないが、他のリスクが残ることになる。従来の技術は、開発者に対し、許可をリクエストしなくて済む行動を助長するものである。

【0118】

Ｃ．アウトバウンドユースケース−フェールセーフ
通常、開発者は、例えば、図７に関連して説明したように、リポジトリ・マネージャを通してコンポーネントをリクエストすることによりそのコンポーネントを取得する。通常、現在リポジトリに格納されているインバウンドコンポーネントは、以前にリポジトリ・ポリシーにパスしたものである。しかしながら、アウトバウンドコンポーネントを評価し、これにより、おそらくは、１つまたは複数のコンポーネントを事前にブロッキングすることを故意に回避した開発者によって、インバウンド評価が迂回されたコンポーネントに対し、フェールセーフ・モードを提供する。

【0119】

以下の例は、特定のコンポーネントを使用したいが、何らかの理由で、例えば、サムドライブを使用し、ソフトウェア・コンポーネントをバージョン管理システムにコミットすることによって、インバウンド側のリポジトリ・マネージャによって提供される制御を回避する開発者を想定する。この例では、開発者によってコミットされたソフトウェア・コンポーネントは、ＭＩＴライセンスおよび重大なセキュリティ脅威を有する。この例では、ソフトウェア・リポジトリ・ポリシーおよびアプリケーション・ポリシーは、ＭＩＴライセンスを必要とするコンポーネント、または重大なセキュリティ脅威を有するコンポーネントを通さない。

【0120】

コミットされたコンポーネント（ＭＩＴライセンスおよび重大なセキュリティ脅威を有する）を含んでいるコンポーネント集が公開されると、リリースの対象となっているソフトウェアがポリシーに準拠して評価される（アウトバウンドの場合のためのポリシーは、リポジトリ、または組織全体に関連付けすることができる。あるいは、アプリケーションに関連付けすることができるが、必ずしも組織全体に関連付けされなくてもよい）。その結果、アプリケーションがビルドされると、たとえこのコンポーネントが、インバウンドポリシーの評価を免れたＭＩＴライセンスおよび重大なセキュリティ脅威を有していたとしても、とにかくアウトバウンドポリシーに対して評価される。このとき、インバウンドポリシーを免れたコンポーネントは、アウトバウンドポリシーによれば容認可能ではない。通さないアクションについての事前規定のプログラム・ステップによって決められているように、システムは、容認できないコンポーネントについての通知を行い、コンポーネントで見つかったリスクについての通知を行い、リスクを有するビルドについての通知を行い、とにかくビルドを実行し、かつ／またはビルドをブロックすることができる。

【0121】

それに比較すると、従来のシステムでは、ライセンスが容認できないという事実、およびビルドが相応のライセンス脅威を組み込んでいるという事実は、気づいたとしても、アプリケーションがリリースされて知的財産リスクを直ちに顕在化させるまで、気づかれない可能性が高い。

【0122】

Ｄ．アウトバウンドユースケース−典型例
以下は、リリースの対象となっているアプリケーションが存在する場合の、ソフトウェア開発プロセスにおける典型的なシナリオを想定する。開発者がコンポーネントまたはバイナリ・アセットを取得する場合、知られているように、開発者は、概して自らのＩＤＥ（例えば、ＥｃｌｉｐｓｅまたはＩＤなどの統合開発環境）にそれらを引き入れる。開発者は、次に、他のバイナリ・アセットへの依存性を表示する可能性が高いローカルソース・コードの一部を更新する。ある時点において、開発者は、バージョン管理システムにコンポーネントを保存し、コミットできる状態になっている。自動化プロセスがソース・コード内で何かが変更されたことに気づき、そのため、ビルドする必要があり、すべてのテストに必ずパスする必要があることがシステムにわかる、「継続的インテグレーション」（ＣＩ）の技術が既に知られている。ＣＩサーバは、必要な他のすべての関連するソース・コードに加え、開発者によってコミットされたソース・コードを引き入れてすべてをビルドし、これにより、例えば、アプリケーションの一部またはアプリケーションそのもの全体が生成される。ＣＩがソフトウェアの最終的な成果物をビルドする場合を例にとってみる。組織の多くは、リポジトリ・マネージャ内のホストされたリポジトリに新たにビルドされた成果物を引き入れる。ＣＩによるビルドが発生した後の時点で、本明細書に記載のシステムは、図８に関連して説明したように、ビルド・プロセス自体の全体的な出力を行い、評価することができる。つまり、ホストされたリポジトリへ戻されるか、または戻されることになるコンポーネントはすべて、確立されたポリシーに対して再度評価される。

【0123】

Ｅ．コンポーネントがパスしないアウトバウンドユースケース
このシナリオでは、リリースの対象となっているアプリケーションは、アプリケーション・ポリシーにパスしないと判定されたコンポーネントを含む。これは、ソフトウェア開発者にとってほとんどトランスペアレントである。上述したプロセスが後続する。違いは、コンポーネントがアプリケーション・ポリシーにパスしなかったため、ソフトウェア・コンポーネントが不合格であるということである。本明細書に記載のシステムでは、ソフトウェア・コンポーネントがパスしない場合、システムは、リポジトリ・マネージャに命じて、そのコンポーネントを含めることができないことをユーザに知らせ、リクエストされたコンポーネントが不合格である理由（例えば、ある一定の理由によりポリシーに不合格になった）に関してユーザに通知することができる。加えて、システムは、不合格ではないソフトウェア・コンポーネントのバージョンを示唆する（例えば、リクエストされたコンポーネントにセキュリティ脆弱性が存在する場合には、リクエストされたコンポーネントが修正されたバージョンについて開発者に通知する）などして、改善についてユーザに通知することができる。次に、開発者は、システムによって示唆された一つ以上のバージョン、すなわち容認された経路についての通知を指定することができ、したがって、数分以内に問題を確実に解決することができる。

【0124】

Ｆ．アウトバウンドユースケース−新たなアプリケーション・バージョンのリリース
このシナリオでは、アプリケーションの新たなバージョンがリリースされている。そのアプリケーションに関連付けされたアプリケーション・ポリシーが存在し、このアプリケーション・ポリシーは、リポジトリ・ポリシーよりも（例えば、ライセンスおよびセキュリティに関して）具体的である。このため、リポジトリに格納されるコンポーネントは、新たなアプリケーションには容認されない可能性がある。その新たなアプリケーションは、その特定のポリシーに従って、それをリリースする（公開する）べきかどうかについて評価されることになる。いずれかのコンポーネントがパスしない場合には、次に、通さないアクションについてのプログラム・ステップのためのオプションには、公開を拒絶すること、またはアプリケーションがアプリケーション・ポリシーに不合格である理由に関する警告とともに公開すること（それは、アプリケーションが単にテスト環境内にロールインされている状況には適切な場合がある）、および／またはソフトウェアをとにかくリリースすること、のうちの１つまたは複数が含まれる。

【0125】

目標は、リポジトリ上のインバウンド制御を意図的に回避しようとする開発者の行動をシステムが予期し、説明することである。したがって、アプリケーションに含まれることになるアウトバウンドコンポーネントもまた、リポジトリにとって既知であるか、または未知であると識別される。アプリケーション内にあるが、ファイアウォールを通って到達しなかったコンポーネントは、リポジトリにとって未知であると識別される。アプリケーション・ポリシーは、例えば、未知のコンポーネントを容認しないように指定することができ、その場合には、アプリケーションはポリシーに不合格となる。

【0126】

Ｇ．アウトバウンドユースケース−新たなポリシーの下で古いアプリケーションをリリースする
このシナリオでは、古いアプリケーションが、新たな、または更新されたアプリケーション・ポリシーの下でリリースされる。この場合、最終的なビルドが、本明細書に記載の評価をトリガするリポジトリ・マネージャに再び公開される。それに応じて、アプリケーションは、新たな、または更新されたアプリケーション・ポリシーに対して評価される。アプリケーション全体が評価され、アプリケーション全体のコンポーネントがそれぞれ、新たな、または更新されたアプリケーション・ポリシーに対して評価される。しかしながら、アプリケーション内の内部コンポーネントには、以前に（他のアプリケーションに対して）遭遇していたので、リポジトリに対して新規でなく、したがって、リポジトリ・ポリシーに従った評価が迅速であることに留意されたい。

【0127】

Ｈ．ポリシー管理者による使用
このシナリオでは、システムは、本明細書に記載のシステムを有するリポジトリ・マネージャを含む。本明細書に記載のシステムは、リポジトリ・マネージャの物理サーバを用いて、またはおそらく追加のサーバ上で実行することが可能である。リポジトリ・マネージャは、本明細書に記載のシステムに組み込まれるか、または統合されることで、リポジトリ・ポリシーおよびアプリケーション・ポリシーの使用が、（コンポーネントがパスしなくなるまで）開発者にとってトランスペアレントになるようにする。

【0128】

ユーザは、システム管理責任者である可能性が高いが、本明細書に記載のシステムに対する１つまたは複数のポリシーを展開することを望んでいる。ユーザは、おそらく、リポジトリ・マネージャに存在する様々なプロキシ・リポジトリごとに１つずつ、リポジトリ・ポリシーを設定する。ユーザは、コンポーネントが公開されることになる様々なアプリケーションごとに１つずつ、アプリケーション・ポリシーもまた設定する。

【0129】

Ｉ．変形例−ソフトウェア・コンポーネントの検疫
一変形例では、リポジトリ・ポリシーにパスしない、不受理の可能性のあるコンポーネントは、検疫ストレージに格納することができ、検疫ストレージから、ホストされたリポジトリ内に放棄することができる。ここで、検疫への、および検疫からのソフトウェア・コンポーネントのフローを図示するデータ流れ図である図９を参照する。図９は、上流のリポジトリ９０１と、ファイアウォールを有するリポジトリ・マネージャ９０５と、コンポーネントおよびメタデータ９１７が格納されたホストされたリポジトリ９１５と、コンポーネントおよびメタデータ９１１が格納された検疫ストレージならびにログ９０９とを図示する。図９に図示された要素のうちのいくつかは、図２に関して上述したものと同じであり、その詳細についてはさらには説明しない。

【0130】

コンポーネントは、上流のリポジトリ９０１からのインバウンドの形態で表されるように、リポジトリ・マネージャ９０５での評価についてはインバウンドまたはアウトバウンド９０３であるが、アウトバウンドの、したがって、リポジトリ・マネージャ９０５によるストレージについての評価のために到達するコンポーネントのような、任意の他の方法とすることも可能である。ファイアウォールを有するリポジトリ・マネージャ９０５は、ポリシーに準拠して、コンポーネントがパスせず、したがって不受理の可能性のあるソフトウェア・コンポーネントであると判定する、と仮定する。ここで、パスしない、不受理の可能性のあるソフトウェア・コンポーネントは、ホストされたリポジトリ９１５から分離して、すなわち、検疫ストレージ９０９に格納９０７され、検疫ログ９０９が、ソフトウェア・コンポーネント９１１が検疫中であることをログ記録する。このように、ソフトウェア・コンポーネントは、ホストされたリポジトリとは別に格納される。

【0131】

ホストされたリポジトリ９１５内のストレージに、検疫ストレージ９０９に格納された不合格になったコンポーネントおよびメタデータ９１１を移動することができるように、検疫放棄手順９１３が提供される。この状況では、ホストされたリポジトリ・ポリシーは、不合格になったコンポーネント９１７をホストされたリポジトリに格納させる検疫放棄手順９１３によって放棄される。検疫放棄手順９１３は、例えば、コンポーネント内のリスクについて通知することができ、かつ／または、不合格になったコンポーネント９１１がホストされたリポジトリ９１５に格納されることになることを肯定的に表示するようにユーザに要求することができる。検疫放棄手順９１３は、不合格になったコンポーネントは、それ自体のメリットに基づいて評価してもよいが、それらをホストされたリポジトリにとにかく含めることが可能な方法を提供する。

【0132】

Ｊ．変形−改善
ソフトウェア・コンポーネントがポリシーにパスしない、いずれの場合においても、システムは改善を提供することができる。改善が提供されてもソフトウェア・コンポーネントがパスしない状況では、システムは、不合格にならないソフトウェア・コンポーネントのバージョン、例えば、ポリシー（どちらに不合格であったのかに応じて、アプリケーション・ポリシーまたはリポジトリ・ポリシーのいずれか）に不合格にならない、セキュリティ脆弱性が修正されたものなど、同じ名前のソフトウェア・コンポーネントの１つ以上前か後のバージョンを判定することができる。次に、開発者は、システムによって示唆された一つ以上のバージョンが容認されたことを表示することができる。示唆されたバージョンは、ポリシーにパスすることがわかっている。これにより、数分以内で問題を確実に解決する方法が提供されることになる。

【0133】

従来、適用されているポリシーにパスしないコンポーネントに代わって、適用されているポリシーにパスすることがわかっている代替バージョンを示唆することによって、実施可能な改善を提供する開発者ツールは存在しない。

【0134】

ＶＩ．追加の例示的実施
本節は、実施の追加の具体的な例について説明する。図１０は、コンピュータにおける実施を図示する。図３〜図８の手順のうちの１つもしくは複数、または組み合わせは、図１０のコンピュータ上で、または適切に構成された任意の別の装置上で、好都合に実施することができる。

【0135】

ここで、図１０を参照する。コンピュータ・システム１００１の該当部分を図示するブロック図について記載し、説明する。コンピュータ・システム１００１は、１つまたは複数のコントローラ１００３、プロセッサ１００５、ネットワーク１００７などとの通信のための入力／出力（ｉ／ｏ）インタフェース１００９、メモリ１０１１、ディスプレイ１０１５（随意）、および／またはキーボード１０１７などのユーザ入力デバイスを含む場合がある。キーボード１０１７の代わりに、またはキーボードに加えて、ユーザ入力デバイスは、ポインティング・デバイス、キーパッド、コンピュータ・マウス、タッチ・パッド、タッチ・スクリーン、トラックボール、および／または、キーボードといったような、様々な既知の入力デバイスのうちの１つまたは複数を含むことがある。ディスプレイ１０１５は、従来の液晶ディスプレイ（ＬＣＤ）またはその他の画像表示器を介して、および／または可聴メッセージを再生するための従来の可聴デバイス（例えば、スピーカ）を介して、ユーザに情報を提示することができるディスプレイの代表的なものである。コンピュータ・システム１００１の部分は、この分野の当業者はよく理解しており、説明を曖昧にしないようにするために省略されている。

【0136】

プロセッサ１００５は、１つまたは複数のマイクロプロセッサ、および／または１つまたは複数のデジタル・シグナル・プロセッサを含む場合がある。メモリ１０１１は、プロセッサ１００５に結合されている場合があり、読み出し専用メモリ（ＲＯＭ）、読み出し書き込みメモリ（ＲＡＭ）、プログラム可能なＲＯＭ（ＰＲＯＭ）、および／または電気的に消去可能な読み出し専用メモリ（ＥＥＰＲＯＭ）を含む場合がある。メモリ１０１１は、とりわけ、オペレーティング・システム、プロセッサ１００５によって実行されるプログラムのためのデータおよび変量１０３３を格納するための複数の記憶場所を含む場合がある。そのようなプログラムには、以下のうちの、すなわち、事前規定のポリシーの編集、および／または、管理を提供１０３５すること、インバウンドコンポーネントを処理１０３７すること、アウトバウンドコンポーネントを処理１０３９すること、コンポーネントの深層検査１０４１、ポリシーからの通すアクションを行うこと１０４３、ポリシーからの通さないアクションを行うこと１０４５、ソフトウェア開発ツール１０４９、１０５１、１０５３、１０５５、およびプロセッサ１００５によって使用される他の情報および／または命令のためのデータベース１０５７のうちの１つまたは複数を含む場合がある。コンピュータ・プログラムは、例えば、ＲＯＭまたはＰＲＯＭに格納される場合があり、コンピュータ・システム１００１の動作を制御する際にプロセッサ１００５に指図することができる。これらの機能はそれぞれ、本明細書の他のどの個所においても詳述されないという限りにおいて、ここでより詳細に考慮される。

【0137】

キーボード１０１７で表されるユーザ入力デバイスからの手動信号に応答して、メモリ１０１１に格納された命令に従って、および／または、ｉ／ｏインタフェース１００９を介して一定の情報を受信すると自動的に、プロセッサ１００５は、格納されているプログラムの実行を指図することができる。

【0138】

コンピュータ１００１は、１つまたは複数のコンポーネントが格納された、本明細書では一つ以上のコンポーネント１０６９で表されるソフトウェア・リポジトリ１０６７にアクセスすることができる。コンポーネント１０６９は、ネットワーク１００９上でアクセスされるように図示されているが、コンポーネント１０６７は、有線接続および／または無線接続上で、コンピュータ１００１からリモートに、および／またはローカルにアクセス可能である場合もある。コンポーネント１０６９は、データベースまたはソフトウェア・リポジトリ１０６７に限定する必要はない。ソフトウェア・リポジトリ１０６７、例えば、ホストされたリポジトリ、プロキシ・リポジトリ、上流のリポジトリなどに位置するコンポーネントにアクセスするための技術は既知である。

【0139】

プロセッサ１００５は、ここでは事前規定のポリシー１０７１で表される、事前規定のポリシーの編集、および／または管理を提供１０３５するようにプログラムすることができる。上記でより詳細に説明したように、事前規定のポリシーはリスク、およびリスクに対して行われるアクションを定義する。事前規定のリポジトリ・ポリシーがソフトウェア・リポジトリ１０６７に対して提供されることが見込まれ、２つ以上のリポジトリが存在する場合には、リポジトリのそれぞれに対して事前規定のリポジトリ・ポリシーが存在する。リポジトリ・ポリシーは、リポジトリ内で容認可能なリスクを定義し、リポジトリに含まれるコンポーネントは、リポジトリ・ポリシーに準拠していることが見込まれる。ソフトウェア・リポジトリ１０６７がコンポーネントを供給するアプリケーションのうちの１つまたは複数に対して、事前規定のアプリケーション・ポリシーが提供されることが見込まれる。２つ以上の異なるアプリケーションに対して、異なるアプリケーション・ポリシーが存在する場合がある。事前規定のリポジトリ・ポリシーおよびアプリケーション・ポリシーについては、上記でより詳細に説明している。事前規定のポリシー１０７１は、リスクと、各リスクに対して遂行１０２１するべき通すアクションまたは通さないアクションとの間の対応関係を表示する情報、すなわち、アクションのために行う情報表示のプログラム・ステップ１０２３であって、随意で、事前規定のポリシーにアクセスすることになる施行の段階に特有の情報表示のプログラム・ステップと、随意で、コンポーネントが部分的にのみリスクと一致する場合に、すなわち、コンポーネントの内部コンポーネントに対してのみリスクが知られている場合に行われる部分的一致アクション１０２５とを含む場合がある。

【0140】

ポリシーは、ここでは単一の事前規定のポリシー１０７１で表されているが、例えば、ディスプレイ１０１５を介して選択可能なプログラム・ステップを表示すること、および、キーボード１０１７を介して入力を受信することなどによって、ユーザとの対話を介して、コンポーネントが評価される前に、指定、編集、および／または管理することができる。通さないアクションのために、および随意に通すアクションのために行われると定義されるプログラム・ステップは、例えば、アクション・ストレージごとにプログラム・ステップ１０２３で格納することができる。事前規定のポリシーは、ユーザとの対話を介して、複数のリスクのそれぞれについて、リスクがポリシーにパスするか、または不合格になるかを表示するアクション、例えば、パスまたは不合格を定義することができる。リスク対アクション・テーブルは、リスク対アクション・テーブル１０２１に格納することができる。コンポーネントのルックアップ・キー対リスクストレージ１０１９は、（有利なことに、フィンガープリントとして示される）コンポーネントに関する情報、およびコンポーネントが有することがわかっている、セキュリティ脅威、セキュリティ脅威のレベル、ライセンスなどのようなリスクを格納することができる。様々な種類のリスクに対して、様々なストレージ１０１９、例えば、セキュリティ・リスクのための様々なストレージ、およびライセンス・リスクのための様々なストレージを提供することができる。コンポーネントのフィンガープリント対リスクストレージに表示されていないコンポーネントに遭遇した場合には、一つ以上のリスクに関する情報は、既知の技術を介して取得することができる。例えば、コンポーネントは、セキュリティ脅威の確定したレベルまで走査することができるし、また、生成されたこのような情報は、コンポーネントのルックアップ・キー対リスクストレージ１０１９に追加することができる。いくつかの実施では、コンポーネントのルックアップ・キー対リスクストレージ１０１９からの情報は、情報提供サービスによって提供することができる。

【0141】

ルックアップ・キーを生成するための技術は既知である。その一例は、任意のハッシュ関数技術である。よく知られているハッシュ技術には、ＳＨＡ−１、ＭＤ５など多数が含まれ、可変長の入力データセットをマップし、ハッシュ値、ハッシュ・コード、ハッシュ・サム、チェック・サムまたはハッシュと呼ばれる場合がある小さなデータセットを出力する。同じ技術を用いて、評価されているファイルと、それが比較される既知のファイルをハッシュする限り、特定のハッシュ関数は重要ではない。任意の既知の技術または開発予定の技術を用いて、ハッシュ値を比較し、一致するハッシュ値を見つけようと試みることができる。

【0142】

プロセッサ１００５は、インバウンドコンポーネントを処理１０３７するようにプログラムすることができる。例えば、リクエストされたコンポーネントがリポジトリに対して新規であるかどうかを判定することが可能である。すでにリポジトリ内に存在するコンポーネントについては、通常通りに、リクエスト者に対してコンポーネントを通すことができる。リポジトリに対して新規であるコンポーネントについては、コンポーネントのリスクを（コンポーネントのルックアップ・キー対リスクストレージ１０１９の参照などによって）判定することができ、コンポーネントに対して行われるアクションを判定するリポジトリ・ポリシーに従って、リスクを評価することができる。これについては、上記でより詳細に説明している。

【0143】

プロセッサ１００５は、１つまたは複数のアウトバウンドコンポーネントを処理１０３９するようにプログラムすることができる。動作時に、ビルドまたはアプリケーションに１つのコンポーネント、またはともに使用することが意図されたコンポーネント群が存在する場合がある。例えば、これらのコンポーネントのそれぞれについて、コンポーネントがアプリケーションに対して新規であるかどうかを判定することができる。アプリケーションに対して新規ではないコンポーネントについては、コンポーネントは通常通りに処理されることになる。アプリケーションに対して新規であるコンポーネントについては、コンポーネントのリスクを（コンポーネントのルックアップ・キー対リスクストレージ１０１９の参照などによって）判定することができ、そのアプリケーションに適した、コンポーネントに対して行われるアクションを判定するアプリケーション・ポリシーに従って、リスクを評価することができる。これについては、上記でより詳細に説明している。

【0144】

加えて、いくつかの実施では、アプリケーションに対して新規であると判定された一つ以上のアウトバウンドコンポーネントについて、プロセッサは、インバウンドコンポーネントとしてコンポーネントを処理するようにプログラムすることができる。すなわち、アウトバウンドコンポーネントとしてコンポーネントを処理した後に、プロセッサは、インバウンドプロセッサにコンポーネントを提出し、次に、（コンポーネントがパスした場合には）それらをリポジトリ・ストレージに格納することができる。実際上、アプリケーション・ポリシーにパスした大部分またはすべてのアウトバウンドコンポーネントは、リポジトリ・ポリシーもまたパスすることが見込まれる。なぜなら、アプリケーション・ポリシーは少なくともリポジトリ・ポリシーと同程度に制限的であり、リポジトリ・ポリシー内のすべてのリスクを指定することが見込まれるからである。しかしながら、リスクがリポジトリ・ポリシーで指定されたリスクと重複するだけのアプリケーション・ポリシー、またはリポジトリ・ポリシーとはまったく異なるアプリケーション・ポリシーを作成することが可能である。

【0145】

プロセッサ１００５は、コンポーネントの深層検査１０４１のためにプログラムすることができる。深層検査では、コンポーネント内の内部コンポーネントが、層ごとに判定され、内部コンポーネントのリスクが判定される。その後、全体としての内部コンポーネントのリスクは、最も外側のコンポーネントのリスクとして使用することができる。ほとんどの実施形態では、深層検査１０４１（実行される場合）は、システムにとって既知のコンポーネントに対してのみ実行されることになる。すなわち、コンポーネントのフィンガープリントは、コンポーネントのルックアップ・キー対リスクストレージ１０１９内にはなく、深層検査は、内部コンポーネントが既知になるまで、または、内部コンポーネントのいずれもが既知にならなくなるまで、未知の内部コンポーネントについて反復的に実行される。コンポーネント内の内部コンポーネントを検査する例は、例えば、「未知のソフトウェア・コンポーネントを既知のソフトウェア・コンポーネントに一致させるための方法およびシステム」と題する米国特許第８，８２５，６８９号明細書に記載されている。このようなコンポーネントは、部分的に一致するコンポーネントであり、内部コンポーネントのリスクは、外部コンポーネントのリスクとして用いられる。既知の技術を用いて、部分的に一致するコンポーネントには、例えば、９９％、８０％、７５％、などのように、一致の程度に関する値を割り当てることができる。一つ以上のポリシーは、「部分的に一致するコンポーネント」に対して行う部分的一致アクション１０２５を指定することができ、例えば、部分的に一致するコンポーネントは、少なくとも９０％の一致でなければならず、そうでなければ、パスしない。この点については、上記でより詳細に説明している。

【0146】

プロセッサ１００５は、ポリシーからの通すアクションを行う１０４３ようにプログラムすることができる。リポジトリ・ポリシー、または適用されるアプリケーション・ポリシーに従って、コンポーネントが（例えば、リスクがないことにより）パスすると判定された場合、次に、アクションごとのプログラム・ステップ１０２３がストレージから検索される。上述したように、プログラム・ステップは、開発者ツールのどれを利用するかによって判定または推論することが可能な施行の段階、または、コンポーネントがインバウンドまたはアウトバウンドになったときに指定することが可能な施行の段階を考慮に入れてもまたよい。パスしたコンポーネントのためのプログラム・ステップは通常、開発者ツールが通常通りに機能できるように、（リポジトリにコンポーネントを格納することを含め）コンポーネントを通常通りに通すことである。例えば、特定のコンポーネントが特定のポリシーにパスしたことを通知するか、またはログ記録することなど、ユーザが選択可能な他のアクションを提供することができる。

【0147】

プロセッサ１００５は、ポリシーからの通さないアクションを行う１０４５ようにプログラムすることができる。リポジトリ・ポリシー、または適用されるアプリケーション・ポリシーに従う少なくとも１つのリスクにコンポーネントがパスしないと判定されると、アクションごとのプログラム・ステップ１０２３は、随意に、施行の段階に対応するものとして、ストレージから検索される。パスしないコンポーネントに対するプログラム・ステップは、アプリケーション・ポリシーまたはリポジトリ・ポリシーごとに指定された通りに行われる。

【0148】

プロセッサ１００５は、ソフトウェア開発ツール１０４９、１０５１、１０５３、１０５５を用いてプログラムすることができる。当技術分野で理解されているように、ソフトウェア開発ツールは、本明細書では、リポジトリ・マネージャ１０４９、既知の開発環境（例えば、ＩＤＥ）１０５１、従来のビルド／リリース・ツール（例えば、ＣＩツール）１０５３、およびソフトウェア・リポジトリを使用するその他の典型的な雑多な開発ツール１０５５で表されている。リポジトリ・マネージャ１０４９は、上述した新規な機能に組み込むことができる。メモリ１０１１は、通常の一時ストレージ、および本明細書では考慮していない他のプログラムのための他の命令とともに、雑多なデータベース１０５７に他の雑多な情報を含むこともまた可能である。

【0149】

コンピュータ１００１は、１つまたは複数のディスク・ドライブまたは取り外し可能なストレージ（図示せず）を収容することができる。典型的には、これらは以下の、すなわち、フラッシュ・メモリ、フロッピー・ディスク・ドライブ、ハード・ディスク・ドライブ、ＣＤ ＲＯＭ、デジタル・ビデオ・ディスク、光ディスク、および／または、ＵＳＢメモリ・スティックなどの取り外し可能なストレージ・デバイス、これらの変形および発展形、のうちの１つまたは複数とすることができる。ドライブおよび取り外し可能なストレージの数およびタイプは、典型的には様々なコンピュータの構成に応じて、様々であってもよい。ディスク・ドライブは任意選択としてもよく、スペースを考慮して、本明細書に記載のプロセスに関連して使用されるコンピュータ・システムから省略してもよい。コンピュータは、ＣＤ−ＲＯＭ読み取り装置およびＣＤ記録装置を含んでもまたよい。それらは、バス構造およびプロトコル（図示せず）によってサポートされる他の周辺デバイスとともにバスで相互接続することが可能である。バスは、コンピュータの他のコンポーネントを相互接続する主要な情報ハイウェイとしての機能を果たすことができ、インタフェースを介してコンピュータに接続することができる。ディスク・コントローラ（図示せず）は、ディスク・ドライブをシステム・バスにインタフェースすることができる。これらは内部にあってもよいし、外部にあってもよい。プロセッサ１００５、メモリ１０１１、ディスク・ドライブおよび／または取り外し可能な記憶媒体は、「コンピュータ可読記憶媒体」と呼ばれ、コンピュータ・プログラムおよびデータの非一時的な記憶を提供する。

【0150】

図１０は、機能またはリソースの論理的なグループ分けに関して記載されていることを理解されたい。これらの論理的なグループ分けの１つまたは複数は、１つまたは複数の実施形態から省略してもよい。例えば、深層検査１０４１の機能、および事前規定されたポリシーを提供／編集、および／または管理すること１０３５は、省略すること、および／または異なるプロセッサ上で実行することが可能である。同様に、範囲から外れることなく、機能を別のやり方でグループ分け、組み合わせ、または増補することができる。同様に、本明細書は、様々なデータベースまたは、データおよび情報集について説明することができる。データまたは情報の１つまたは複数のグループ分けは、範囲から逸脱することなく、省略、分散、組み合わせ、または増補してもよいし、ローカルに、および／またはリモートに提供することができる。

【0151】

ＶＩＩ．用語解説
本明細書で使用される用語は、最初に、ソフトウェア・リポジトリの当業者が理解するような第１のレベルで解釈され、第１のレベルで解釈可能でなければ、次に、ソフトウェア開発をサポートし管理するツール科学の当業者が理解するような第２のレベルで解釈され、第１のレベルおよび第２のレベルで解釈可能でなければ、コンピュータ科学の当業者が理解するような第３のレベルで解釈され、そして、第１のレベル、第２のレベル、および第３のレベルに従って解釈可能でなければ、一般的な辞書に従って解釈されることを意図している。

【0152】

特許請求の範囲は、以下の用語を使用することができる。これらは、本明細書の特許請求の範囲の目的で、以下の意味を有すると定義される。他の定義を本明細書で指定する場合がある。

【0153】

本明細書で使用される「バイト・コード」という用語は、入力プログラミング言語を翻訳することによって生成された中間的な操作上のコードを意味すると定義され、バイト・コードは、仮想機械が実行するハードウェアの在来の機械コードとは独立した、独自の命令セットを有する仮想機械によってバイト・コードが実行されたときに、解釈することができる。「バイト・コード」を使用するコンピュータ言語には、限定ではなく例として、Ｊａｖａ、ＮＥＴ、Ｓｃａｌａ、ｊｙｔｈｏｎ、ｇｒｏｏｖｙ、およびＰａｓｃａｌが含まれる。

【0154】

本明細書で使用される「コンポーネント」という用語は、先在する実行可能なソフトウェアの特定のバージョン（標準バージョンと呼ばれる場合もある）、または、いつでも使用可能な完全なスタンド・アローンの完成品ではない、バイト・コードまたはランタイムに実行可能なコードである、再利用可能な先在する自己完結型のソフトウェア・コード・ビルディング・ブロックであると定義され、コンポーネントは、ライセンス、またはセキュリティ脆弱性の標的といったような、リスクの対象になる可能性がある。よりくだけた言い方をすると、スタンド・アローン製品の一部であるコンポーネントは、開発者がスタンド・アローン製品の一部として自分自身で書きたくないコードの自己完結型のビットであると理解することができ、したがって、開発者は、別のスタンド・アローン製品の一部として機能が前もって詳しく調査された可能性が高い、以前から存在するコンポーネントを使用する。

【0155】

コンポーネントは、複数の入れ子型コンポーネント自体を含むことができる。例えば、ＷＡＲコンポーネントとしてパッケージされたＪａｖａウェブ・アプリケーションは、様々なＪＡＲコンポーネントおよびＪａｖａＳｃｒｉｐｔライブラリを含む場合があり、これらはそれぞれ、コンポーネントそのものである。

【0156】

本明細書で使用される「コンピュータ・システム」または「コンピュータ」という用語は、コンピュータ、ラップトップ、パーソナル・コンピュータ、タブレット・コンピュータ、ハンドヘルド・コンピュータ、スマートフォン、個人用携帯情報端末、ノート型コンピュータ、個人用割り当てパッド、サーバ、クライアント、メインフレーム・コンピュータ、ミニコンピュータと呼ばれることもあるデバイス、またはその発展形および等価物を表す。

【0157】

「オープンソース」ソフトウェアは、本明細書では、ソースを取得する、よく知られた、索引付けされた手段を用いて、随意に、修正作業および派生した作業を許可するライセンスを用いて、ソース・コードとしての配布だけでなく、コンパイルされた形式としての配布もまた可能にするソース・コードであると定義される。

【0158】

本明細書で使用される「リポジトリ」または「ソフトウェア・リポジトリ」という用語は、ソフトウェア・ビルド・コンポーネント（「成果物」と呼ばれることもある）、および後の検索のための依存関係を格納する電子記憶システムを意味すると定義され、この分野の当業者によく知られた手順に従って成果物がリポジトリに公開されることにより、あるソフトウェア開発者によって作られた成果物が、他のソフトウェア開発者がさらなる使用に利用できるように、実行可能なソフトウェア製品をビルドするビルディング・ブロックとして組み込まれるように公開される。すなわち、リポジトリは、格納された成果物の電子コピーをソフトウェア開発者の使用に利用できるようにして、実行可能なソフトウェア製品をビルドするビルディング・ブロックとして組み込むためのコンピュータ・サーバを含むことができる。リポジトリは通常、成果物に寄与したソフトウェア開発者（個人またはグループ）を表示する一意的な識別子を有する。リポジトリは、リモートまたはローカルとすることができる。

【0159】

従来のソフトウェア・リポジトリの例には、限定ではなく例として、セントラル・リポジトリ（Ｍａｖｅｎ Ｃｅｎｔｒａｌとしても知られる）、ＮｕＧｅｔギャラリー、ＲｕｂｙＧｅｍｓ．ｏｒｇ、ｎｐｍｊｓ．ｏｒｇなど多数が含まれる。リポジトリは、例えば、Ｍａｖｅｎリポジトリ・フォーマット、ＲＥＳＴ ＡＰＩ対話、メタデータのフォーマットに固有のファイルを有する様々なディレクトリ構造など、事前規定のフォーマットおよびツールに依存する傾向がある。

【0160】

ソフトウェア・リポジトリは、限定ではなく例として、Ｍａｖｅｎ、Ｇｒａｄｌｅ、Ｒａｋｅ、Ｇｒｕｎｔなどのビルド・ツール、ｎｐｍ、ｎｕｇｇｅｔ、ｇｅｍなどのパッケージ・マネージャを含むツール、Ｅｃｌｉｐｓｅ、ＩｎｔｅｌｌｉＪなど多数の統合開発環境などによってアクセスされる。

【0161】

本明細書で使用される「ソフトウェア・ビルド」という用語は特に、複数のコンポーネント（その一部または全部をリポジトリから取得することができる）を変換し、さらなるソフトウェア・ビルドで使用するためにその結果を実行可能なスタンド・アローンのコンピュータ・プログラムまたはソフトウェア・コンポーネントに組み合わせる実行可能なビルド・プログラムにおいて事前規定されるプロセスを意味すると定義され、少なくともコンポーネントをコンパイルすることと、ビルド・プログラムで定義された所定の順番で、コンパイルされたコンポーネント、および場合によってはバイナリ・コンポーネント（リポジトリからのものとすることができる）をリンクすることとを含む。

【0162】

「コンパイラ」という用語は、本明細書では特に、実行可能なプログラムを作成するために、しばしばバイナリ・コードまたはバイト・コードの形で、プログラミング言語で書かれたソース・コードをコンピュータによって読み取り可能なターゲット言語に変換する一つ以上のコンピュータ・プログラムを意味するように使用される。

【0163】

「手動の介在なしに自動的に」という語句は、特許請求の範囲において使用される場合には、ステップが開始された後に、ユーザがプロセッサに入力を行うことを必要とせずに、ステップで列挙された制限が終了するまで、特定のステップが行われることを意味するように定義される。

【0164】

ＶＩＩＩ．実施および技術注記
上記の説明は、読者が記載された事項を認識するのに十分な技術的背景を有するものと仮定している。本節は、関連し得るいくつかの技術情報を説明する補足的な実施および／または技術注記をいくつか提供する。

【0165】

本開示は、１つまたは複数の実施形態を実行する最良の態様を可能にするやり方でさらに説明するために提供される。本開示はさらに、いかなる方法においても本発明を限定するのではなく、本発明の技術的思想およびその利点の理解および認識を高めるために提示するものである。本発明は、添付の特許請求の範囲によってのみ定義され、本出願の係属中になされたあらゆる修正、および発行されたそれらの特許請求の範囲のすべての均等物を含む。

【0166】

第１の、および第２の、などのような関係語が存在する場合には、その使用は、ある実体、アイテム、またはアクションを別のものから区別するためにのみ使用され、そのような実体、アイテム、またはアクションの間で、実際にそのような関係または順序であることを必ずしも必要としたり、含意したりするものではないことがさらに理解される。明示的に、かつ、必然的に、特定の順序に限定されない限り、いくつかの実施形態は、任意の順序で実行することが可能な複数のプロセスまたはステップを含み得ることに留意されたい。すなわち、そのように限定されていないプロセスまたはステップは、順不同に実行することができる。

【0167】

本発明の機能の多く、および本発明の技術的思想の多くは、実施する場合、デジタル信号プロセッサおよびソフトウェア、および／または特定用途向けＩＣなどの、ソフトウェアまたは集積回路（ＩＣ）とともに、またはこれらにおいて最もよくサポートされる。例えば、利用可能な時間、現在の技術および経済的に考慮事項によって動機付けられた当業者は、場合によっては多大な努力および多数の設計選択肢にもかかわらず、本明細書に開示された概念および技術的思想によって導かれれば、このようなソフトウェア命令またはＩＣを最小限の実験で容易に生成可能であることが見込まれる。したがって、簡潔にするために、そして技術的思想および概念を分かりにくくするあらゆるリスクを最小限にするために、このようなソフトウェアおよびＩＣのさらなる説明は、あったとしても、例示的な実施形態によって使用される技術的思想および概念に関する本質的要素に限定されることになる。

【0168】

ソフトウェア・リポジトリを含むリポジトリ環境に向けられた不受理の可能性のあるソフトウェア・コンポーネントを制御するための方法および／またはシステムを実証する様々な実施形態について、上記で詳細に説明した。上述したプロセスは、コンピュータ可読記憶媒体に命令として格納することができることにさらに留意されたい。コンピュータによって命令が実行されると、例えば、コンピュータ可読記憶媒体からロードされた後に、一つ以上のプロセスが実行される。本明細書に記載されている詳細な説明は、コンピュータ上またはコンピュータのネットワーク上で実行されるプログラム手順に関して提示することができる。本明細書におけるこれらの手順の説明および提示は、当業者が自らの作品の内容を他の当業者に最も効果的に伝えるために用いる手段である。

【0169】

さらに、一実施形態は、特定の例において、一人の開発者または管理者によって単一の現場で使用されているかのように説明されている。一実施形態は、希望する場合には、多数の開発者、管理者、および／または関連するユーザによって、１つまたは複数の現場で使用することができる。

【0170】

手順は、概して、所望の結果につながる自己矛盾がない一連のステップであると考えられる。これらのステップは、物理量の物理的操作を必要とするステップである。必ずしもそうではないが通常、これらの量は、非一時的なコンピュータ可読媒体上に格納可能な、転送可能な、組み合わせ可能な、比較可能な、およびそれ以外の方法で操作可能な電気信号または磁気信号の形態をとる。場合によっては、主に一般的慣習上の理由により、これらの信号をビット、値、要素、記号、文字、用語、数字などと呼ぶことが好都合であることが分かる。しかしながら、これらの用語および類似した用語はすべて、適切な物理量に関連するものであり、単にこれらの量に適用される便利なラベルにすぎないことに留意されたい。

【0171】

さらに、実行される操作は、追加、判定、または比較という用語で呼ばれることが多く、これらは一般に、人間のオペレータによって実行される知的活動に関連するものである。本明細書での説明は、オペレータの使用を企図する場合もあるが、人間のオペレータが本明細書に記載の実際の機能を実行することが、ほとんどの場合には望ましいが、必ずしもそうでなくてもよい。操作は機械操作である。

【0172】

本明細書の教示に従って書かれたプログラムを用いて、様々なコンピュータまたはコンピュータ・システムをプログラムすることができる。または、より特殊化した装置を構築して、必要な方法ステップを実行する方が好都合であることがわかる場合もある。様々なこれらの機械に必要な構造は、本明細書に記載された説明から明らかになるであろう。

【0173】

コンピュータ可読記憶媒体は、有形で、非一時的である。コンピュータ可読記憶媒体は、このようなコンピュータ可読記憶媒体が有形、かつ非一時的である限り、上述した例のようなメモリまたはストレージ・デバイスのいずれか、または、その他の取り外し可能記憶媒体もしくは固定記憶媒体とすることができる。

【0174】

さらに、一実施形態に関係する任意の通信ネットワークは、限定ではなく例として、無線通信機能を提供することが可能な、かつ／または、ケーブルおよび／またはコネクタなどといったような、有線接続を利用することが可能な、データおよび／またはパケット通信ネットワークを含むことができる。任意の適切な通信プロトコルを使用することができる。

【0175】

本明細書に関連して具体化されるコンピュータおよび／またはシステムは、適宜および／または必要ならば、限定ではなく例として、ハードウェアおよびソフトウェア・サーバ、アプリケーション・ソフトウェア、データベース・エンジン、サーバ・エリア・ネットワーク、従来のファイアウォールおよびＳＳＬセキュリティ、プロダクション・バックアップ・システム、および／またはアプリケーション・インタフェース・ソフトウェアを含む様々なコンポーネントの統合に依存してもよい（し、依存しなくてもよい）。一実施形態は、限定としてではなく例として、ネットワークベースであってもよいし、また、任意の情報配信のためのユーザとの例示的なインタフェースとして、インターネットなどのネットワークまたは他のネットワークを利用してもよい（し、利用しなくてもよい）。

【0176】

上記の説明に関係する１つまたは複数のデータベースは、限定ではなく例として、関係データベース形式とすることができるが、他の標準データ形式を使用してもまたよい。随意に、様々なデータベースは、様々な標準形式でデータを受信することが可能な既知の変換システムを含むことができる。

【0177】

限定ではなく例として、ＸＭＬを使用して、ＨＴＭＬ表示形式に関連してシステムのための１つまたは複数のディスプレイを開発することができる。ＨＴＭＬ、およびＸＭＬは、好適な表示形式とすることができるが、ユーザと対話し、ユーザ命令を取得するための代替表示形式を利用することが可能である。

【0178】

本開示は、本発明の真の、意図した公正な範囲および趣旨を限定するのではなく、本発明による様々な実施形態を作成し用いる方法を説明することを意図している。本発明は、本出願の特許取得のための係属中に補正される場合がある添付の特許請求の範囲および本発明のすべての均等物によってのみ定義される。上記説明は、網羅的であることを意図したものでもなければ、本発明を開示された正確な形態に限定することを意図したものでもない。上記教示に鑑み、変更形態および変形形態が可能である。上記実施形態は、本発明の技術的思想およびその実際の適用の最良の例示を提供するとともに、当業者が、様々な実施形態において、検討されている特定の使用に適した様々な変更形態とともに本発明を利用することを可能にするために選ばれて説明されたものである。そのようなすべての変更形態および変形形態は、本出願の特許取得のための係属中に補正される場合がある添付の特許請求の範囲によって定められる本発明の範囲内にあり、また、本発明のすべての均等物が公正、法的、かつ正当に権利を有する広さに従って解釈されるときは本発明のすべての範囲内にある。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】