技术领域总体涉及软件开发，并且更具体地涉及在基于组件的软件开发中使用的软件组件存储库。
背景技术：
大约15年前，软件开发人员使用很少的开源软件，反倒倾向于自己编写软件自身的大部分或全部内容。相比之下，今天，包括应用在内的大部分软件组件是由他人编写的。在当今的软件开发领域，与以往相比，他人创建的软件组件被用得多得多，而且这种趋势正在增加。
因此，实际上，今天的开发人员已经将质量责任委托给开源社区。关于开源软件组件的一种流行观点是：软件组件必然是好的，因为众多开发人员都在关注它。然而，这是一个错误的假设。有时候开源软件有很多问题。
此外，开发人员对他们正在使用的开源软件组件几乎没有可见性和理解。可用的软件开发工具使得使用开源变得容易，但这些工具并不能使得开源及其可能存在的问题变得容易理解。由于缺乏可见性和理解，造成了来自开源领域的软件往往依赖于其它开源元素这一事实。
软件存储库是用以为开发人员提供重用的和可重用的软件组件(无论是开源还是其它形式)的便利集合的已知技术。换言之，软件存储库提供了对软件开发人员将使用的组件的存储。
常规的存储库管理器可被用作为软件组件使用服务的存储和交换中心点。例如，常规的存储库管理器提供代理远程存储库并且将组件高速缓存到本地存储库的能力，以节省从远程存储库反复取回软件组件所需的带宽和时间。托管本地存储库的能力为组织提供了该组织所使用的软件组件的便利集合。尽管如此，软件组件的可见性和理解的问题仍然存在。
技术实现要素：
因此，一个或多个实施例提供了一种计算机。所述计算机包括操作用于与软件存储库通信的i/o接口；以及与i/o接口协同操作的处理器。处理器被配置为执行以下项。
一种控制旨在用于包括软件存储库在内的存储库环境的可能不可接受的软件组件的方法。在策略存储器中，提供了与存储库环境相关联的预定义的存储库策略。预定义的存储库策略定义风险以及针对每种风险定义针对风险要采取的动作，其中针对风险要采取的动作是至少从通过动作和没通过动作中选择的，其中所述动作是预定义的编程步骤。响应于接收到对软件组件的请求，确定所请求的软件组件对于软件存储库来说是否是新的。
当确定了软件组件对于软件存储库来说不是新的时：使软件组件通过。
当确定了所述软件组件对于所述软件存储库来说是新的时：从风险匹配单元确定与软件组件匹配的风险。评价被确定为与所述软件组件相匹配的风险，以确定在所述预定义的存储库策略中定义的、针对被确定为与所述软件组件匹配的风险要采取的动作。在所述软件组件的风险被评价为通过所述预定义的存储库策略的情况下，遵循在所述预定义的存储库策略中定义的针对被确定为通过的组件的通过动作，其中所述通过动作包括将所述软件组件添加到所述软件存储库。在所述软件组件的风险被评价为没通过所述预定义的存储库策略的情况下，遵循在所述预定义的存储库策略中定义的针对作为可能的不可接受软件组件而被确定为没通过的组件的没通过动作。
在另一实施例中，预定义的存储库策略还包括针对部分匹配的软件组件要采取的预定义动作。当确定软件组件对于软件存储库来说是新的时，并且当确定了软件组件与风险匹配单元已知的任何组件不匹配时，递归地执行在软件组件内部的下一层处的内部软件组件的深度检查，直到确定与风险匹配单元已知的已知组件相匹配的内部软件组件为止；针对与已知软件组件匹配的内部软件组件，执行确定风险的步骤。针对与已知软件组件匹配的内部软件组件的风险，执行评价风险的步骤。结合遵循预定义的针对部分匹配的软件组件要采取的动作，执行遵循在所述预定义的存储库策略中定义的针对与已知组件匹配的内部组件的风险的动作的步骤。
在又一实施例中，提供了隔离用户访问的隔离区存储器以及隔离区存储器中的组件的日志。通过将被确定为可能不可接受的软件组件的软件组件存储在所述隔离区存储器中而不是存储在所述软件存储库中，来将所述软件组件隔离；以及存储所述软件组件被隔离的事实。响应于接收到对软件组件的请求，确定所请求的软件组件是否在隔离区存储器中，并且提供关于确定了软件组件被隔离而不在软件存储库中的隔离通知。
在又一实施例中，当确定了软件组件被隔离时，由系统确定被隔离组件的不同版本，其中已知所述不同版本通过了预定义的存储库策略，并且隔离通知还指示隔离组件的通过了预定义的存储库策略的所述不同版本。
在又一实施例中，当组件已被隔离时，引导用户确定所述隔离组件是否应该因为豁免而被接受到软件存储库中，然后将被豁免的隔离组件(尽管没通过存储库策略)从隔离区移动到软件存储库中。
在另一实施例中，确定风险包括：基于软件组件的元数据来准备风险查找密钥；以及基于来自所述软件组件的风险查找密钥来取回指示所述软件组件的风险的信息。
在又一实施例中，在针对软件组件的预定义的存储库策略中定义的风险包括：所述软件组件受制于的许可证以及所述软件组件的安全漏洞。确定风险包括：基于来自所述软件组件的元数据准备对所述软件组件来说是唯一的许可证查找密钥和安全漏洞查找密钥；基于针对所述软件组件的许可证查找密钥从许可证查找信息提供器取回指示所述软件组件的许可证的信息；以及基于针对所述软件组件的安全漏洞查找密钥从安全漏洞信息提供器取回指示所述软件组件的安全漏洞的信息。
在又一实施例中，当所述软件组件被确定为对所述软件存储库来说是新的以及所述软件组件的风险全部被评价为无错误地通过所述预定义的存储库策略时要采取的动作包括以下项中的一个或多个：将被添加到所述软件存储库的软件组件记录到日志中；以及由所述处理器经由电子邮件通知新组件。
在不同的实施例中，对旨在用于包括软件存储库在内的存储库环境的可能的不可接受的软件组件进行控制。策略存储器提供与存储库环境和应用两者相关联的预定义的应用策略，预定义的应用策略不同于与存储库相关联的策略，并且预定义的应用策略可以不同于与其它应用相关联的策略。预定义的应用策略定义风险以及针对每种风险定义针对风险要采取的动作，其中针对风险要采取的动作是至少从通过动作和没通过动作中选择的，其中所述动作是预定义的编程步骤。响应于针对包括所述软件组件的应用的提交资产动作或构建动作，针对每个软件组件，确定所请求的软件组件对于所述应用来说是否是新的。
当确定了所述软件组件对于所述应用来说不是新的时：使软件组件通过。
当确定了软件组件对于应用来说是新的时，从风险匹配单元确定与软件组件匹配的风险。评价被确定为与所述软件组件相匹配的风险，以确定在所述预定义的应用策略中定义的、针对被确定为与所述软件组件匹配的风险要采取的动作。在所述软件组件的风险被评价为通过所述预定义的应用策略的情况下，遵循在所述预定义的应用策略中定义的针对被确定为通过的组件的通过动作，其中所述通过动作包括将所述软件组件添加到所述软件存储库。在所述软件组件的风险被评价为没通过所述预定义的应用策略的情况下，遵循在所述预定义的存储库策略中定义的针对作为可能的不可接受软件组件而被确定为没通过的组件的没通过动作。
根据一个或多个上述实施例，另一实施例是一种计算机实现的方法。
又一实施例是一种包括供计算机执行的指令的非暂时性计算机可读介质，所述指令包括如上的计算机实现的方法，所述指令用于在处理器中实现所述方法。
以上实施例中的一个实施例或多于一个的实施例的组合或全部实施例可以被组合并且被提供为单个实施例。
此外，上述摘要的目的是使美国专利商标局和公众(特别是不熟悉专利或法律术语或措辞的本领域的科学家、工程师和从业人员)普遍能够通过粗略检查快速确定本申请的技术公开的性质和本质。该摘要既不旨在限定由权利要求度量的本申请的发明，也不旨在以任何方式限制本发明的范围。
附图说明
附图被用来进一步示出各种示例性实施例，并且根据实施例解释各种原理和优点，在附图中相似的附图标记指代相同或功能相似的要素，并且附图和以下的详细描述一起被并入说明书并形成说明书的一部分。
图1是示出了常规存储库环境中的流的数据流图；
图2是示出了用于控制用于存储库环境的软件的计算机系统中的流的数据流图；
图3是示出了用存储库策略来评价组件的过程的流程图；
图4是示出了用应用策略来评价组件的过程的流程图；
图5是用于示出动态分析同步模式的流程图；
图6是用于示出动态分析异步模式的流程图；
图7是示出了用于提供所请求的软件组件的过程的流程图；
图8是示出了用于构建应用的过程的流程图；
图9是示出了软件组件进出隔离区(quarantine)的流的数据流图；以及
图10是示出了计算机系统的相关部分的框图。
具体实施方式
i.引言
概括而言，本公开涉及软件开发，其中应用包括软件存储库中存储的不同的自包含软件组件，软件存储库可以支持不同的应用，开发人员可以对软件存储库进行添加，并且软件组件被提供给开发人员以供使用和重用。提供了一种用于检测软件组件中的潜在风险并防止这些风险流入存储库和/或防止这些风险流出例如到应用或被发布等的方法；所述方法和系统可以有利地与存储库管理器一起工作。通过在适合软件开发的关键时刻采取措施以自动阻止、隔离、限制或通知不符合预定义准则的软件组件，并且可能还通过指示失败原因和/或建议可接受的软件组件，可以减少和/或防止消费(入站流)和发布(出站流)具有对于存储库或对于应用来说已经被视为不可接受的风险的软件组件，从而大大减少风险行为并且大大提高整体软件开发效率。
更具体地，各种创造性概念和原理体现在获取新的软件组件的系统、设备以及方法中，所述系统、设备以及方法位于组织和新的软件组件的供应之间，并且仅在新的组件到达组织处、和/或仅在可可能进入软件存储库或应用的软件组件被发行之前、和/或仅在新的组件被以其他方式散布在应用中或散布到组织的软件存储库中之前，才对新的软件组件进行评价。
构思在于允许系统建立并利用任意准则来通过或没通过可能存在风险的软件组件。这样的风险可以是安全漏洞，(例如，即使软件组件通过安全测试或审查，软件组件是否存在安全漏洞)；和/或软件组件所需的许可证。如果软件组件具有预定义的风险，则系统可以采取与失败相对应和/或与风险类型相对应的动作(比如，阻止软件组件)或本文讨论的其它预定义的编程步骤。
概括地说，一个或多个实施例可以担当防止开发人员没有意识到有问题的、或者与公司或组织策略等不兼容的入站软件组件进站的守卫。在出站侧，可以进行类似的检查，以确保出站软件组件(其可以位于存储库中)通过已建立的测试，这些测试可以针对特定应用进行定制。作为许可证风险的示例，如果系统不想允许apache2.0或gplv3成为许可项目，则可以阻止这些项目。作为安全漏洞的示例，考虑软件组件可能具有定级为较低级别的漏洞，但该应用只能阻止关键级别的漏洞。此外，策略可以包括各种变型，比如禁止超过某个年龄的或不满某个年龄的组件，或禁止所有开源组件。
如下文进一步讨论的，有利地采用各种创造性原理及其组合来允许用户建立适合其系统的策略，其中用户可以允许具有某种风险的组件并且禁止其它组件。
进一步根据示例性实施例，提供了解决上述问题的方法和系统。
ii.问题介绍和观察
存储库管理器提供了用于管理任意数量的软件组件存储库的设施。典型的存储库管理器有两个主要流。
第一个流充当针对另一上游存储库(通常是另一存储库管理器的一部分)的高速缓存代理。在此流中，客户端将向本地存储库请求特定的软件组件，并且本地存储库将确定所请求的组件是否可获得。如果可获得，则存储库管理器将向客户端提供该组件。如果不可获得，则存储库管理器将从先前建立的上游存储库中获取组件，将组件本地高速缓冲(在代理存储库中)，然后向客户端提供组件。
第二个流允许存储库管理器的用户向与存储库管理器中的特定存储位置相关联的托管存储库发布组件。在此流中，客户端将请求存储库管理器将软件组件存储在预先配置的位置中。当组件被上传并存储时，目标存储库就可以成为其他消费者的分发点，类似于存储库的代理高速缓存形式。
现在参考图1，图1是示出了常规存储库环境中的流的数据流图。在图1中，存在客户端a101、客户端b103、第一流107、第二流109、存储库管理器111、代理存储库113、托管存储库121、托管存储库中的组件和元数据119、上游存储库105、上游存储库中的组件和元数据117。
在第一流107中，客户端a101向存储库管理器111请求软件组件(117或119)。存储库管理器111确定所请求的组件是否在托管存储库121处可获得。如果所请求的组件119在托管存储库121处可获得，则存储库管理器将向客户端a提供组件119。如果所请求的组件117在托管存储库121中不可获得，则存储库管理器111将从上游存储库105获取组件117，在本地(在代理存储库113中)高速缓存组件，然后将组件113提供给客户端a101。第一流可以被称为高速缓存代理流。这是可以由上游存储库105分发以可以成为可获得的第三方开源组件的软件组件的典型流。
在第二流109中，客户端b103请求存储库管理器111将软件组件119存储在由托管存储库121表示的预先配置的位置。当软件组件119被上传并存储时，托管存储库119于是可以成为用于其它消费者(通常是管理托管存储库121的组织中的开发人员，所述开发人员可以请求存储在托管存储库121中的组件)的分发点。该软件组件119可以是客户端b开发的组件，或者最近看有可能是源自其它地方的、在上传之前被客户端b插入其自己的开发环境中的第三方组件。
在开源软件的使用大量增加之前，在应用创建中使用的第三方软件组件的数量是微不足道的。此外，这些组件的关键程度常常很低。因此，组织通常忽视这种第三方软件的质量而假设风险是微不足道的。然而，随着开源的使用的增长，这种动态已经发生了巨大改变。例如，在2000年，典型的应用包括的第三方组件少于10％。在2015年，典型的应用包括80％至90％的第三方组件。
应用的组成的这种改变提供了非凡的好处，因为软件开发人员能够利用开源软件生态系统能提供的各种专业化和专业知识。现在这种高度外包的模式面临的挑战是：质量验证的最终责任仍然是实际使用开源组件的团队的责任。然而，用于这种验证的工具非常有限，并且没有与本文讨论的系统和方法所提供的预定义动作和可能的补救措施有关的任何对质量的自动验证，更不用说在关键时刻对质量的自动验证。
针对防止使用劣质或有缺陷的软件组件和应用的挑战而采取的通常响应是对使用的软件进行手动的人工审查。通常开发团队不了解组件的适用性或可接受性。一些组织拥有对软件组件进行手动检查的大型的人力资源密集型的评价处理。
目前的方法存在问题。由于开发人员被迫在开发之前等待批准，因此往往会导致严重的延迟，而更糟糕的是可能会使得开发人员采取变通方法而完全绕过审查过程。由于软件开发速度不断提高，引入延迟的过程通常会导致成本效率显著低下，最终影响发展中组织的竞争优势。
现如今情况没有得到改善的原因在于没有适当的控制措施，并且经常发生的情况是：存储库与互联网断开连接(禁止访问上游存储库)以加强安全性，在开发之前手动仔细审查新组件，并且将那些通过审查的新组件放入供开发人员使用的存储库中。使用常规检查是很麻烦的，会滋生各种变通方法，并且与最终产品无关。
iii.方法方面
a.构思
上面部分中讨论的问题的解决方案是在解决上述问题的同时增强软件组件的可见性和理解。本文公开的实施例将自动化的有效使用引入到适当的点中，以强制执行对第三方和开源软件组件的质量验证处理，所述处理是针对软件组件的中间用途或最终用途而定制的，在适配典型开发人员的行为(比如，使用他们想使用的东西)的同时减少延迟和验证错误。因为现在可以在将软件组件存储到存储库中之前和/或在对软件组件进行部署之前知道软件组件的属性和风险，因此本文中公开的方法和系统可以使用所讨论的针对组件的可获得数据来自动处理包括规则集在内的用户可配置的预定义策略，并且将根据开发人员对软件组件的预期使用来采取预定义的、用户可配置的操作。由于减少了通常的延迟和错误，并且在不需要开发人员采取变通方法的同时避免了在开发过程中的适当点处做出不良的组件选择决定，从而显著提高了开发效率。如果可能的话，避免这些早期的不良决定会使得计划外和未计划的开发工作显著减少；在其它适当的点处检查，以确保避免不良的组件选择决定，从而加强开发过程。
在某些情况下，开发人员可以从存储库取回软件组件。最终，存储库可以仅作为软件开发文件系统而被审查。该系统不仅可以提供用于存储库管理器，也可以提供用于通过其开发人员引入软件的任何方法/系统，这样的系统可以与存储库相媲美。该系统也可以提供用于任何开发人员部署工具或用于发布应用或其它的组件集成组群的工具。
在软件开发生命周期的上下文中，存储库管理器可以通常利用代理高速缓存形式的存储库以及基于本地存储的存储库(通常也称为“托管存储库”)的组合来为各种客户端以及开发和操作工具提供软件组件。由于存储库管理器是开发生命周期的核心，因此可以将其用作为用于确保正在使用适当的软件组件的方便控制点。
b.架构
现在参考图2，图2是示出了计算机系统中的用于控制针对存储库环境的软件的流的数据流图。图2示出了客户端a201、客户端b203、第一流207、第二流209、具有防火墙的存储库管理器211、代理存储库213、托管存储库227、可选的隔离区存储器229、和上游存储库205。这里由组件和元数据215表示的组件被存储在托管存储库227中。这里由组件和元数据231表示的组件被存储在上游存储库205中。
在第一流207中，如本文进一步详细描述的，客户端a201向包括防火墙的存储库管理器211做出针对软件组件(215或231)的常规请求。由于这是开发环境，因此假设软件组件被指定为规范版本，例如“ember-1.1.2-nupkg”。存储库管理器211确定所请求的组件是否在托管存储库227处可获得。如果所请求的组件215在托管存储库227处可获得，则存储库管理器211将根据常用技术向客户端a提供组件215。如果所请求的组件在托管存储库227中不可获得，则存储库管理器213将从上游存储库205获取组件231。然而，在可能向客户端a201提供组件231并且将组件保存在存储库227中之前，存储库管理器211将使用风险数据(这里由安全漏洞风险数据219和软件许可风险数据217表示)来确定组件的风险，并且确定组件231是否通过已经在存储库策略223中建立的规则(关于入站组件的处置)。如果组件231通过存储库策略223，则存储库管理器将采取通常的步骤(例如将组件本地高速缓存(到代理存储库213))，然后向客户端a201提供组件231。如果组件231没通过存储库策略223，则将采取建立在存储库策略223中的用于处置没通过的入站组件的动作。如下面更详细地公开的那样，这些步骤可以是通过示例提供的以下项中的一个或多个：阻止将组件231提供给客户端a；向客户端a201通知关于组件231失败的原因；将组件231移动到隔离区存储器229中(有可能随后由于豁免而移动到托管存储库)；提出组件的可接受的备选版本；执行对组件的深度检查221以确定部分匹配的风险(例如，组件内包括的组件的风险)并重复进行部分匹配；阻止部分匹配；以及可以堆叠在一起的这些操作的变型和组合。因此，从客户端a201的角度来看，对组件的请求的行为与常规请求相同，除非存在风险。此外，如果存在风险，则可以向客户端a201处的开发人员提供用于选择将通过存储库策略的组件的选项和信息。
在第二流209中，客户端b203请求(像通常一样)存储库管理器211将软件组件215存储在预先配置的位置(由托管存储库227表示)。可能有其它原因导致上传，所述原因如被持续集成(ci)处理注意到、或为了全面或部分构建应用。如下面更详细讨论的，存储库管理器211确定组件是否通过已经在存储库策略223中建立的规则，或者如果该组件旨在用于应用，则确定组件是否通过特定于应用的预定应用策略225a、225b。当软件组件215被上传和存储、和/或应用被构建(build)时，托管存储库227于是可以成为针对其它消费者的分发点。然而，在可以上传组件之前，存储库管理器211将使用风险数据(例如，安全漏洞风险数据219和软件许可风险数据217)来确定组件的风险，并且确定组件是否通过在与特定应用相关联的应用策略225a或225b中已经建立的规则(关于出站组件的处置)。如果组件231通过应用策略225a或225b，则存储库管理器211将采取常规步骤，例如本地存储组件(将组件存储在托管存储库227中)，然后使该构建或组件对客户端是可用的。如果正在上传或构建的组件没通过应用策略225a或225b，则将采取在应用策略225a或225b中建立的用于处置没通过的出站组件的动作。如下面更详细地公开的那样，这些步骤可以是通过示例提供的以下项中的一个或多个：(适用于内部开发使用)的任何方式的构建；阻止组件231被用于构建或被上传；向客户端b203通知关于组件失败的原因；将组件移动到隔离区存储器229中(有可能随后由于豁免而移动到托管存储库227)；提出应用策略225a或225b可接受的组件的备选版本；执行对组件的深度检查221以确定部分匹配的风险(例如，组件内包括的组件的风险)并重复进行部分匹配；阻止部分匹配；以及可以堆叠在一起的这些操作的变型和组合。
存储库管理器211及其代理存储库和托管存储库213、227可以充当作为应用的一部分的软件组件或甚至作为整个应用自身的软件组件的本地(例如，高速网络连接在通信节点之间是可用的)存储仓库。在软件开发和操作流水线的上下文中，该本地部件仓库提供了极高的性能和可靠的应用构建，最终显著提高了整体开发效率。
存储库管理器211可以被认为是软件组件(在应用的组装和所得的应用本身中使用的部件)的通用入口和出口点。它是用于控制可能不可接受的软件组件的方法/系统的集成的理想点。
一旦软件组件215被存储在存储库227中，软件组件215就不会被重新评价并且不应该在之后被驱逐。原因在于：构建取决于库中的软件组件的持续存在，并且驱逐可能导致构建中断。驱逐可以进行，但这不是好的做法，因为驱逐将导致部分开发人员的低效率和混乱。较好的做法是在构建点处捕获组件，而不是试图始终保持软件完全干净。在该系统中，当软件组件被存储在存储库227中时，假设软件组件是足够干净的。
本发明的方法和系统可以集成到与存储库管理器211的内部和外部的与软件组件相关联的流路径(这里由第一流路径和第二流路径207、209表示)中。
c.风险、策略和动作
这样的系统和方法可以基于策略223、225a、225b中包含的规则集合进行作用，这些规则是预定义的，用于建立哪些风险被认为是可接受的、哪些不是可接受的、以及针对没通过的风险采取什么动作。可以评价例如通过存储库管理器211流入和流出软件储存库213、227的组件和应用的可接受性。如果组件或应用的风险被认为是可接受的，则可以如预定义的策略中所定义的那样采取某些用户可配置的、预定义(可编程)的动作。当组件或应用的风险被认为是不可接受时，也可以如预定义的策略中所定义的那样采取不同的动作集合，这样的动作集合通常是为了防止不可接受的组件或应用的交付或存储。然而，取决于系统用户所期望的行为，也可以采取其它动作。
通过响应于组件或应用的风险是否被认为是可接受的而采取预定义的动作，可以自动防止使用劣质或有缺陷的软件组件，同时向开发人员提供关于出了什么问题或者可以是更好的做法的即时反馈。
这可以提供极其可扩展的控制形式，显著降低开发成本和应用组合风险，并显著提高整体开发和操作效率以及开发人员行为。
1.风险
可以自动分析出于任何原因进入存储库的组件，并且将组件与可获得的与所述组件有关的风险数据进行匹配。风险数据可以包含诸如安全漏洞、软件许可细节和/或来自可能与组件关联的元数据的其它细节。
根据已知技术，所述方法和系统可以从组件的元数据中提取用于唯一识别该组件的已知“标记”。组件的识别可被用于查找与该组件相关联(即，可以与风险相匹配)的信息。例如，安全漏洞风险数据219可以将组件的识别与已报告(如已知)的针对该组件的安全风险相关联。作为另一示例，软件组件的元数据可以列出软件组件所需的一个或多个许可证；或组件的识别可被用于查找与组件相关联的许可证，例如，软件许可风险数据217可以将组件的识别与软件组件固有的许可证相关联。在该示例中，这些处理在存储库管理器211中实现，但是可以与存储库管理器分开而例如被实施为数据服务。用于识别与软件组件相关联的安全漏洞以及用于识别与软件组件相关联的许可证的技术是已经的。
被评价的风险的类型不必局限于安全漏洞和软件许可。任何任意数据都可被附加到已知组件。如果附加了数据，则系统可以评价该数据并对其执行动作。关于安全漏洞，这些规则参考被报告为与软件组件相匹配的安全漏洞风险数据。关于软件许可，这些规则参考被报告为与软件组件相匹配的软件许可细节。
软件开发人员通常从各种源中的任何源拉取软件组件。众所周知，软件组件总是具有元数据。可以提供表格，该表格输入软件组件的唯一识别符(例如，查找指纹，本文有时称为查找密钥)，并且反馈与指纹相匹配的风险。关于与软件组件相匹配的风险的信息将用作为评价的一部分。对于许可证，系统可以识别组件并且(例如，使用常规技术基于哈希值)为组件创建独一无二的指纹，该指纹是用于查找指示与该组件相关联的许可证的信息的查找密钥。
以下是安全漏洞风险数据219的简单缩减示例，其不旨在全面的涵盖而是旨在建议变化：
表1-示例安全风险
以下是软件许可风险数据217的缩减示例，其不旨在全面涵盖，而是旨在建议变化：
表2-示例软件许可风险
开源项目往往依赖于要被折入的其它东西，因此可以存在可以与bsd和cddl1.0相组合的apache许可证，可选地选择cddl1.0或gpl。可以确定许可证的组合，并且将该组合存储到软件许可风险数据存储器217中。
在很多情况下，软件许可风险数据可以是在软件组件或其元数据中直接可获得的。
从上面可以看出，软件组件与其风险数据相匹配。
2.策略和风险与动作
针对根据预定义的可配置的规则集合而预先准备的预定义策略来估计与软件组件相匹配的风险，以确定对组件的处置。基于与软件组件匹配的风险，软件组件可以被视为通过或不能通过可接受的准则。然后，可以根据组件是通过还是没通过来采取已经配置了的没通过动作或通过动作的预定集合，这会在后续部分中讨论。
可配置的规则可以存储在策略223、225a、225b中。基于预定义规则，这些策略是用户可配置的。该规则将风险与动作和处置相关联。处置可以是通过或失败(没通过)，尽管也可以提供其它处置。对于没通过的组件，系统可以采取预定义的编程步骤；而对于通过的组件，系统可以遵循正常的处理，例如存储组件、构建应用等。例如，给出关于组件的已知元数据片段，可以提供已知安全漏洞风险的列表；假设规则是，如果安全漏洞大于预定级别，则组件失败。作为另一示例，规则可以是：如果软件组件匹配任何指定的软件许可证(例如，gpl、egpl)，则软件组件通过(或者备选地失败)。这些规则可以叠加起来以实现策略，以处理与单个组件匹配的多种风险，其中遵循的动作是最严格的动作。
以下是示例存储库策略或应用策略中指定的规则的简单示例，其不旨在全面涵盖：
表3-示例策略
系统可以被设置为使得：在组件具有任何风险会没通过的情况下，该组件没通过。
图2的图示为存储库223提供策略，并且为不同的应用中的每一个提供不同的策略225a、225b。预期应用策略是存储库策略的子集。例如，根据存储库策略，gpl组件可以被允许进入存储库，但是特定的应用可能不适合于gpl，因此存储库管理器211在特定的一个应用策略下将使组件没通过，而在不同的应用策略之下使组件通过。
3.针对没通过动作的策略和编程步骤
例如，今天的组织经常尝试进行集成和构建，这允许系统经常在构建的每个点处评价应用(或应用中的一些组件的组群)是否通过策略。作为替代或补充，系统可以仅在发行之前进行评价。这些可以在开发工作流中的各个点处设置，并且每个点具有对应的且可能不同的预先配置的动作集合。
存储库管理器211可以利用这些策略在开发发行过程中的不同阶段强制执行该策略。在开发发行过程中的所有不同阶段处可以利用相同的编程步骤。备选地，策略可以在不同阶段处指定不同的编程步骤，这些步骤被视为不同的强制执行点。例如，策略可以在每个强制执行点处指定用于没通过动作的编程步骤；编程步骤的其它示例是可能的。这种灵活性允许在违反策略的情况下发生理想的动作，得到更有效率和更高效的对开发过程的控制。
该策略可以为“没通过”动作指定编程步骤，该“没通过”动作将强制执行阶段与编程步骤相关。以下是针对没通过动作的预定义编程步骤的简单示例，其不旨在全面涵盖，而是旨在建议变化。
表4-示例没通过动作
强制执行的阶段可以根据例如使得组件要被评价的开发人员环境工具来确定。例如，向存储库管理器做出的针对新组件的请求可以被视为强制执行的“开发”阶段，发起评价的持续集成(ci)工具可以被视为强制执行的“构建”阶段，针对内部测试发起评价的构建工具可以被视为是强制执行的“阶段发行”阶段，针对应用发行版本发起评价的构建工具可以被视为是强制执行的“发行阶段”，并且重新创建先前发行的版本的任何尝试可以被视为是强制执行的“操作”阶段。
请注意，用户可以相当简单地通过修改预定义的编程步骤及其组合来配置操作。此外，本文将更详细地讨论编程步骤。
在组件没通过的情况下，一个常见动作是阻止将组件提供给用户，但支持其它预定义的用户可配置动作。
存储库管理器211通常用于发布新的和更新的应用。在操作中，好的实践是不发布没通过应用策略的应用，并且附带错误和通知的，以便可以修复应用。
如果需要的话，可以按照上面描述的与没通过动作相关的方法，为通过动作指定预定义的编程步骤。
4.深度检查
除了已知的关于组件的数据(因为之前已经遇到组件)之外，比如当组件不是已知时，可以对软件组件内部的软件组件进行深度检查221，以识别已知的组件和未知的组件内部的组件。静态应用安全测试(sast)和动态应用安全测试(dast)等工具是示例。在转让给sonatype公司的us8,825,689中公开了用于识别内部组件的深度检查。
关于组件的“深度检查”221，前面的许多部分都涉及已知的规范版本的组件，这些组件是来自供应商的原始版本的逐位对应的复制件。然而，在某些情况下，开发人员修改或修复部分软件组件，从而导致对原始组件进行轻微修改，从而无法轻易识别该组件。
在无法识别组件的情况下，深度检查221将识别内部组件。例如，使用已知技术，可以对与原始组件的相似性进行评分，并且可以将分数并入存储库策略223或应用策略225a、225b的一部分中。换言之，如果某个东西与原始组件不是100％匹配的，该某个东西可能会失败(也许有后门或特洛伊木马)。深度检测是针对与已知组件不相同但相似的某物。以这种方式，可以在正被应用于该原始组件的预定策略下评价与原始组件不是100％匹配的组件。
该策略可以预定如何处理部分匹配的组件。如果某个组件是完全匹配的，则可以比在组件不完全匹配的情况更快地应用策略，并且对该组件执行深度检查。当对软件组件执行深度检查221时，系统从软件组件的最外层开始，并且尝试识别该层的指纹。如果该指纹未知，则系统将该最外面的组件分解成下一内层中的组件，并且尝试识别下一内层中的每个组件的指纹。当在某一层识别出组件时，评价就完成了。在此之前，深度检查221将递归继续。
一般而言，预期大部分组件都是已知的，但会有一些异常。如果存在一个(或多个)不同的事物，也就是当部分匹配算法和打分发挥作用时，随后将策略应用于所识别的每个组件。
软件组件通过还是失败是通过内部组件的风险数据的组合来确定的。
此外，对于部分匹配的组件，每个策略都可以确定必需匹配多少否则就失败；例如，如果部分匹配的组件不是至少80％匹配，则该组件将会失败。例如，当最外层匹配时，则不需要更深度的检查，因为系统先前已经识别出针对所匹配的软件组件中的所有组件(包括每层处的内部组件)的所有信息。
5.隔离
在一些实现中，入站的但是不能通过存储库策略223的软件组件231可被置于隔离区存储器229中，并且软件组件在隔离区中的事实也被存储在例如日志中。随后，可以针对隔离的软件组件日志来检查所请求的软件组件，以便不需要针对用户定义的策略进行检查，或进行深度检查以使所请求的已被隔离的软件组件失败。
当软件组件被阻止时，可以将被阻止的软件组件置于隔离区内，这允许用户可以更深入地评价被隔离的软件组件。在一些实现中，可以豁免隔离，其包括由用户明确地将软件组件从隔离区存储器229移动到存储库117。这允许不能通过广泛的一般性策略的软件组件出于策略中未捕获到的原因而根据该软件组件自身的优点而被包括在存储库中。
iv.组件和流的详细描述
本文中公开的总体设计可以允许将评价并入到存储库管理器中，或者将评价并入到其它开发和/或构建工具中。图3和图4分别示出了对入站组件(到存储库)和出站组件(例如，到应用)的评价。如结合图3进一步描述的，利用存储库策略来评价入站组件。如参考图4进一步描述的，利用特定于应用的应用策略来评价旨在用于特定应用的出站组件。在图5和图6示出了对策略的分析是如图5中那样的同步的(即，在处置组件之前对组件进行评价并且采取动作)或者如图6中那样的是异步的(例如，在根据标准处置已经处理了组件之后对组件进行评价并且采取动作)的变化。图7和图8分别示出了如何分别从开发和/或构建工具中启动图3和图4的入站流程或出站流程。
本文中通过举例说明数据流以进一步理解本文所讨论的原理。实际的实现可以省略数据流的一个或多个部分，和/或可以包括在本文时论的范围和精神内的其它数据流。
现在参考图3，图3是示出了用存储库策略来评价组件的过程301的流程图。在图3中，过程301包括风险匹配单元321。在风险匹配单元321中，过程301确定(305)要被评价的组件是否是已知的已经针对风险匹配进行了评价的组件，这意味着是否针对风险对组件进行了评价。
如果知道已经针对风险匹配对组件进行了评价(305→是)，则过程301将尝试将组件与风险数据匹配313。例如，可以使用已知技术、使用组件的散列或二进制签名来准备查找密钥。然后，基于查找密钥，可以确定与组件匹配的任何存在的风险(比如，安全漏洞和/或软件许可证)。应该注意，元数据中可用的任何数据都可以用于确定各种风险。
如果对于与风险的匹配而言组件是未知的(305→否)，则过程301的一些实施例可以包括深度检查。正在评价的组件内部的软件组件是逐层评价的，直到组件已知为止。在深度检查中，过程301将确定307软件组件内下一层是否有任何内部组件。如果在下一层有内部组件，则将执行深度检查以识别被评价的组件内的组件。然后针对风险递归地评价在下一层处识别出的组件。如果在下一层没有内部组件，则过程301将指示正被评价的组件是可能不可接受的309，因为在评价之后尚未遇到组件及其内部组件(如果有的话)。经由深度检查确定的组件的风险包括该组件内的组件的风险。例如，有时候，组织重新构建稍微修改了的开源组件。这些改变导致组件与规范版本不匹配。当发生这种情况时，深度检查可以用于确定组件是否与已知组件“相似”。可以基于有多相似来指派分数。这个分数实际上是与组件相关联的、可以作为规则集合的一部分而被评价的另一数据片段。例如，一些用户可以决定只能使用已知的组件，或者部分匹配(例如，匹配度为80％、90％、99％)的组件也是可以的。因此，对于提交用于评价的任何一个组件，可能有部分匹配、完全匹配或不匹配。a，“匹配状态”是真或假中的任一个，而“部分匹配分数”具有小于100％的某个值。
当过程301确定了与组件相匹配的风险时(并且如果进行了深度检查，则此组件内的组件的风险)，将针对预定义的存储库策略来评价315匹配风险以确定针对风险要采取的动作。如果根据存储库策略风险全部被确定为“通过”，则过程301将遵循在预定义的存储库策略中定义的通过动作317。通过存储库策略的组件被认为是可以接受的，并且可以照常添加到存储库中。具有通不过存储库策略的风险的组件被认为是不可接受的，并且可以遵循预定义的存储库策略中定义的没通过动作319，即针对没通过动作的任何预定义编程步骤。可选地，如上所述，可以基于开发人员工具的阶段来定义用于通过动作和/或没通过动作的预定义编程步骤。
现在参考图4，图4是示出了用存储库策略来评价组件的过程的流程图。在图4中，过程401包括风险匹配单元419。在风险匹配单元419中，过程401确定(403)要被评价的组件是否是已知的已经针对风险匹配进行了评价的组件，这意味着是否针对风险对组件进行了评价。
如果知道已经针对风险匹配对组件进行了评价(403→是)，则过程401将尝试将组件与风险数据匹配411。例如，可以使用已知技术、使用组件的散列或二进制签名来准备查找密钥。然后，基于查找密钥，可以确定与组件匹配的任何存在的风险(比如，安全漏洞和/或软件许可证)。应该注意，元数据中可用的任何数据都可以用于确定各种风险。
如果对于与风险匹配而言组件是未知的(403→否)，则过程401的一些实施例可以包括与结合图3所讨论的深度检查类似的深度检查。正在评价的组件内部的软件组件是逐层评价的，直到组件已知为止。在深度检查中，过程401将确定405软件组件内下一层是否有任何内部组件，该任何内部组件在存在的情况下将被递归地评价409。如果在下一层没有内部组件，则过程401将指示正被评价的组件是可能不可接受的407，因为在评价之后尚未遇到组件及其内部组件(如果有的话)。经由深度检查确定的组件的风险包括该组件内的组件的风险。
当过程401确定了与组件相匹配411的风险时(并且如果进行了深度检查，则此组件内的组件的风险)，将针对预定义的应用策略来评价413匹配风险以确定针对风险要采取的动作。如果根据应用策略风险全部被确定为“通过”，则过程401将遵循在预定义的应用策略中定义的通过动作415。具有没通过存储库策略的风险的组件被认为是不可接受的，并且可以遵循预定义的存储库策略中定义的没通过动作417，即针对没通过动作的任何预定义编程步骤。可选地，如上所述，可以基于开发人员工具的阶段来定义用于通过动作和/或没通过动作的预定义编程步骤。
在图5和图6分别示出了用于处理规则评价和动作执行的同步模式和异步模式变化。
现在参考图5，将讨论和描述用于示出动态分析同步模式的流程图。在同步模式处理501中，利用存储库策略来对组件进行评价503，并且在标准处置组件可以发生之前处理501确定采取哪个动作505(例如，阻止组件或通过组件)。
现在参考图6，将讨论和描述用于示出动态分析异步模式的流程图。在异步模式处理601中，对软件组件进行标准处置603，这可以例如导致向下游请求客户端交付。与标准处置603并行或者在标准处置603之后的某个时间，执行评价605，接着确定607该动作与软件组件的风险相对应。
如果使用异步模式变化，则允许经由执行标准处置603将组件(可能可接受或可能不可接受)提供给存储库管理器的用户。然后，异步过程601利用存储库策略来评价605组件。在完成评价605之后，过程601基于组件是否通过来确定607要采取的动作，例如动作可以是例如经由电子邮件来向一组用户进行警告，通知例如已经交付的组件实际上通不过策略。
现在参考图7，图7示出了用于提供701所请求的软件组件的过程的流程图。图7示出了集成开发环境(ide)的上下文中的入站组件的流程。可以理解，可以使用其它开发工具而不是ide。在图7中，利用存储库策略来评价组件711与以上参考图3所描述的相对应。
用于提供所请求的软件组件的过程701可以用例如由开发人员使用的开发或其它操作工具来发起，例如，由开发人员使用的开发或其它操作工具接收703开发人员的针对软件组件的请求；指定的软件组件是规范的(通常是编号的)版本。作为开发人员对组件的请求的结果，过程701确定705该组件对它将被放置到的存储库来说是否是新的。这样的存储库可以是正式的托管存储库，或者甚至是不太正式的旨在用于开发人员的软件组件的指定集合。
如果组件对于存储库来说不是新的(705→否)，则过程701对存储库中的组件采取通常的动作。例如，所请求的组件从存储库中取回，并且例如经由开发或操作工具而传送给开发人员。
如果组件对于存储库来说是新的(705→是)，则过程701将从上游存储库得到组件709。用于从上游存储库取回组件的技术是已知的。然后，利用组件将被置于其中的存储库的存储库策略对从上游存储库取回的组件进行评价711。图3中提供了评价711的示例。利用存储库策略来进行的评价711将根据策略(即，组件通过或没通过策略)返回针对组件的动作。
如果组件通过存储库策略(711→组件通过)，则过程701将针对不在存储库中的组件采取通常的步骤713。例如，所请求的组件存储在存储库中，并且例如经由开发或操作工具而传送给开发人员。
如果组件没通过存储库策略(711→没通过)，则过程701将采取在存储库策略中预定义的编程步骤715。例如，这样的编程步骤可以包括以下项中的一个或多个：阻止组件被存储在存储库中；向请求者通知组件没通过；向管理器通知失败的尝试和组件；向请求者通知所建议的通过存储库策略的备选组件等。组件没通过的通知可以包括组件中识别的风险，这可以帮助确定要使用的更好的组件。在一些实施例中，请求者可以选择请求备选组件来替代最初请求的组件；如果这样的话，则处理701如所请求的组件那样来评价703至719该备选组件。当采取通过动作或没通过动作时，该过程结束717、719。
在一些变型中，该过程为没通过的组件存储指纹日志。该过程可以检查不在存储库中的组件是否在没通过的组件的指纹的日志中，可以跳过利用存储库策略对组件进行评价711，并且采取指定的没通过动作715。
存储通过的指纹日志应该不是必须的，因为这些组件应该先前已存储在存储库中，因此这些组件对于存储库来说不会是新的。然而，如果希望存储的话，可以保留通过的组件的对应日志。
现在参考图8，图8是示出了用于构建应用的过程的流程图。图8示出了在构建的上下文下的出站组件的流程，所述构建可以是例如构建工具、开发工具、持续集成(ci服务器)等。可以理解的是，可以使用其它开发工具，其中意图是组件被指定用于特定应用，例如发布、发行、构建等(从开发人员的角度理解为出站)。在图8中，利用应用策略来评价组件809与以上参考图4所描述的相对应。
当例如构建工具或开发工具或其它操作工具被指示资产准备好提交、或者包括组件的应用(或应用的一部分)准备好构建时，可以发起用于构建应用的过程801。构建或开发工具的方便示例是持续集成(ci)服务器。作为即时提交资产或在构建(或部分构建)时指定的软件组件是规范版本，并且该应用也是指定版本。过程801确定805该组件对于将包括它的应用来说是否是新的。该组件可能(或可能不是)已经在存储库中。基于应用策略，该组件可能(或可能不)适用于应用。
如果组件对于存储库来说不是新的(805→否)，则过程801对已经在应用中使用的组件采取通常的动作821。例如，经由开发或操作工具采取用于构建要被包括在应用的最终制品的通常步骤等。
如果组件对于应用来说是新的(805→是)，则过程801将利用将在其中构建组件的应用的应用策略来对组件进行评价809。图4中提供了评价809的示例。利用应用策略来进行的评价809将根据策略(即，组件通过或没通过策略)返回针对组件的动作。
如果组件通过应用策略(809→组件通过)，则过程801将针对该组件采取例如用于构建最要包括在应用中的最终制品的通常步骤807；如果组件尚不在存储库中，则过程801也将该组件存储在存储库中。
如果组件没通过应用策略(809→没通过)，则过程801将采取在应用策略中预定义的编程步骤811。例如，这样的编程步骤可以包括以下项中的一个或多个：向用户通知失败的组件；可选地，无论如何提交失败的组件；可选地，将组件和风险警告包括在构建中。如图7所示，还可以向用户通知建议的通过应用策略的备选组件等，并且可以选择和使用建议的备选组件而不是失败的组件。组件没通过的通知可以包括组件中识别的风险，这可以帮助确定要使用的更好的组件。
过程801将确定813是否有更多组件要评价以用于构建、提交等；这样的过程通常包括在关于相同应用的单个构建或提交中的多个组件。如果有更多组件要评价(步骤→801)，则过程801将得到815用于构建或提交的下一组件，并且将重复针对下一组件的评价。
如果813没有更多组件要评价以用于构建、提交等，并且如果组件全部通过，则过程801将采取通常的步骤817来提交和/或构建指定的应用。注意，过程801可选地可以采取通常的步骤817提交和/或构建指定的应用，即使在存在没通过的组件时也是如此。如果存在失败的组件，则应用策略可以指定是否无论如何都要构建。
用于提交/构建应用、用于构建最终制品等的通常步骤的技术是已知的。在评价所有组件后，当构建发生(或跳过)时，过程结束817。
在一些变型中，该过程为没通过应用策略的组件存储指纹日志。该过程可以检查对于应用来说不是新的组件是否在没通过应用策略的组件的指纹的该应用日志中，可以跳过利用应用策略来对组件进行评价809，并且采取指定的没通过动作811。
可以保留通过应用策略的组件的日志。
v.示例和变型
以下示例用例，策略管理示例和一些变型非常适用于演示各种实现细节和优点。可以理解的是，该系统可以防止开发人员的不良决定，并且还可以通过提前获得更好的卫生(hygiene)来降低整个开发环境的风险状况。
a.入站用例-新组件通过策略
考虑这样的示例：开发人员请求对于存储库来说是新的组件，并且开发人员不知道该组件通过存储库策略。组件是新的并通过策略的事实对于软件开发人员来说是透明的。
在该示例中，存在利用本文公开的本系统和方法来使用存储库管理器的现有环境。从开发人员的角度来看，开发人员经由例如ide请求可能以前没有被取回到该存储库中的新的组件，并且向开发人员交付组件(因为它通过了策略)。对开发人员透明的是：ide向存储库请求组件，存储库知道它本地没有组件，因此存储库(根据已知技术)从上游存储库得到所请求的组件；然后，在存储库向请求开发人员提供组件之前，本文的系统和方法将评价存储库策略，并且如果组件通过，则通常(根据策略)存储库管理器被允许在本地存储组件，并且向请求该组件的开发人员交付软件组件。当组件通过策略时，本系统和方法对开发人员完全透明。
相比之下，在诸如禁止组件的黑名单之类的常规技术中，由于之前从未被批准的原因，开发人员不被允许取回该组件。然后，开发人员可以请求针对特定组件的触发手动工作流程的权限，而手动工作流程通常很慢，并且由于缺乏自动化和对应的必须执行的手动动作，往往会导致开发效率显著低下。如果权限被授予了，则开发人员将取回组件；但是如果权限没有被授予，则开发人员可以尝试另一版本，或者也许更糟糕的情况，可以尝试通过以其它方式下载组件并不管如何使用它来完全规避常规处理。这种规避行为是相当普遍的做法，因为开发人员只是试图完成他们的工作而未理解到他们可能违反了手动处理。
b.入站用例-新组件不能通过存储库策略
考虑这样的示例：开发人员请求对于存储库来说是新的、并且对于开发人员来说是不知道的组件，并且软件组件对于存储库来说是不可接受的。组件没通过策略的事实被及时通知给软件开发人员，并且在该示例中包括软件组件失败的原因。
在该示例中，再次存在利用本文公开的本系统和方法来使用存储库管理器的现有环境。在该示例中，存储库策略不接受具有mit许可证或严重的安全威胁的软件组件；其它一切都被接受。开发人员将请求软件组件，但开发人员不知道或不关心此软件组件的许可证或安全威胁，或者甚至不知道软件组件是否会在软件存储库中。从开发人员的角度来看，开发人员经由例如ide请求组件的规范版本；向开发人员通知该组件不可接受，因为该组件需要例如mit许可证，并且因为该组件具有严重的安全威胁(组件没通过策略的原因)。对开发人员透明的是：ide向存储库请求组件，存储库(根据已知技术)从上游存储库得到所请求的组件；然后，在存储库向请求开发人员提供组件之前，本文的系统和方法将评价存储库策略，并且如果组件没通过存储库策略，则通常(根据策略)阻止所请求的组件被存储，并且向请对组件的开发人员通知失败和组件不能通过的原因。本系统和方法向开发人员通知组件没通过策略的所有原因，以便开发人员能够及时地对组件做出适当的决定，以更好地避免所请求的软件组件呈现的所有风险。
相比之下，在常规技术中，由于组件是新的的原因，开发人员不被允许取回该组件。然后，开发人员然后请求针对特定组件的许可。如果权限没有被授予，则开发人员可以尝试其它版本。然而，缺少许可可以(或不可以)指示失败的一个原因；开发人员选择的替代版本可以解决一个风险，但其它风险将保留。常规技术鼓励开发人员的绕过请求许可的需要的行为。
c.出站用例-失效保护
通常，开发人员通过经由存储库管理器请求组件从而获得组件，如结合图7所讨论的那样。通常，现在存储在存储库中的入站组件先前已通过存储库策略。然而，对出站组件进行评价，这为绕过入站评价的组件提供了失效保护模式，而绕过入站评价可以由有意规避先前阻止的一个或多个组件的开发人员来进行。
以下示例假设开发人员想要使用特定组件，但由于某种原因，例如通过使用拇指驱动器并将软件组件提交给版本控制系统规避了由入站侧的存储库管理器提供的控制。在该示例中，由开发人员提交的软件组件具有mit许可证和严重的安全威胁。在该示例中，软件存储库策略和应用策略不会通过要求mit许可证或具有严重安全威胁的组件。
当包括提交的组件(具有mit许可证和严重安全威胁)在内的组件集合被发布时，将根据策略评价要被发行的软件。(针对出站案例的策略可以与存储库相关联、或者与整个组织相关联，或者可以与应用相关联、而不一定与整个组织相关联。)因此，在构建应用时，即使规避了入站策略评价，具有mit许可证和严重安全威胁的组件也无论如何都会针对出站策略进行评价。这里，根据出站策略，规避了入站策略的组件是不可接受的。如针对没通过动作的预定义编程步骤所规定的，系统可以提供不可接受的组件的通知，提供组件中发现的风险通知，提供构建有风险的通知，以及可以无论如何都要执行构建和/或可以阻止构建。
相比之下，在常规系统中，许可证是不可接受的、并且构建并入对应的许可证威胁的事实很可能未被注意到，如果真是这样的话，则直到发行应用后导致知识产权风险立即显示为止才可能被注意到。
d.出站用例-典型的
当存在要被发行的应用时，下面假设软件开发处理中的典型场景。众所周知，当开发人员获取组件或二进制资产时，开发人员通常将它们拖入他们的ide(集成开发环境，例如eclipse或id等)中。然后，开发人员更新他们的一些本地源代码，这可能指示依赖于其它二进制资产。在某个时候，开发人员已经准备好将这些组件保存并提交到版本控制系统中。存在一种已知的“持续集成”(ci)技术，在该技术中，自动化处理注意到源代码中的某些内容发生了改变，因此系统知道需要构建该源代码并确保该构建的源代码通过所有测试。ci服务器将提取开发人员提交的源代码以及所需的所有其它相关源代码，构建所有内容，其得到例如应用的一部分或整个应用本身。以ci为软件构建最终制品为例；许多组织将新构建的工件放入存储库管理器中的托管存储库中。在ci构建发生之后的某个时候，本文讨论的系统可以起作用并且评价构建处理本身的整个输出，如结合图8所讨论的。也就是说，任何正在或将要放回到托管存储库中的组件都会针对已建立的策略再次被评价。
e.出站用例-组件没通过
在这种情况下，要发行的应用包括被确定为没通过应用策略的组件。这对软件开发人员来说通常是透明的。遵循上面讨论的处理。不同之处在于：组件没通过应用策略，导致软件组件失败。在本文中的系统中，当软件组件没通过时，系统可以告知存储库管理器向用户通知存储库管理器不能包括该组件，并且可以通知关于所请求的组件为什么失败(例如，出于某些原因的失败的策略)，系统还可以向用户通知补救措施，例如通过建议不失败的软件组件版本(例如，如果所请求的组件中存在安全漏洞，则向开发人员通过所请求的组件的版本是固定的)。然后，开发人员可以指定系统建议的版本，即通知接受的路径，从而在几分钟内确定地解决问题。
f.出站使用案例-发行新的应用版本
在这种情况下，发行新版本的应用。存在与应用相关联的应用策略；应用策略比存储库策略更特定(例如，关于许可和安全)。因此，存储库中存储的组件可以不被新应用接受。该新的应用将根据其特定策略来评价，以确定是否发行(发布)该新的应用。如果任何组件没通过，则针对没通过操作的编程步骤的选项包括以下一项或多项：拒绝发布；或发布警告，说明应用为什么不能通过应用策略(这可以适用于应用仅仅被放入测试环境的情况)；和/或无论如何都要发行软件。
目标是系统预期并导致有意试图规避存储库上的入站控制的开发人员的行为。因此，要包括在应用中的出站组件也被识别为对存储库来说是已知的或未知的。在应用中但未通过防火墙到达的组件被识别为对存储库来说是未知的。应用策略可以指定它不会接受未知组件，例如，在这种情况下应用不能通过策略。
g.出站用例-在新策略下发行旧应用
在这种情况下，旧的应用将在新的或更新后的应用策略下发行。在这种情况下，最终版本被发布回存储库管理器，这将触发本文中讨论的评价。因此，针对新的或更新后的应用策略来评价应用。评价整个应用，并且针对新的或更新后的应用策略评价整个应用中的每个组件。然而，请注意，应用内的内部组件对存储库而言并不是新的，因为之前(针对其它应用)已经遇到过这些内部组件，因此根据存储库策略进行的评价很快。
h.策略管理器使用
在这种情况下，系统包括具有本文讨论的系统的存储库管理器。本文讨论的系统可以与存储库管理器物理服务器一起运行，或者可以在另外的服务器上运行。存储库管理器并入本文所讨论的系统或者与本文讨论的系统集成在一起，因此存储库策略和应用策略的使用对开发人员而言是透明的(直到组件没通过为止)。
用户(可能是系统管理员)希望针对本文中讨论的系统部署一个或多个策略。用户配置存储库策略，可能是为存储库管理器上存在的每个不同代理存储库配置一个存储策略。用户还配置应用策略，为将向其发布组件的每个不同应用配置一个应用策略。
i.变化-软件组件的隔离
在变型中，没通过存储库策略的可能不可接受的组件可被存储在隔离区存储器中，并且可以从隔离区存储豁免而进入到托管存储库中。现在参考图9，图9是示出了软件组件进出隔离区(quarantine)的流的数据流图。图9示出了上游存储库901、具有防火墙的存储库管理器905、其中存储有组件和元数据917的托管存储库915、其中存储有组件和元数据911的隔离区存储和日志909。在图9中所示的一些元件可以与以上结合图2讨论的那些元件相同，这些元件的细节将不再讨论。
组件是入站的或出站的903以便在存储库管理器905处进行评价，如从上游存储库901入站所表示的，但组件可以是任何其它方式，例如，组件是出站的，并且因此实现评价以供存储库管理器905存储。假设具有防火墙的存储库管理器905根据策略确定组件没通过并且因此组件是可能不可接受的软件组件。这里，没通过并且是可能不可接受的软件组件与托管存储库915相隔离地存储907，即存储在隔离区存储器909中，并且隔离区日志909记录软件组件911处于隔离区中。通过这种方式，软件组件与托管存储库分开存储。
提供隔离区豁免过程913，使得隔离区存储器909中存储的失败组件和元数据911可以被移动到而存储在托管存储库915中。在这种情况下，隔离区豁免过程913豁免托管存储库策略，这使得失败的组件917被存储在托管存储库中。例如，隔离区豁免过程913可以通知组件中的风险，和/或要求用户肯定地指示将失败的组件911存储在托管存储库915中。隔离区豁免过程913提供了这样一种方式：无论如何可以将失败的组件(可以是根据其自身的优点评价的)包括在托管存储库中。
j.变化-补救措施
在软件组件没通过策略的任何用例中，系统可以提供补救措施。在提供了补救措施并且软件组件没通过的情况下，系统可以确定非失败的软件组件的版本，例如，具有相同名称但是能够通过策略(应用或存储库策略，取决于哪个策略失败)的软件组件的一个或多个先前版本或之后的版本，例如安全漏洞已经得到修复的版本。然后，开发人员可以指示接受由系统建议的版本。建议的版本已知可以通过策略。这将提供一种在几分钟内确定地解决问题的方法。
通常，针对没通过正在应用的策略的组件来说，不存在通过建议已知通过正在应用的策略的备选版本来提供可能补救措施的开发人员工具。
vi.附加示例实现
本部分将讨论实现的附加具体示例。图10示出了计算机实现。图3至图8的过程中的一个或多个或者组合便利地可以在图10的计算机上实现，或者可以在被适当地配置了的任何另一装置上实现。
现在参见图10，将讨论和描述示出了计算机系统1001的相关部分的框图。计算机系统1001可以包括一个或多个控制器1003、处理器1005、用于比如与网络1007通信的输入/输出(i/o)接口1009、存储器1011、显示器1015(可选的)、和/或用户输入设备(比如，键盘1017)。备选地，或除了键盘1017之外，用户输入设备可以包括各种已知输入设备中的一个或多个，诸如定点设备、键区、计算机鼠标、触摸板、触摸屏、轨迹球和/或键盘。显示器1015表示可以通过常规液晶显示器(lcd)或其它视觉显示器的方式、和/或通过用于播放可听消息的常规可听没备(例如，扬声器)的方式来向用户呈现信息的显示器。计算机系统1001的一些部分对于该领域的技术人员来说是很好理解的，并且为了避免模糊讨论而被省略。
处理器1005可以包括一个或多个微处理器和/或一个或多个数字信号处理器。存储器1011可以耦接到处理器1005，并且可以包括只读存储器(rom)、随机存取存储器(ram)、可编程rom(prom)和/或电可擦除只读存储器(eeprom)。存储器1011可以包括用于存储操作系统、针对由处理器1005执行的程序的数据和变量1033等的多个存储位置；这样的程序可以包括以下项中的一个或多个：提供1035、编辑和/或管理预定义的策略；处理1037入站组件；处理1039出站组件；组件的深度检查1041；遵循1043根据策略的通过动作；遵循1045根据策略的没通过动作；软件开发工具1049、1051、1053、1055；和用于由处理器1005使用的其它信息和/或指令的数据库1057。计算机程序可以被存储在例如rom或prom中，并且可以指示处理器1005控制计算机系统1001的操作。只要这些功能中的每一个在本文件的其它地方没有详述，则这些功能中的每一个都在本文中被更详细地考虑。
响应于来自由键盘1017表示的来自用户输入设备的手动信令，根据存储器1011中存储的指令、和/或在经由i/o接口1009接收到某些信息时自动进行的，处理器1005可以指示执行存储的程序。
计算机1001可以访问其上存储有一个或多个组件(在此由组件1069表示)的软件存储库1067。尽管组件1069被示为通过网络1009而被访问，但是组件1067可以通过有线和/或无线连接从计算机1001远程和/或本地访问；组件1069不需要限于数据库或软件存储库1067。用于访问位于软件存储库1067(例如，托管存储库、代理存储库、上游存储库等)中的组件的技术是已知的。
处理器1005可以被编程以提供1035、编辑和/或管理预定义的策略(这里由预定义策略1071表示)。预定义的策略定义风险和针对风险要采取的动作，如上面更详细的讨论的。预期为软件存储库1067提供预定义的存储库策略；以及如果存在多于一个的存储库，则为每个存储库都提供预定义的存储库策略。存储库策略定义存储库中可接受的风险；预期存储库中包括的组件符合存储库策略。预期为软件存储库1067为其提供组件的一个或多个应用提供预定义的应用策略。对于两个或多个不同的应用，可以有不同的应用策略。以上更详细地讨论了预定义的存储库和应用策略。预定义策略1071可以包括：指示风险与针对每个风险而采取1021的通过或没通过动作之间的对应关系的信息；指示针对动作1023而采取的编程步骤的信息，可选地特定于导致访问预定义策略的强制执行阶段；以及可选地，当组件仅部分地匹配风险时(即，当风险仅对组件的内部组件是已知的时)采取的部分匹配动作1025。
这里由单个预定义策略1071表示的策略可以在评价组件之前经由与用户的交互(例如，通过经由显示器1015显示可选择的编程步骤并且经由键盘1017接收输入)来指定、编辑和/或管理。可以将被定义为针对没通过动作和可选地针对通过动作而采取的编程步骤存储在例如每个动作存储1023的编程步骤中。经由与用户的交互，预定义的策略可以为多个风险中的每一个风险定义动作(例如，通过或失败)，所述动作指示风险是通过了策略还是不能通过策略。风险与动作的表可以存储在风险与动作表1021中。组件查找密钥与风险存储器1019可以存储关于组件的信息(有利地表示为指纹)以及组件已知具有的风险(比如，安全威胁、安全威胁级别、许可证等)。可以针对不同种类的风险提供不同的存储器1019，例如针对安全风险的不同存储器和针对许可证风险的不同存储器。如果遇到未在组件指纹与风险存储中指示的组件，则可以经由已知技术获得关于风险的信息；例如，可以将组件扫描到确定的安全威胁级别；以及创建的这样的信息可以被添加到组件查找密钥与风险存储器1019。在一些实现中，来自组件查找密钥与风险存储器1019的信息可以由信息提供服务提供。
用于产生查找密钥的技术是已知的；示例是任何散列函数技术。众所周知的散列技术包括sha-1、md5和将映射可变长度的输入数据集并输出小数据集(有时称为散列值、散列码、散列总和、校验和或散列)的任何其它技术。只要使用相同的技术来散列正在评价的文件以及与其进行比较的已知文件，则特定的散列函数并不重要。任何已知的或将要开发的技术都可以用于比较散列值并试图找到匹配的散列值。
处理器1005可以被编程以处理1037入站组件。例如，可以确定所请求的组件对于存储库来说是否是新的。对于已存在于存储库中的组件，可以像通常一样将组件传递给请求者。对于对存储库来说是新的的组件，可以确定组件的风险(例如，通过参考组件查找密钥与风险存储器1019)，并且可以根据存储库策略评价风险以确定针对组件而采取的动作。以上对此进行了更详细地讨论。
处理器1005可以被编程以处理1039一个或多个出站组件。在操作中，可以存在旨在在构建或应用中一起使用的一个组件或组件集合。例如，对于这些组件中的每一个，都可以确定该组件对于应用来说是否是新的。对于对应用来说不是新的组件，将像通常那样处理组件。对于对存储库来说是新的组件，可以确定组件的风险(例如，通过参考组件查找密钥与风险存储器1019)，并且可以根据应用策略评价风险以确定针对适用于应用的组件而采取的动作。以上对此进行了更详细地讨论。
此外，在一些实现中，对于被确定为对应用来说是新的出站组件，处理器可以被编程为将组件作为入站组件处理。也就是说，在将组件作为出站组件处理后，处理器可以将组件提交给入站处理器，然后将组件(当它们通过时)存储在存储库存储器中。实际上，预期通过应用策略的大多数或所有出站组件也将通过存储库策略，因为预期应用策略至少与存储库策略一样具有限制性，并且指定存储库策略中的所有风险。然而，可以准备风险仅与存储库策略中指定的风险重叠的应用策略，或与存储库策略完全不同的应用策略。
处理器1005可以被编程用于组件的深度检查1041。在深度检查中，逐层确定组件中的内部组件，并且确定内部组件的风险。然后，集体内部组件的风险可以用作为最外面组件的风险。在大多数实施例中，深度检查1041(如果执行的话)将仅针对系统已知的组件(即，组件指纹不在组件查找密钥与风险存储器1019中)执行；以及对于未知的内部组件，将递归执行深度检查，直到内部组件已知为止或直到没有内部组件是已知的为止。例如在题为“methodandsystemformatchingunknownsoftwarecomponenttoknownsoftwarecomponent”的美国专利no.8,825,689中描述了检查组件内的内部组件的示例。这种组件是部分匹配组件，内部组件的风险被用作外部组件的风险。使用已知技术，可以为部分匹配组件指派关于匹配度为多少的值，例如99％、80％、75％等。策略可以指定针对“部分匹配组件”要采取的部分匹配动作1025，例如，部分匹配组件必须至少90％匹配，否则它将没通过。以上更详细地讨论了这方面。
处理器1005可以被编程以遵循1043根据策略的通过动作。当组件被确定为通过(例如，通过没有任何风险)时，根据所应用的存储库策略或应用策略，然后从存储器中取回每个动作1023的编程步骤。如上所述，编程步骤还可以考虑强制执行的阶段，这可以通过哪个开发人员工具被利用来确定或推断，或者可以使得组件成为入站的或出站的时被指定。通过的组件的编程步骤通常是使得组件像通常那样通过，以便开发人员工具可以照常运行(包括将组件存储在存储库中)。可以提供用户可选择的其它动作，例如通知或记录特定组件通过特定策略。
处理器1005可以被编程以遵循1045根据策略的没通过动作。当根据应用的存储库策略或应用策略确定组件是没通过至少一个风险时，则从存储器取回每个动作1023的编程步骤，可选地与强制执行的阶段相对应。如按照应用策略或存储库策略所指定的，没通过的组件的编程步骤如下所示。
可以用软件开发工具1049、1051、1053、1055对处理器1005进行编程。如在该技术领域中将理解的，软件开发工具在本文中由以下项表示：存储库管理器1049、已知的开发环境(例如，ide)1051、常规构建/发行工具(例如，ci工具)1053、以及使用软件存储库的其它典型的混杂的开发工具1055。存储库管理器1049可以与上面讨论的新颖的功能集成。存储器1011还可以包括在混杂数据库1057中的混杂信息以及本文中未考虑的用于其它程序的常用暂时性存储器和其它指令。
计算机1001可以容纳一个或多个磁盘驱动器或可移动存储器(未示出)。通常，可以存在以下项中的一个或多个：闪速存储器、软盘驱动器、硬盘驱动器、cdrom、数字视频盘、光盘和/或可移动存储设备(比如，usb存储棒)、它们的变型和演进型。通常在不同的计算机配置下，驱动器和可移动存储器的数量和类型可能会有所不同。磁盘驱动器可以是选项，并且为了空间考虑，可以从结合本文描述的处理使用的计算机系统中省略。计算机还可以包括cdrom阅读器和cd记录器，所述cdrom阅读器和cd记录器可以通过总线与由总线结构和协议支持的其它外围设备(未示出)互连。总线可以用作为互连计算机的其它组件的主要信息高速公路，并且可以经由接口连接到计算机。磁盘控制器(未示出)可以将磁盘驱动器连接到系统总线。这些可以是内部的或外部的。处理器1005、存储器1011、磁盘驱动器和/或可移动存储介质被称为“计算机可读存储介质”，并且提供计算机程序和数据的非暂时存储。
应该理解的是，图10是结合功能或资源的逻辑组群来描述的。这些逻辑组群中的一个或多个(例如，深度检查1041的功能)可以从一个或多个实施例中省略，并且提供/编辑和/或管理预定义的策略1035可以被省略和/或在不同的处理器上执行。同样，功能可以被不同的成组、组合或扩充，而不脱离范围。类似地，本描述可以描述各种数据库或数据和信息的集合。在不偏离范围的情况下，数据或信息的一个或多个组群可以被省略、分发、组合或扩充、或者本地和/或远程地提供。
vii.术语表
如本文所使用的术语旨在首先如本领域技术人员在第一级所理解的那样解释软件存储库；以及如果不能在第一级解释，则在支持和管理软件开发的工具的科学领域中的技术人员所理解的第二级进行解释；以及如果不能在第一级和第二级解释，则在计算机科学领域中的技术人员所理解的第三级进行解释；以及如果根据第一级、第二级和第三级都不能解释，则根据通常的词典来进行解释。
权利要求可以使用以下术语，为了本文权利要求的目的，这些术语被定义为具有以下含义。本文档中可以指定其它定义。
本文中使用的术语“字节码”被定义为意指通过翻译输入编程语言而产生的中间操作码，并且然后可以在字节码由虚拟机执行时解释字节码，所述虚拟机具有独立于虚拟机在其上执行的硬件的本地机器代码的自己的指令集。使用“字节码”的计算机语言的示例包括但不限于java、.net、scala、jython、groovy和pascal。
本文中使用的术语“组件”被定义为预先存在的可执行软件的指定版本(有时称为规范版本)，或者是可重复使用的预先存在的自包含软件代码构建块，该自包含软件代码构建块不是准备用于使用的完全独立完成的产品，而是字节码或运行时间可执行码；组件可以是诸如许可证或安全漏洞目标之类的风险的主题。更正式地，作为独立产品一部分的组件可以被理解为这样的一部分自包含代码比特，开发人员不希望将其作为独立产品的一部分来自己编写，因此开发人员使用其功能可能作为另一独立产品的一部分而被审查的先前存在的组件。
组件可以包括多个嵌套的组件自身。例如，打包成war组件的javaweb应用可以包含各种jar组件和javascript库，jar组件和javascript库中的每一个本身就是组件自身。
本文使用的术语“计算机系统”或“计算机”表示有时称为如下项的设备：计算机、膝上型电脑、个人计算机、平板计算机、手持式计算机、智能电话、个人数字助手、笔记本电脑、个人指派平板、服务器、客户端、大型计算机、小型计算机、或其演进及等同物。
“开源”软件在本文中被定义为源代码，源代码允许可选地利用允许修改和派生工作的许可证、利用获取源的广为人知的和索引的手段来以源代码以及编译形式进行分发。
本文中使用的术语“存储库”或“软件存储库”被定义为意指存储软件构建组件(有时被称为“制品”)和用于随后取回的依赖性的电子存储系统，其中本领域技术人员众所周知的过程向所述电子存储系统发布制品，使得由一位软件开发人员制作的制品可供其他软件开发人员进一步使用，以合并为用于构建可以被执行的软件产品的构件块；存储库可以包括计算机服务器，通过该计算机服务器，存储的制品的电子副本可供软件开发人员使用，以被并入为用于构件可以被执行的软件产品的构建块；存储库通常具有唯一的识别符，该识别符指示贡献该制品的软件开发人员(个人或组)。存储库可以是远程或本地的。
常规的软件存储库的示例包括例如但不限于：中心存储库(也称为maven中心)、nugetgallery、rubygems.org、npmjs.org和许多其它的存储库。存储库倾向于依赖于预定义的格式和工具，例如，maven存储库格式、restapi交互、具有用于元数据的格式特定文件的不同目录结构等。
软件存储库通过工具来访问，包括例如但不限于：构建工具，比如maven、gradle、rake、grunt等工具；包管理器，比如npm、nugget、gem等；集成开发环境，比如eclipse、intellij等等。
本文中使用的术语“软件构建”具体被定义为意指如在转换多个组件(可以从存储库中获得的一些组件或全部组件)并且将结果组合到可执行独立计算机程序或软件组件中以供另一软件构建使用的可执行构建程序中预定义的处理，至少包括按照如构建程序中定义的预定顺序的对组件进行编译和将编译后的组件与可能的二进制组件(可以来自存储库)链接。
术语“编译器”在本文中特别用于意指将以编程语言编写的源代码转换成计算机可读的目标语言(通常以二进制代码或字节码的形式)、以便创建可执行程序的计算机程序。
在权利要求中使用的短语“无需人工干预而自动地”被定义为意指该特定步骤发生在该步骤发起之后，直到在该步骤中所述的限制完成为止，而不需要用户向处理器提供输入。
viii.实现和技术说明
上述讨论假设读者有足够的技术背景来理解所提出的观点。本部分提供了一些补充实现和/或技术说明，以讨论可能相关的一些技术信息。
本公开用来通过使之能够实现的方式进一步解释执行一个或多个实施例的最佳模式。本公开还用来加强对其中的创造性原理和优点的理解和认识，而不通过任何方式限制本发明。本发明完全是由所附权利要求限定的，其中包括在本申请的待授权期间进行的任何修改以及所发布的那些权利要求的所有等同物。
还应理解的是，对诸如第一和第二等的关系术语(如果有的话)的使用，仅用于将一个实体、项目或动作与另一个实体、项目或动作区分开来，而不必要求或暗示这些实体、项目或动作之间存在任何实际的这种关系或顺序。注意到，一些实施例可以包括多个处理或步骤，这些处理或步骤可以按照任意顺序执行，除非明确且必要地限制于特定的顺序；即，没有进行如此限制的处理或步骤可以按照任意顺序执行。
许多创造性功能和许多创造性原理在被实现时最好由软件或集成电路(ic)(例如，数字信号处理器及其软件和/或专用ic)支持或者所述软件或集成电路(ic)中得到支持。可以预期：普通技术人员尽管可以花费大量精力并在由例如可用时间、当前技术和经济考虑而激发的情况下做出许多设计选择，但是在由本文公开的构思和原理的指导下，将用最少的试验能够容易地产生这样的软件指令或ic。因此，为了简洁和使模糊原理和构思的任何风险最小化，对这些软件和ic(如果有的话)的进一步讨论将限于关于由示例性实施例使用的原理和构思的要素。
以上已经详细讨论了演示用于控制用于包括软件存储库在内的存储库环境的可能不可接受的软件组件的方法和/或系统的各种实施例。应该进一步注意的是，上述处理可以作为指令而存储在计算机可读存储介质中。当指令例如在从计算机可读存储介质加载后由计算机执行时，执行所述处理。本文中出现的详细描述可以按照在计算机或计算机网络上执行的程序过程来呈现。本文中的这些程序性描述和表示是本领域技术人员用来最有效地将其工作内容传达给本领域其他技术人员的手段。
此外，在某些示例中对实施例的讨论，就好像该实施例由单个站点处的单个开发人员或管理员使用了一样。实施例可以由许多开发人员、管理员和/或相关用户(如果优选的话)在一个或多个站点处使用。
通常将过程设想为导致期望结果的自我一致的步骤序列。这些步骤是需要物理量的物理操纵的步骤。通常(尽管并不一定)，这些量采取能够被存储在非暂时性计算机可读介质上、传送、组合、比较和以其它方式操纵的电或磁信号的形式。主要出于通常使用的原因，在将这些信号称为比特、值、元素、符号、字符、项、数字等时是方便的。然而，应当注意，所有这些和类似的术语将与适当的物理量相关联，并且仅仅是应用于这些量的方便的标记。
此外，所执行的操纵通常以诸如添加、确定或比较之类的术语来提及，这些操纵通常与由操作人员执行的心理操作相关联。尽管本文中的讨论可以考虑使用操作员，但是在大多数情况下，对于执行本文所述的实际功能来说，操作人员不是必须的或期望的；操作是机器操作。
各种计算机或计算机系统可以用根据本文中的教导编写的程序编程，或者可以证明构建更专业的装置来执行所需的方法步骤会更方便。根据本文给出的描述，各种这些机器所需的结构将是显而易见的。
计算机可读存储介质是有形且非暂时性的；计算机可读存储介质可以是存储器或存储设备中的任何一种(例如，上面描述的那些示例)、或者其它可移动或固定存储介质，只要这种计算机可读存储介质是有形且非暂时性的即可。
此外，作为示例而非限制，实施例中涉及的任何通信网络可以包括可以提供无线通信能力和/或利用有线连接(例如，电缆和/或连接器等)的数据和/或分组通信网络。可以使用任何适当的通信协议。
与此相关地体现的计算机和/或系统可以(或可以不)依赖于各种组件的集成，所述各种组件包括(如果合适和/或如果需要的话)作为示例而非限制的以下项：硬件和软件服务器、应用软件、数据库引擎、服务器区域网络、常规防火墙和ssl安全、生产备份系统和/或应用接口软件。作为示例而非限制，实施例可以是基于网络的，并且可以(或可以不)利用诸如互联网或其它网络之类的网络来作为与用户进行任何信息传送的示例性接口。
作为示例而非限制，以上讨论所涉及的一个或多个数据库可以是关系数据库格式，但是也可以使用其它标准数据格式。可选地，各种数据库可以包括能够接收各种标准格式的数据的已知转换系统。
作为示例而非限制，系统的一个或多个显示器可以使用xml结合html显示格式来开发。尽管html和xml可能是优选的显示格式，但是可以利用备选显示格式来与用户交互并获得用户指令。
本公开旨在说明如何塑造和使用根据本发明的各个实施例，而不是限制本公开的真实、预期且合理的范围和精神。本发明仅由所附权利要求限定，因为所附权利要求可以在本专利申请及其所有等同物的待审期间修改。前文的描述不旨在穷尽或将本发明限于所公开的精确形式。鉴于上述教导，多种修改和变型是可能的。对实施例的选择和描述是为了最好地解释本发明的原理及其实际应用，并且使得本领域普通技术人员能够在各种实施例中且在具有各种修改(如适合于预期的特定用途)的情况下利用本发明。当根据公平、合法和公正地赋予的范围进行解译时，所有这些修改和改变都在通过随附权利要求(可在本专利申请的待授权期间进行修改)及其所有等同确定的本发明的范围内。