CN111488578A - 现代应用程序的连续漏洞管理 - Google Patents

现代应用程序的连续漏洞管理 Download PDF

Info

Publication number
CN111488578A
CN111488578A CN202010051878.3A CN202010051878A CN111488578A CN 111488578 A CN111488578 A CN 111488578A CN 202010051878 A CN202010051878 A CN 202010051878A CN 111488578 A CN111488578 A CN 111488578A
Authority
CN
China
Prior art keywords
library
libraries
code
api
risk score
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010051878.3A
Other languages
English (en)
Inventor
S·维鲁尔
A·夏尔马
K·肯根
K·曼尼瓦纳
C·瓦什
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Visa International Service Association
Original Assignee
Visa International Service Association
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Visa International Service Association filed Critical Visa International Service Association
Publication of CN111488578A publication Critical patent/CN111488578A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/552—Detecting local intrusion or implementing counter-measures involving long-term monitoring or reporting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2115—Third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Stored Programmes (AREA)

Abstract

提供对现代应用程序进行连续漏洞管理的设备、方法和系统。可以创建依赖关系树，将第三方库映射到软件包的应用程序中使用的微服务。可以在新的库版本的发行说明和变更日志上使用自然语言处理，以生成受常见漏洞和暴露(“CVE”)扰乱的库列表。可以对受扰乱库进行来自应用程序编程接口(“API”)的多个代码调用。可以对每个受扰乱库列举包括CVE的多个代码调用。可以基于包括CVE的所述多个代码调用为所述API分配风险评分。可以将所述风险评分与阈值进行比较，以引起补救措施的发生，包括将库更新到较新版本以解决CVE问题或生成有关所述受扰乱库的报告。

Description

现代应用程序的连续漏洞管理
背景技术
应用程序服务、微服务和软件包及其API实施方案可以使用许多开源库或第三方库。微服务对其库的功能依赖可能导致现有代码易受新漏洞影响，即使在微服务代码依赖关系保持不变时也是如此。由于与现有库更新的API交互，微服务可能会暴露于之前未知的漏洞。或者，在库更新时微服务可能保持不变，同样形成了将微服务暴露于漏洞的可能性。此外，一些库可能对后续库具有多个依赖关系，从而形成依赖关系树。微服务可能依赖大量功能库，因此产生了更多对API恶意攻击(黑客、未授权使用等)的机会。
通常，开源库中的漏洞会公开报告。根据公开的性质，易受攻击的库可能会成为恶意攻击的主要目标。通常，手动执行API内或微服务实施方案内相关于其依赖关系的漏洞分析和解决，因为很难以自动方式正确地执行此类操作。对API或微服务的每次更新的手动检查都可能耗时且耗尽资源。需要快速标识并解决API内由其对很可能被黑客定为目标的库的依赖引起的任何漏洞的解决方案。
发明内容
实施例提供设备、方法和系统，为现代应用程序的连续和自动漏洞管理提供更强大且更准确的解决方案。根据一些实施例，一种计算机系统可以执行用于保护软件包中的漏洞的方法。所述方法可以包括接收对应于软件包使用的第三方软件的库集合。可以确定来自库集合的受扰乱库列表，其中所述受扰乱库列表中的每个库都受到漏洞的影响。可以确定软件包的应用程序所依赖的来自受扰乱库列表的一个或多个受扰乱库，其中所述应用程序执行来自一个或多个受扰乱库的代码，并且其中所述应用程序调用一个或多个受扰乱库。可以针对一个或多个受扰乱库中的每个库标识包括漏洞的多个代码调用。代码调用可以由软件包的应用程序的应用程序编程接口(“API”)来进行，并且其中针对一个或多个受扰乱库中的每个库内的代码进行代码调用。可以基于多个代码调用为API分配风险评分。可以将API的风险评分与阈值风险值进行比较。响应于风险评分超出阈值风险值，可以针对API调用的每个受扰乱库采取补救措施。
各种实施例可以包括一种非瞬态计算机可读介质，其包括指令，所述指令可由处理装置执行以使所述处理装置通过通信端口接收对应于软件包使用的第三方软件的库集合。可以确定来自库集合的受扰乱库列表，其中所述受扰乱库列表中的每个库都受到漏洞的影响。可以确定软件包的应用程序所依赖的来自受扰乱库列表的一个或多个受扰乱库，其中所述应用程序执行来自一个或多个受扰乱库的代码，并且其中所述应用程序调用一个或多个受扰乱库。可以针对一个或多个受扰乱库中的每个库标识包括漏洞的多个代码调用。代码调用可以由软件包的应用程序的应用程序编程接口(“API”)来进行，并且其中针对一个或多个受扰乱库中的每个库内的代码进行代码调用。可以基于多个代码调用为API分配风险评分。可以将API的风险评分与阈值风险值进行比较。响应于风险评分超出阈值风险值，可以针对API调用的每个受扰乱库采取补救措施。
实施例可以包括一种系统，所述系统包括处理装置、通信端口，以及包括可由处理装置执行的指令的非瞬态计算机可读介质。所述系统可以通过通信端口接收对应于软件包使用的第三方软件的库集合。可以确定来自库集合的受扰乱库列表，其中所述受扰乱库列表中的每个库都受到漏洞的影响。可以确定软件包的应用程序所依赖的来自受扰乱库列表的一个或多个受扰乱库，其中所述应用程序执行来自一个或多个受扰乱库的代码，并且其中所述应用程序调用一个或多个受扰乱库。可以针对一个或多个受扰乱库中的每个库标识包括漏洞的多个代码调用。代码调用可以由软件包的应用程序的应用程序编程接口(“API”)来进行，并且其中针对一个或多个受扰乱库中的每个库内的代码进行代码调用。可以基于多个代码调用为API分配风险评分。可以将API的风险评分与阈值风险值进行比较。响应于风险评分超出阈值风险值，可以针对API调用的每个受扰乱库采取补救措施。
下文详细地描述了本发明的这些和其它实施例。例如，其它实施例涉及与本文中描述的方法相关联的系统、装置和计算机可读介质。
可以参考以下具体实施方式和附图来更好地了解本发明实施例的性质和优点。
附图说明
图1是描绘根据本发明的一些实施例的针对要访问的随后位置的用户行进路径和可用建议的图。
图2描绘根据本发明的一些实施例的执行连续和自动漏洞管理的流程图。
图3A是根据本发明的一些实施例的检测连续漏洞管理中的已知漏洞的流程图。
图3B是根据本发明的一些实施例的测量和报告连续漏洞管理中微服务的安全暴露的流程图。
图4示出根据本发明的一些实施例的可以用于聚合易受攻击的第三方库列表的伪逻辑。
图5示出根据本发明的一些实施例的可以用于测量安全暴露的伪逻辑。
图6是根据本发明的一些实施例的连续漏洞管理系统的框图。
图7是根据本发明的一些实施例用于保护软件包中的漏洞的方法的过程的流程图。
图8描绘可与根据本发明的一些实施例的系统和方法一起使用的实例计算机系统的框图。
术语
术语“应用程序编程接口”(“API”)可以指建立软件应用程序的例程、协议或工具的集合。API可以是各种编程组件之间明确定义的通信方法和交互方法的集合。例如，API可以用于对图形用户界面、操作系统、应用程序、数据库系统、软件库、基于Web的系统或计算机硬件进行编程。单个API可以采用共享同一编程接口的不同库的形式进行多种实现(或者没有一种实现是抽象的)。API可以包括用于例程、数据结构、对象类别、变量和/或远程调用的规范。API的一些实例包括POSIX、Windows API和ASPI。API可以与软件库相关。API可以描述和规定规范，而库是此规则集合的实际实施方案。单个API可以采用共享同一编程接口的不同库的形式进行多种实现。
术语“微服务”可以包括以与其它微服务的集合松散耦合的方式运行以便实施应用程序的服务。例如，视频流服务器可以使用多个微服务向客户端计算机提供视频流服务，其中一个微服务可以提供用户界面前端，另一个微服务可以管理视频数据库，第三个微服务可以管理视频编码等。
术语“常见漏洞和暴露”(“CVE”)可以指已知安全威胁的目录。CVE可以包括在公共域报告的漏洞和暴露。常见漏洞可能是软件代码中的错误，它使攻击者能直接访问系统或网络。例如，漏洞可能允许攻击者冒充具有完全访问权限的超级用户或系统管理员。常见的暴露可能是软件代码或配置中的错误，它使攻击者能间接访问系统或网络。例如，暴露可能使攻击者能秘密收集可以出售的客户信息。CVE可以用于
术语“库”可以指计算机程序使用的非易失性资源的集合，用于开发和实施软件程序和应用程序，通常用于软件开发的一套数据和编程代码。这些可以包括配置数据、程序、脚本、文档、帮助数据、消息模板、预写代码和子例程、类别、值或类型规范。例如，微服务可以依赖许多第三方库以通过调用每个库中的子例程或数据结构来实施微服务的各种功能。
“存储器”可以包括可存储电子数据的任何合适的一个或多个装置。合适的存储器可以包括非瞬态计算机可读介质，其存储可以由处理器执行以实施所要方法的指令。存储器的实例可以包括一个或多个存储器芯片、磁盘驱动器等。此类存储器可以使用任何合适的电、光和/或磁操作模式来操作。
“处理器”可以包括任何合适的一个或多个数据计算装置。处理器可以包括一起工作以实现所要功能的一个或多个微处理器。处理器可以包括CPU，所述CPU包括足以执行用于执行用户和/或系统生成的请求的程序组件的至少一个高速数据处理器。CPU可以是微处理器，例如AMD的速龙(Athlon)、钻龙(Duron)和/或皓龙(Opteron)；IBM和/或摩托罗拉(Motorola)的PowerPC；IBM和索尼(Sony)的Cell处理器；英特尔(Intel)的赛扬(Celeron)、安腾(Itanium)、奔腾(Pentium)、至强(Xeon)和/或XScale；和/或类似处理器。
具体实施方式
各种实施例提供与实施现代应用程序的连续和自动漏洞管理相关的设备、方法和系统。一些实施例通过提供更强大且更快速的解决方案来确定和解决软件包使用的API内的常见漏洞和暴露(“CVE”)，从而解决在更新微服务所依赖的库时可能发生的问题。例如，这可以通过以下方式来完成：(i)确定可能受CVE影响的API内的库列表，(ii)量化可能受CVE影响的多个API以及每个API已受影响的明显程度，以及(iii)提供包括对潜在CVE的量化分析的通知或报告。
更详细地，可以获得第三方库列表并将其映射到微服务内的其依赖关系并随后映射到其API。然后，可以将开源第三方库映射到其相应的源统一资源标识符(“URI”)。这允许本发明在API内映射多服务依赖关系，并将库链接到公开已知的信息(例如，补丁、发行说明、版本或与CVE控制有关的其它信息)。网络爬虫可以用于通过映射的统一资源标识符(“URI”)进行搜索，以确定哪些库具有带更新的较新版本，并且因此可能包括潜在的CVE。此外，在检查是否存在更新版本时，本发明可以确定是否在较新版本的库中断开向后兼容性。
在确定潜在易受攻击微服务的列表后，可以量化带有已知漏洞和其它安全修复的库的量以及每个微服务可能受影响的明显程度。对于每个已知的安全相关修复，本发明可以确定(i)漏洞的严重性，(ii)受影响的代码路径的数量，(iii)是否涉及直接或过渡性依赖关系，以及(iv)带有已知CVE影响API的依赖关系的数量。然后可以使用这些信息来量化因这些漏洞而受影响的业务功能。
例如，可能存在许多依赖关系，包括已知CVE影响API。本发明可以对已知CVE对于每种依赖关系的重要性进行分类或评价。例如，受CVE影响的一个依赖关系可能在代码内被API多次调用，使得每个代码调用都可能产生攻击机会。这种依赖关系将被归类为问题，并且在一些实施例中可以归因于一定程度的关键性或风险评分。另一个依赖关系可能包括已知的CVE，但其代码在API执行时可能不会被调用。本发明可以注意到，这种依赖关系包括CVE，但是由于在代码内执行CVE的风险是最小的或不存在的，因此其风险评分很少或没有。标识为不包括CVE的任何依赖关系均可归属于无风险。然后，实施例可以将量化分析输出为可用于进一步调试、修复或更新库内潜在问题的通知或报告。这种方法可以让组织持续监视应用程序和业务服务的漏洞，并且可以提供风险评分，以根据漏洞的严重性并基于受影响的业务功能来决定是否应做出修复。
I.引言
由于第三方库(尤其是开源库)的依赖性显著增加，攻击面日益扩大，这在现代应用程序中是一个巨大的挑战。对于一组已部署的微服务及其API，这些漏洞的可见性至关重要。此外，在发现漏洞之后，提高可恢复性也很重要。新漏洞实际上可能不是新的安全漏洞，而仅是影响旧的现有代码的新披露的漏洞。这意味着无需变更任何代码即可存在新的已知漏洞。
现代应用程序可能具有大量带直接和过渡性依赖关系的微服务。这可能导致明显的攻击面。攻击者可以越来越多地将开源依赖关系作为目标，因为它们的重复使用为恶意黑客提供了许多受害者。确保实施API的系统的安全性对于确保应用程序整个依赖关系树中没有已知漏洞可能是有益的。对于某一依赖关系中给定的漏洞而言，微服务和API中的暴露水平可能是不知道的。这就需要一种自动方式来主动检测由于第三方依赖关系中发现的漏洞而导致的安全漏洞，并随后修复这些漏洞。
图1是描绘根据一个实例的应用程序、微服务和包括库的第三方信息的依赖关系树的图。应用程序可以利用一个或多个微服务来执行各种功能。微服务可以执行实施一个或多个库的各种功能。例如，应用程序102可以使用微服务104来执行与软件有关的功能。微服务104可以调用存储在第三方库106中的子例程、数据结构、程序、脚本等，以执行或帮助执行微服务功能。
在一些实例中，第三方库106可以依赖于其它库或用作其它库所依赖的依赖库。第三方库106可以具有第三方库版本110，使得第三方库106的不同版本具有不同的代码，其中较新版本通常包括修复以解决以前版本的问题。第三方库106和第三方库版本110可以由第三方库源或供应商108创建、提供、更新或以其它方式管理。对系统内使用的第三方库106的更新可以是自动的，使得第三方库源或供应商108可以实施在发行时生效的“补丁”。通常，对第三方库106的更新是手动的，使得应用程序102或微服务104的管理器或编程器可以选择要实施第三方库106的哪些版本以及何时实施。
当第三方库版本110被自动或手动变更时，可以在依赖于第三方库106的微服务104内创建新的CVE。在微服务104中所得的新创建的CVE可以在应用程序102内创建潜在的漏洞或代码错误。各种微服务可以结合其它库和微服务代码利用第三方库106的各部分，以实现不同的微服务功能。对第三方库版本110的更新可能导致微服务104内的意外代码变更。代码变更可能影响微服务104执行代码的方式。
例如，第三方库源或供应商108可以在考虑特定功能的情况下维护第三方库106。对第三方库版本110的更新可能寻求解决一些依赖的微服务经历过的先前版本中存在的错误或安全风险。一些微服务可能以与打算对第三方库版本110进行更新的大多数微服务不同的能力使用第三方库106。因此，这些异常微服务可能会经历新创建的CVE，因为对第三方库版本110的更新旨在解决其它问题或CVE。作为另一个实例，对第三方库版本110的更新可能设计得很差，对大多数依赖的微服务产生负面影响，并形成一个或多个广泛的CVE。
为了帮助抢先标识CVE或避免对可能导致CVE的库版本的更新，第三方库源或供应商108可以在第三方库版本110内或与所述第三方库版本一起包括发行说明112和变更日志114。发行说明112和变更日志114可以提供对第三方库106的内容所做的变更的详细描述，使得微服务104和/或应用程序102的编程器或管理器可以改变代码(如必要)以与更新的第三方库版本110兼容。在一些实例中，如果微服务104不会调用受版本更新影响的代码，则对第三方库版本110的更新可能不会影响微服务104运行的方式。在此实例中，微服务104不需要被更新以适应版本更新，从而避免了任何新创建的CVE。
标识由对微服务所依赖的第三方库的更新创建的CVE可能是有益的，因为攻击者可能会因CVE的公共性质而更容易利用这些CVE。例如，第三方库106的CVE可以由用户或第三方库源或供应商108标识，并报告为公共知识。攻击者可能知道公共已知的CVE，并试图自动攻击可能已更新为第三方库106的最新带CVE版本的微服务104，或不改变代码以适应第三方库版本110的变更。
通常，已经通过手动诊断和错误检查解决了CVE。例如，编程器可以读取伴随库版本更新的发行说明和变更日志，以确定将影响使用库调用的微服务的哪些部分(如果有)。然后可以对利用库的更新部分的微服务的任何代码进行重新编码，以确保可以在微服务内实施库而不会出现错误或漏洞。在一些实例中，连续集成/构建系统插件可以用来提供微服务代码的静态分析，以确定哪个库、API或微服务的服务受依赖关系树中任何代码变更的影响。但是，确定受影响的代码不会提供可用于确定版本升级是否会严重影响系统的CVE暴露的量化。本发明的实施例提供了用于确定对微服务和/或API代码的CVE影响的量化的解决方案。此量化可以用于确定第三方库是否可以更新为其最新版本，而对应用程序功能和安全性的负面影响很小或没有负面影响。
提供代码静态分析的插件可能遭受额外限制。插件可能导致与病毒软件类似方式的潜在漏洞，使得基于插件库进行任何潜在漏洞的分析。插件不会基于存在问题的API的库检测潜在漏洞，因此无法解决体系结构依赖关系内的任何潜在问题。
实施例可以通过以下方式来解决上述问题：(i)主动检测第三方依赖关系的漏洞；(ii)提供可见性并测量每个应用程序的API(和微服务)的安全暴露；(iii)基于暴露的严重性处理部署应用程序中的漏洞；以及(iv)引起补救措施，例如应对漏洞的通知。本文所公开的现代应用程序的连续和自动漏洞管理的实施例旨在为这些实例以及在尝试管理和维护无损CVE的API时遇到的其它问题提供解决方案。
II.连续漏洞管理
在本节中，提供了用于执行连续和自动漏洞管理的各个步骤的描述。图2描绘根据一个实例执行连续和自动漏洞管理的流程图。在框202中，检测到已知漏洞。这可以包括将每个依赖关系或库映射到应用程序，其中软件包可以包括多个应用程序。可以生成包括CVE的易受攻击库列表。在框204中，测量微服务的安全暴露。使用从框202映射的依赖关系树，可以分析易受攻击库列表，以确定调用包括CVE的每个库的代码以执行软件包的操作的次数。通过累积每个库的带有CVE的代码调用总数，CVE的重要性以及对业务功能的影响，可以为每个库和/或API分配风险评分。风险评分可以表示库容易遭受黑客攻击或安全缺口的潜在机会。在框206中，可以修复包括CVE的库内的漏洞，并且可以生成报告，所述报告包括关于带有CVE和/或高于阈值的风险评分的每个库的信息。基于与阈值相比每个库的风险评分，可以执行补救措施。
A.检测已知漏洞
图3A描绘根据本发明的一些实施例的检测连续漏洞管理中的已知漏洞的流程图。已知漏洞是公开披露的安全漏洞，通常由用户发现和记录，或者由安全研究人员报告。公开将已知漏洞作为攻击者最容易找到和利用的漏洞，因此在管理应用程序及其相应版本的库时解决此问题至关重要。可以创建应用程序依赖关系树的映射，然后将第三方库映射到它们的可用发行说明和变更日志，所述映射可以用于确定所有依赖关系和具有漏洞的受影响的微服务的列表。
在框302中，生成所有第三方库的基准存储库。基准存储库可以包括来自多个公共可用的第三方库(例如，SourceClear知识中心、Mitre的CVE数据库、Ruby咨询数据库、OSS索引等)的库信息。此存储库可以包括所有已知的第三方库列表，以使存储库内的一些库可能不会被正在测试CVE的用户部署的任何应用程序或服务使用。例如，基准存储库可以包括成千上万的第三方库，这些库在各种类型的API中使用，具有各种功能，这些库在公共域内很容易访问。
在框304中，将部署的应用程序映射到其第三方库依赖关系。使用在框302中生成的基准存储库，可以将存储在存储库内的第三方库链接到使用每个第三方库的每个应用程序。例如，存储库可以具有数百个与网络连接相关的第三方库。服务提供商的一个应用程序可以使用这些第三方库的一半，服务提供商的另一应用程序可以仅使用其中一些库。每个主动部署的应用程序都可以映射或链接到可以由应用程序内的任何代码或微服务调用或以其它方式实施的每个第三方库。将已部署的应用程序映射到其第三方库依赖关系可以包括依赖关系版本信息。这可以提供每个应用程序使用的每个第三方库的当前状态的快照。
在框306中，将第三方库映射到其对应的源存储库URI。开源、公共供应商和已关闭的供应商URI可以包括每个第三方库的发行说明和变更日志。将源存储库URI映射到第三方库可以将使用第三方库的已部署应用程序间接链接到源存储库URI。因此，第三方提供的第三方库版本随附的任何发行说明或变更日志都可以链接到每个应用程序。这可以允许每个应用程序与第三方提供的最新发行说明或变更日志的动态和实时关联。例如，如框304中所述，可以将应用程序链接到第三方库，并且可以将应用程序间接链接到与所述库相对应的URI。第三方可以发布有关所述库的URI的更新信息(例如，发行说明、变更日志、更新的库版本)。由于映射到应用程序的库先前已链接到源存储库URI，因此可以使用URI检索第三方库的更新信息，从而无需创建新映射即可检索更新后的信息。
在一些实例中，可以将源存储库URI信息映射到在框302中生成的第三方库存储库内的每个第三方库。这可以通过链接当前CVE分析中可能未使用但可用于未来CVE分析的URI信息来创建更完整的存储库。在一些实例中，源存储库URI信息可以仅映射到被文本化为CVE的应用程序使用的第三方库。通过避免映射与正被检查的应用程序未使用的库相对应的URI信息，可以避免计算资源的消耗。
如框302、304、306中所描述的，基准存储库的生成和依赖关系的后续映射的结果是与图1的依赖关系树类似的依赖关系树。依赖关系树的这种反向映射可以允许分析常规插件无法解决的直接和过渡(transitive)依赖关系，因为它们仅限于自己的库。然后可以分析此依赖关系树及其内容，以确定哪些第三方库已被更新，以及哪些第三方库可能包括系统体系结构内实施的CVE。
在框308中，生成具有任何变更的第三方库列表。对第三方库的变更可以包括漏洞修复、CVE修复或其它代码变更，这些变更可能或可能不会影响应用程序内实施的微服务的功能。网络爬虫可以被编程为自动解析在框306中收集的URI，以确定已从在框302中生成的基准存储库内存储的版本中更改了哪些第三方库(如果有)。例如，网络爬虫可以确定与基准存储库中存储的版本相比，由收集的URI标识的哪些第三方库具有较新的版本。可以将标识为可能具有更新版本的第三方库存储为列表，以分析潜在的CVE。对于CVE分析可以忽略主动使用的不具有网络爬虫访问相应URI所确定的较新版本的第三方库，因为任何潜在的CVE问题都应在之前对API的更新中得到解决。
在框310中，使用已知的漏洞数据库来分析从框302、304、306创建的依赖关系树。可以将源自互联网的已知漏洞数据库用于搜索依赖关系树中的问题，尤其是有关在框308中生成的具有变更的第三方库列表。已知漏洞数据库可以包括已经由各个实体使用第三方库实践和报告的已知CVE所引起的所有错误的列表。可以分析依赖关系树的直接和过渡依赖关系，以确定是否存在任何已知的CVE问题。
可以收集并解析具有在框308中生成的变更的基准第三方库列表的发行说明和变更日志，以进行分析。发行说明和变更日志可以通过自然语言处理(“NLP”)引擎来运行，所述引擎了解软件漏洞修复和漏洞(例如CVE、远程命令执行(“RCE”)等)的语义。与在API中实施的库的当前版本相比，NLP引擎可以用于确定已知CVE是否已在库的较新版本中修复。例如，NLP引擎可以确定第三方库的较新版本未修复API当前使用的第三方库版本中存在的已知CVE。在此实例中，由于新的版本不能解决CVE问题，因此NLP引擎可以确定不从源或供应商处检索第三方库的最新版本。因此，当前版本将不会更新为最新版本。如果NLP引擎确定第三方库依赖关系的较新版本将修复CVE问题，则可以在API中检索并应用较新版本替换库的过时版本。
在框312中，生成易受攻击的第三方库和微服务的列表。可以基于在框310中执行的分析来生成列表。可以基于在框310中执行的NLP分析，将使用NLP引擎处理变更的库版本的发行说明和变更日志的结果制成表格。列表可以包括具有漏洞的所有直接和过渡依赖关系、已修复的相应版本，以及记录更新的库版本中所做的任何变更的日志。列表还可以包括由于易受攻击的直接和过渡依赖关系而受到潜在漏洞影响的所有微服务和API。或者，可以生成受影响的微服务或API的单独列表。
在框314中，在第三方库的当前版本与新的版本之间执行向后兼容性检查。可以针对依赖关系的当前版本检查具有修复或变更的依赖关系的任何新版本的向后兼容性变更。这样可以确保对第三方库的较新版本的更新不会破坏现有的API。在一些实例中，当建议使用更新来修复已知的CVE时，可以使用向后兼容性工具来确定更新依赖关系是否会导致API破坏。如果预料对依赖关系的较新版本的更新会导致API的破坏，则可以建议手动更改依赖关系代码以解决预料的破坏。可以自由更新经确定没有会导致破坏的兼容性变更的依赖关系，而不会出现问题。如框312所述，可以在标识易受攻击的第三方库和微服务的列表之后自动执行框314。例如，可以使用诸如APIDIFF工具之类的工具来执行向后兼容性分析[2]。
图4示出根据一些实例的可以用于聚合易受攻击的第三方库列表的伪逻辑。产品可以是包括一个或多个微服务的任何软件包(例如，许可给第三方的软件包)。在一些实例中，库可以具有较新的版本，可以解决在每个产品内的微服务中正在实施的当前版本或基准版本的问题。
伪逻辑可以包括在框308、310、312和314中描述的过程。行408可以包括“对于(for)”循环逻辑的初始化，使得在确定库已更新时执行由行410到424提供的逻辑的剩余部分。在图3A的框308和310中描述了库已更新以及应执行for循环逻辑的确定。如果库已更新，则可以执行伪逻辑的行410以获取发行说明和变更日志，其可以对应于图3A的框310所描述的过程。行412可以对应于框310的NLP，其可以确定是否存在由较新的库版本修复的任何CVE或安全问题。除了如框310中描述的检查CVE之外，实施例还可以检查非CVE问题，例如安全问题。安全问题可以是除CVE之外的任何错误或潜在易受攻击的部分。例如，安全问题可能不是已知漏洞，因此不是CVE，但可能是特定于依赖关系的安全漏洞的孤立实例，其中依赖关系的更新版本可能会寻求解决所述安全问题。
行414可以对应于图3的框314中描述的过程，所述过程描述了执行向后兼容性检查。可以在行418和420处执行框312，其包括当重复行408的for循环时，获取每个易受攻击库的信息，然后生成易受攻击库列表，向所述列表添加新的易受攻击库。行426和430包括跨用于每个产品的所有微服务创建总的易受攻击库列表。因此，从行406开始的for循环确定微服务中的每个库是否已更新或有新版本可用，并且行404的for循环为产品内的每个微服务执行行406的for循环。行402的for循环可以顺序执行所有伪逻辑，以确定跨每个产品的每个微服务已更新了哪些库。
B.测量微服务的安全暴露
在确定微服务依赖于具有已知漏洞的第三方库(如框302到314中所确定)之后，可以确定CVE的范围。在框312中创建易受攻击的第三方库和微服务的列表之后，可以对由CVE产生的问题进行量化，以评估出现CVE的微服务中有多少API受到影响。可以将这种量化与由于受扰乱的API而受影响的业务功能的量相关。可以运行各种测试套件以确定依赖关系漏洞影响哪些代码路径和哪些API。可以生成报告以显示每个微服务中受影响的API和受影响的代码路径。可以根据以下因素向受CVE影响的每个API分配风险评分：包括漏洞的严重性、每个API的问题所影响的代码路径的数量、受影响的依赖关系是直接依赖关系还是过渡依赖关系，以及具有会影响API的已知CVE的依赖关系的数量。
风险评分可以与微服务或API相关联，这取决于受CVE影响的一个或多个第三方库。可以使用风险评分来确定是对受CVE扰乱的依赖关系实施更新，还是对包括CVE但功能显著更新的较新版本进行更新。例如，当涉及CVE的代码调用数量较高时，与依赖关系相关的风险评分就较高。当涉及CVE的代码调用数量较少时，与依赖关系相关的风险评分就较低。被确定为大于某个阈值级别的风险评分可能导致提供采取某些措施来减轻风险的建议(例如更新依赖关系版本，提供具有高风险评分原因的通知报告)。
图3B是根据一些实例的测量和报告连续漏洞管理中微服务的安全暴露的流程图。在框316中，可以运行一个或多个测试套件，以测量CVE对受影响的微服务和API的冲击的特征。测试软件套件可以用于测试微服务调用的代码路径。当测试覆盖率较高时，测试套件的应用可以提高CVE冲击的测量特性的准确性。例如，当应用程序中的大多数代码路径由测试套件测试时，测试覆盖率可能会较高。当测试套件测试的代码路径太少时，测试覆盖率可能会较低。测试覆盖率太低可能无法全面描述应用程序中CVE的冲击。
可以与测试套件一起运行代码拦截器。可以为每个受影响的易受攻击库创建名称空间。可以将充当代码挂钩的拦截器植入受影响的库的代码中，以使得记录执行名称空间的任何代码。可以在数据库中记录在由拦截器标识和检索的名称空间中执行的代码。这可以允许量化名称空间中所述特定代码的代码调用数量。量化测试期间代码调用的数量可以确定与每个名称空间相对应的哪个代码(如果有)产生更高的漏洞或暴露风险。对于以下实例，假设测试覆盖率较高(例如90％)。在一个实例中，与带有CVE的代码在测试期间仅被调用一次相比，带有CVE的代码调用可能被多次调用，这可能会产生更高的安全风险。在测试套件运行期间，微服务可能永远不会调用带有多个CVE的代码，因此对安全的威胁甚至更低。没有CVE的代码调用不会对安全构成威胁。
在框318中，确定CVE冲击的风险级别。在运行测试套件以记录数据库内的每个代码挂钩之后，可以分析收集到的代码挂钩信息的数据库，以确定哪些API受代码调用影响以及为每个API调用名称空间的次数。通过分析API在名称空间执行代码的次数，可以确定对每个API的总体冲击。基于受影响的API以及在微服务中实施这些API的频率，特定服务的应用程序可以归属于某个风险评分。例如，具有易受攻击依赖关系的API可以在一个使用实例(例如，业务应用程序)中产生高风险评分，而同一API可能在另一个使用实例中产生较低风险评分。可以基于业务环境中应用程序的上下文来分配相应应用程序的风险评分。例如，在付款选项中添加信用卡可能比发送确认已收到货运的确认更为关键，因此尽管在两个上下文设置中都使用了受影响的API，但可能会被赋予更高的风险评分。
可以存在各种阈值级别以对受影响的微服务进行分类。阈值级别可以是API调用执行CVE的库代码的最大次数。例如，低阈值可以具有较高数量的可允许受影响代码调用，中等阈值可以具有较低数量的可允许受影响代码调用，而较高阈值可以具有甚至更低数量的可允许受影响代码调用。在一些实例中，可以根据业务应用的上下文为某些代码调用赋予优先级。例如，可以将API的风险评分加倍，以相比其它API为所述特定API分配更多权重。根据应用程序的上下文，这可以使某些API功能的优先级高于其它API。然后可以将属性权重与给定的阈值级别进行比较，以确定API使得微服务处于低、中或高风险。如本领域技术人员所理解的，除了低、中和高风险外，还可以使用其它类别。
如果受影响的API冲击级别下降到阈值(例如，百分比)以下，以致API的实施方案不会对应用程序的功能构成重大的安全威胁，则不采取任何措施。如果受影响的API冲击级别大于API可能构成重大安全威胁的阈值，则确定是否将API的受影响依赖关系的当前版本更新为最新版本。
在一些实例中，可以以相关技术领域的技术人员可以想到的任何数量的方式来确定阈值。依赖关系树的任何部分(例如，软件包、应用程序、微服务、API、库等)可以被赋予与依赖关系树的另一部分有关的阈值。例如，可以为应用程序分配50％的阈值，这样，如果在应用程序内调用的50％或更多的库带有CVE，则可以采取一些补救措施来提供包括有关CVE信息的通知或将阈值级别降低到可接受的操作水平。可以向依赖关系树的各个部分分配不同的阈值级别。继续上一个实例的具有阈值级别为50％的应用程序，在软件包操作中使用的另一个应用程序的阈值级别为20％。在一些实例中，
在一些实例中，可以确定在测试期间未调用的代码。存储代码调用的数据库可以为每个名称空间初始化零值。如果从未调用特定名称空间的代码，则在运行各种测试套件后，数据库中所述代码的属性值可以为零。这可意味着不需要为API调用的所述库的代码进行更新，因为它既不有害也不有利于API的操作。
图5示出根据一些实例的可以用于测量安全暴露的伪逻辑。所述伪逻辑可以包括框316和318中描述的过程。在一些实例中，可以为易受攻击库列表内的每个依赖关系确定检测到的漏洞的名称。
在行502和504处，可以生成微服务、API和第三方库的映射或依赖关系树。可以使用在框302中收集的库，根据图3A的框304中描述的过程来生成依赖关系树。在行506处，可以使用行502和504中映射的依赖关系以及图4的伪逻辑来创建漏洞库列表。可以执行行508的for循环，以分析易受攻击库列表中的每个元素(例如，易受攻击依赖关系内的代码部分)。行510和512可以包括图3B的框316中描述的用于在易受攻击库代码中实施代码挂钩的过程，以确定微服务调用受CVE扰乱的一部分代码的次数。代码挂钩可以收集有关调用某个API的频率和时间以衡量冲击的度量。例如，代码挂钩可以增加API调用的计数，以用于确定冲击等级或权重。后挂钩可以写入文件或其它数据存储区，以保存例如针对API和/或受影响的业务产品或服务的API调用计数之类的信息。此存储的信息可用于计算总体风险和冲击。行514的for循环可以运行带有测试套件的软件构建，以捕获受冲击的API的冲击百分比(例如，风险评分)，包括CVE名称和其它与CVE相关的信息。可以由图3B的框318中的过程来描述行514的for循环。
C.修复漏洞并生成报告
在框320中，确定有风险的依赖关系是否稳定且向后兼容。使用在框302到312中产生的微服务依赖关系版本映射，可以标识所有需要修补或升级的处于风险中的已部署微服务，如框316和318中所述。可以分析具有在框318中确定的风险评分大于阈值的依赖关系的微服务，以确定应执行何种措施来解决风险。与框314中描述的过程类似，可以使用API代码比较工具(例如，APIDIFF工具[2])来确定第三方库的当前版本与新的版本之间的向后兼容性。
在框322中，基于依赖性版本的稳定性和向后兼容性，采取补救措施来处理风险依赖关系。如果所述受影响的依赖关系的新版本的向后兼容性被破坏或没有可用的修复程序，则可以生成通知或报告以将受影响的依赖关系版本、CVE问题以及其它相关信息传达给相关用户。此报告可以帮助基于受影响的API评估受影响的业务功能的风险。此评估可以通过更改业务流程来避免受影响的API，从而帮助决策修复问题还是控制问题。在没有向后兼容性问题的实例中，可以根据受影响的应用程序和微服务的类型采取措施。如果没有下游依赖关系，则可以将微服务回滚到先前的稳定版本。否则，可以将微服务更新为依赖关系的修复版本。这可以触发运行测试套件和功能测试的持续集成构建，并提供可在生产中部署的连续交付管道。在一些实例中，修复可以包括将受影响的依赖关系的当前版本更新为具有较低风险评分的依赖关系的另一版本，使得另一版本仍可能包括CVE问题。
III.连续漏洞管理系统
图6描绘根据一个实例的连续漏洞管理系统的框图。连续漏洞管理系统600可以包括处理器602、总线604、通信端口606和存储器608。可以将图6中的处理器(例如，处理器602、总线604、通信端口606和存储器608)集成到单个结构中。例如，组件可以在单个外壳内。在其它实例中，图6中示出的组件可以分布(例如，在单独的外壳中)并且彼此电连通。连续漏洞管理系统600可以执行由本公开的各种实施例描述的用于连续漏洞管理的任何功能，执行过渡正则化非负矩阵分解并提供顺序建议。
处理器602可以执行一个或多个操作以实现一些实例。处理器602可以执行存储在存储器608中的指令以执行操作。处理器602可以包括一个处理装置或多个处理装置。处理器602的非限制性实例包括现场可编程门阵列(“FPGA”)、专用集成电路(“ASIC”)、微处理器等。
处理器602可以经由总线604通信地耦合到存储器608。非易失性存储器608可以包括在断电时保留所存储的信息的任何类型的存储器装置。存储器608的非限制性实例包括电可擦除可编程只读存储器(“EEPROM”)、闪存或任何其它类型的非易失性存储器。在一些示例中，存储器608中的至少一些可以包括介质，处理器602可以从所述介质读取指令。计算机可读介质可以包括能够向处理器602提供计算机可读指令或其它程序代码的电子、光学、磁性或其它存储装置。计算机可读介质的非限制性实例包括(但不限于)磁盘、存储器芯片、ROM、随机存取存储器(“RAM”)、ASIC、配置的处理器、光存储装置或计算机处理器可以从中读取指令的任何其它介质。指令可以包括由编译器或解释器从以任何合适的计算机编程语言(包括例如C、C++、C#等)编写的代码生成的处理器特定指令。
CVECVE数据库618可以包括在整个公共域中已知的CVE的列表，包括与每个CVE有关的任何信息。库数据库620可以包括使用URI可标识和可检索的任何第三方库。在一些实例中，CVE数据库618和库数据库620可以是存储库和CVE信息的单个数据库。库数据库620可以是由包括私有库的供应商维护的私有数据库。通信端口606可以与CVE数据库618对接，以将有关CFA的信息传输到连续漏洞管理系统600。通信端口606可以与库数据库620对接，以将与第三方库有关的信息(例如发行说明，变更日志)传输到连续漏洞管理系统600。通过总线604将通信端口606接收的CVE和库信息传送到存储器608。存储器608可以存储任何接收到的浓度分布和任何接收到的感官信息。
存储器608可以包括发行说明和变更日志数据库610，以存储库的每个版本的发行说明和变更日志。存储器608可以包括用于自然语言处理引擎612、代码比较模块614以及网络爬虫模块616的程序代码。自然语言处理引擎612可以使用NLP来确定与在API中实现的库的当前版本相比，已知CVE是否已经在库的较新版本中修复。当建议更新来修复已知的CVE时，代码比较模块614可以用来确定更新依赖关系是否会导致API破坏。网络爬虫模块616可以使用URI来定位和检索公共域中的库内容和版本数据。
连续漏洞管理系统600的组件可以用来实施描述的实例，包括图3A和3B中描述的过程流。例如，可以根据框302中描述的过程来生成当前库的存储库。库数据库620可以与连续漏洞管理系统600的通信端口606进行通信。例如，库数据库620可以是位于连续漏洞管理系统600远程的服务器，在服务器上可以通过互联网建立组件之间的通信。通信端口606可以接收可以存储在存储器608中的库和与库有关的信息。网络爬虫模块616可以用于搜索包括库数据库620在内的公共域，以确定微服务使用的任何库是否已更新或是否具有可用更新。此过程可以包括在图3A的框308描述的过程中。
库数据库620可以包括可以存储在发行说明和变更日志数据库610中的发行说明和变更日志。如图3A的框310所述，NLP可以用来分析存储在发行说明和变更日志数据库610中的信息。与在API中实施的库的当前版本相比，可以使用自然语言处理引擎612来确定已知CVE是否已在库的较新版本中修复。可以将有关已知CVE的信息从CVE数据库618传递到通信端口606，以由自然语言处理引擎612进行分析。通过分析发行说明和变更日志，自然语言处理引擎612可以生成如图3A的框312中描述的易受攻击的第三方库和对应微服务的列表。
代码比较模块614可以用来比较依赖关系的当前版本的代码与从库数据库620导出并存储在存储器608中的依赖关系的较新版本。存储器608可以包括每个软件包中的每个微服务所依赖的每个当前使用的库的数据库。代码比较模块614可以执行逐行语法分析，以确定每个库的代码的哪些部分已被更改。区分库的当前版本与较新版本可用于确定较新版本是否与当前版本向后兼容，如图3A的框314和图3B的框320中所述。确定向后兼容性是否可用可以允许连续漏洞管理系统600提供建议，以不将库的当前版本更新为库的较新版本以防止破坏微服务。
在一些实例中，可在存储器608内创建已知CVE的本地存储库，以减少生成受影响的依赖关系和微服务的列表时的处理时间。例如，可以从CVE数据库618和其它静态源(例如vulmon.com)收集互联网上已知的漏洞数据库，并将其存储在存储器608中的综合数据库中。在本地访问数据库，而不是通过互联网传达CVE更新，可以缩短处理时间。可以通过间歇性地或按需轮询互联网上已知漏洞数据库的变更来使包含CVE的本地数据库成为当前数据库。
IV.连续漏洞管理方法
图7是根据一个实例的用于保护软件包中的漏洞的方法的过程流程图。软件包可以使用计算机系统执行。可以根据以前的实例描述连续漏洞管理的一些流程。
在框702中，接收对应于软件包使用的第三方软件的库集合。软件包可以具有取决于库的数量的多个微服务。库可以从第三方供应商处采购，并存储在计算机系统的数据库中。
在框704中，确定来自库集合的受扰乱库列表。受扰乱库列表中的每个库都可能受漏洞影响。在一些实例中，可以通过在计算机系统的数据库中存储库集合中的每个库的URI来确定受扰乱库列表。网络爬虫可以基于每个库的URI在公共域中搜索受扰乱库列表中的每个库的较新版本。与较新版本相关联的发行说明和变更日志可以存储在数据库中。可以使用计算系统的自然语言处理器引擎来分析发行说明和变更日志，以便从受扰乱库列表中确定一个或多个可修复库。可修复库的较新版本可以消除或减少可修复库的当前版本中漏洞的冲击。
在框706中，确定软件包的应用程序所依赖的来自受扰乱库列表的一个或多个受扰乱库。应用程序可以执行来自一个或多个受扰乱库的代码，并且可以调用一个或多个受扰乱库以执行软件包的操作。
在框708中，标识包括漏洞的多个代码调用。可以针对一个或多个受扰乱库中的每个库确定多个代码调用。可以通过软件包的应用程序的API来进行代码调用。可以对一个或多个受扰乱库中的每个库的代码进行代码调用。可以运行测试套件，以确定软件包中的API调用每个依赖库中受CVE影响的代码的每一部分的次数。
在框710中，基于多个代码调用为API分配风险评分。API的风险评分取决于API所依赖的每个库的敏感性。例如，API可以使用多个库来调用代码。这些库中的这些代码均不包括CVE，因此可以为API分配较低风险评分或不分配风险评分。作为另一个实例，这些库可能具有带CVE的代码，但是API不会调用代码的这些已受扰乱的部分。因此，可以为API分配较低风险评分或不分配风险评分。作为另一实例，API可以调用来自包括CVE的库的代码。包括API对库进行的CVE在内的更多代码调用会增加分配给API的风险评分。在一些实例中，分配风险评分可以包括确定来自与应用程序相关的一个或多个受扰乱库的每个库的依赖关系。例如，直接依赖关系的风险评分可以与过渡依赖关系的风险评分不同。较高风险评分可以指示发生安全缺口的几率较高，而较低风险评分可以指示发生安全缺口的几率较低。
在框712中，将API的风险评分与阈值风险值进行比较。可以根据所描述的实例分配阈值风险值。
在框714中，响应于风险评分超出阈值风险值，针对API调用的每个受扰乱库采取补救措施。补救措施可以包括生成含有关受扰乱库的信息的报告，更新库版本和/或将库版本还原为向后兼容版本。可以采取补救措施来报告库中CVE的存在或解决CVE。在一些实例中，可以生成报告，所述报告包括受扰乱库的列表、API的风险评分以及关于库的较新版本不向后兼容的通知。可以将报告传输到由实施应用程序的用户操作的一个或多个用户装置。在一些实例中，可以使用计算机系统的代码区分工具针对一个或多个受扰乱库中的每个库将库的较新版本的代码与库的当前版本的代码进行比较。作为比较的结果，可以确定较新版本不与当前版本向后兼容。
V.计算机系统
图8描绘可与根据一个实例的系统和方法一起使用的实例计算机系统的框图。
本文中所提及的任何计算机系统都可以利用任何合适数量的子系统。在图8中的计算机设备800中示出了这种子系统的实例。在一些实施例中，计算机系统包括单个计算机设备，其中子系统可以是计算机设备的组件。在其它实施例中，计算机系统可以包括具有内部组件的多个计算机设备，每个计算机设备都是子系统。计算机系统可以包括台式电脑和笔记本电脑、平板电脑、移动电话和其它移动装置。
图8中所示的子系统经由系统总线815互连。示出了诸如打印机814、键盘818、存储装置819、耦合到显示适配器820的监视器816等等的额外子系统。耦合到输入/输出(I/O)控制器811的外围设备和I/O装置可以通过本领域中已知的各种构件连接到计算机系统，所述构件例如是输入/输出(I/O)端口817(例如USB、
Figure BDA0002371460910000191
)。例如，I/O端口817或外部接口821(例如，以太网、Wi-Fi等)可用于将计算机设备800连接到例如互联网的广域网、鼠标输入装置或扫描仪。经由系统总线815的互连允许中央处理器813与每个子系统进行通信，并控制来自系统存储器812或存储装置819(例如，诸如硬盘驱动器或光盘之类的固定盘)的指令的执行，以及子系统之间的信息交换。系统存储器812和/或存储装置819可以具体化为计算机可读介质，其可以是非瞬态计算机可读介质。本文所提及的任何数据都可以从一个组件输出到另一组件，并且可以输出给用户。
计算机系统可以包括，例如，由外部接口821或由内部接口连接在一起的多个相同部件或子系统。在一些实施例中，计算机系统、子系统或设备可以通过网络通信。在此类情况下，一个计算机可以被视为客户端，且另一计算机可以被视为服务器，其中每台计算机可以是同一计算机系统的部分。客户端和服务器可以各自包括多个系统、子系统或组件。
应理解，本发明的实施例中的任一个都可以使用硬件(例如专用集成电路或现场可编程门阵列)和/或使用计算机软件以控制逻辑的形式实施，其中通用可编程处理器是模块化的或集成的。如本文中使用，处理器包括单核处理器、在同一集成芯片上的多核处理器，或在单个电路板上或联网的多个处理单元。基于本文中所提供的公开内容和教示内容，本领域的普通技术人员将知道并了解使用硬件及硬件与软件的组合来实施本发明的实施例的其它方式和/或方法。
本申请中所描述的任何软件组件或功能可以被实施为由处理器使用例如Java、C、C++、C#、Objective-C、Swift的任何合适计算机语言或例如Perl或Python的脚本语言并使用例如常规的或面向对象的技术执行的软件代码。软件代码可以作为一系列指令或命令存储在用于存储和/或传输的计算机可读介质上，合适的介质包括随机存取存储器(RAM)、只读存储器(ROM)、诸如硬盘驱动器或软盘的磁介质或诸如光盘(CD)或DVD(数字通用光盘)的光学介质、闪存等等。计算机可读介质可以是此类存储或传输装置的任何组合。
此类程序还可以使用适于经由包括互联网的符合多种协议的有线、光学和/或无线网络进行传输的载波信号来编码和传输。因此，根据本发明的实施例的计算机可读介质可以使用用此类程序编码的数据信号来创建。以程序代码编码的计算机可读介质可以与兼容装置一起封装或与其它装置分开地提供(例如，经由互联网下载)。任何此类计算机可读介质可以驻存于单个计算机产品(例如，硬盘驱动器、CD或整个计算机系统)上或内，且可以存在于系统或网络内的不同计算机产品上或内。计算机系统可以包括用于将本文中所提及的任何结果提供给用户的监视器、打印机或其它合适的显示器。
本文中所描述的任何方法可以完全或部分地用计算机系统来执行，所述计算机系统包括可被配置成执行各步骤的一个或多个处理器。因此，实施例可以涉及被配置成执行本文中所描述的任何方法的步骤、可能具有执行相应步骤或相应步骤群组的不同组件的计算机系统。尽管以带编号的步骤呈现，但是可以同时或以不同的顺序执行本文中的方法的步骤。另外，这些步骤的部分可以与其它方法的其它步骤的部分一起使用。此外，步骤的全部或部分可以是任选的。另外，任何方法的任何步骤可以用模块、电路或用于执行这些步骤的其它手段来执行。
在不偏离本发明的实施例的精神和范围的情况下，具体实施例的特定细节可以任何适当方式组合。然而，本发明的其它实施例可以涉及与每个单独方面或这些单独方面的特定组合相关的特定实施例。
上文对本发明的实例性实施例的描述已经出于说明和描述的目的呈现。其不希望是详尽的，或将本发明限于所描述的精确形式，并且根据上文的教示，许多修改和变化是可能的。选择和描述这些实施例是为了最好地解释本发明的原理及其实际应用，从而使本领域的技术人员能够在各种实施例中最好地利用本发明，并且进行适合于预期的特定用途的各种修改。
除非特别指出相反的情况，“一个”、“一种”或“所述”的叙述旨在表示“一个或多个”。除非明确指示有相反的意思，否则“或”的使用旨在表示是“包括性的或”，而不是“排他性的或”。提到“第一”组件并不一定要求提供第二组件。而且，除非明确指出，否则提到“第一”或“第二”组件并不将提到的组件限制到特定位置。术语“基于”旨在表示“至少部分地基于”。
本文中提到的所有专利、专利申请、公开和描述出于所有目的以全文引用的方式并入本文中。并非承认它们是现有技术。
VI.参考
[1]Ibrahim,S.、Bashah Idris,N.、Munro,M.以及Deraman,A.，(未注明出版日期)。支持变更影响分析的需求可追溯性(A REQUIREMENTS TRACEABILITY TO SUPPORTCHANGE IMPACT ANALYSIS)。
[2]Brito,A.、Xavier,L.、Hora,A.以及Valente,M.T.，(2018年)。Java开发人员断开API的原因及方式(Why and how Java developers break APIs)。2018年IEEE第25届软件分析、演变和再工程国际会议(SANER)。doi:10.1109/saner.2018.8330214
[3]Fenton,C(2017年10月03日)。如何检查漏洞的开源代码(How to Check OpenSource Code for Vulnerabilities)-DZONE安全。检索自https://dzone.com/articles/how-to-check-open-source-code-for-vulnerabilities。

Claims (9)

1.一种用于保护软件包中的漏洞的方法，所述方法包括由计算机系统执行以下操作：
接收对应于所述软件包使用的第三方软件的库集合；
确定来自所述库集合的受扰乱库列表，其中所述受扰乱库列表中的每个库都受到漏洞的影响；
确定所述软件包的应用程序所依赖的来自所述受扰乱库列表的一个或多个受扰乱库，其中所述应用程序执行来自所述一个或多个受扰乱库的代码，并且其中所述应用程序调用所述一个或多个受扰乱库；
针对所述一个或多个受扰乱库中的每个库标识包括所述漏洞的多个代码调用，其中代码调用由所述软件包的所述应用程序的应用程序编程接口(API)来进行，并且其中针对所述一个或多个受扰乱库中的每个库内的代码进行所述代码调用；
基于多个代码调用为所述API分配风险评分；
将所述API的所述风险评分与阈值风险值进行比较；以及
响应于所述风险评分超出所述阈值风险值，针对所述API调用的每个受扰乱库引起补救措施。
2.根据权利要求1所述的方法，其进一步包括：
在所述计算机系统的数据库中存储所述库集合内的每个库的统一资源标识符(“URI”)；
使用由所述计算机系统实施的网络爬虫，基于每个库的所述URI，在公共域中搜索所述受扰乱库列表中的每个库的较新版本；以及
在所述数据库中存储与所述较新版本相关联的发行说明和变更日志。
3.根据权利要求1所述的方法，其进一步包括：
使用所述计算系统的自然语言处理器引擎分析发行说明和变更日志，以从所述受扰乱库列表中确定一个或多个可修复库，其中可修复库的较新版本消除或减少了所述漏洞在所述可修复库的当前版本中的影响，
其中所述补救措施包括将所述可修复库的所述当前版本更新为所述可修复库的所述较新版本。
4.根据权利要求1所述的方法，其进一步包括：
使用所述计算机系统的代码区分工具，针对所述一个或多个受扰乱库中的每个库，将库的较新版本的代码与所述库的当前版本的代码进行比较；以及
响应于所述代码区分工具的所述比较，确定所述较新版本不与所述当前版本向后兼容。
5.根据权利要求4所述的方法，其进一步包括：
生成报告，所述报告包括所述受扰乱库列表、所述API的所述风险评分，以及所述较新版本不向后兼容的通知；以及
将所述报告传输到由实施所述应用程序的用户操作的一个或多个用户装置。
6.根据权利要求1所述的方法，其中分配风险评分包括确定来自所述一个或多个受扰乱库的每个库相对于所述应用程序的依赖关系，其中针对直接依赖关系的风险评分与针对过渡依赖关系的风险评分的分配不同。
7.根据权利要求1所述的方法，其中较高风险评分指示发生安全缺口的几率较高，而较低风险评分指示发生安全缺口的几率较低。
8.一种计算机程序，其包括指令，所述指令在由处理装置执行时使所述处理装置执行如权利要求1-7中任一项所述的方法。
9.一种系统，其包括：
处理装置，
通信端口，以及
非瞬态计算机可读介质，其包括指令，所述指令可由所述处理装置执行以执行权利要求1-7中任一项所述的方法。
CN202010051878.3A 2019-01-28 2020-01-17 现代应用程序的连续漏洞管理 Pending CN111488578A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/259,960 2019-01-28
US16/259,960 US11481498B2 (en) 2019-01-28 2019-01-28 Continuous vulnerability management for modern applications

Publications (1)

Publication Number Publication Date
CN111488578A true CN111488578A (zh) 2020-08-04

Family

ID=69326399

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010051878.3A Pending CN111488578A (zh) 2019-01-28 2020-01-17 现代应用程序的连续漏洞管理

Country Status (4)

Country Link
US (1) US11481498B2 (zh)
EP (1) EP3693874B1 (zh)
CN (1) CN111488578A (zh)
SG (1) SG10201912351QA (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112416757A (zh) * 2020-11-03 2021-02-26 前海飞算云智软件科技(深圳)有限公司 组件开发方法、装置、存储介质及电子设备
CN113139192A (zh) * 2021-04-09 2021-07-20 扬州大学 基于知识图谱的第三方库安全风险分析方法及系统
CN113360955A (zh) * 2021-06-16 2021-09-07 深圳市雪球科技有限公司 一种Applet管理方法、装置和服务器
CN114461252A (zh) * 2022-03-08 2022-05-10 牡丹江浪联网络科技有限公司 基于大数据漏洞分析的软件服务升级方法及互联网ai系统
CN113360955B (zh) * 2021-06-16 2024-06-04 深圳市雪球科技有限公司 一种Applet管理方法、装置和服务器

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11960609B2 (en) * 2019-10-21 2024-04-16 Snyk Limited Package dependencies representation
US11100239B2 (en) * 2019-05-06 2021-08-24 Sap Se Open source library security rating
US11210404B2 (en) * 2019-06-14 2021-12-28 Netiq Corporation Blockchain-based state verifications of software component vulnerability database for software products
US11422917B2 (en) * 2019-07-26 2022-08-23 Red Hat, Inc. Deriving software application dependency trees for white-box testing
US11704414B2 (en) * 2020-04-29 2023-07-18 Jpmorgan Chase Bank, N.A. Systems and methods for managing vulnerability data
US11470159B2 (en) * 2020-08-28 2022-10-11 Cisco Technology, Inc. API key security posture scoring for microservices to determine microservice security risks
US20220083667A1 (en) * 2020-09-16 2022-03-17 At&T Intellectual Property I, L.P. Open Source Software Security Vulnerability Prioritization Scheme
US20220156383A1 (en) * 2020-09-17 2022-05-19 Dynatrace Llc Method And System For Real Time Detection And Prioritization Of Computing Assets Affected By Publicly Known Vulnerabilities Based On Topological And Transactional Monitoring Data
EP4226240A1 (en) * 2020-10-09 2023-08-16 Conektto, Inc. Natural language processing of api specifications for automatic artifact generation
CN112434305B (zh) * 2020-12-07 2024-03-08 北京中科微澜科技有限公司 基于补丁的漏洞检测方法、装置、存储介质和电子设备
US11831688B2 (en) * 2021-06-18 2023-11-28 Capital One Services, Llc Systems and methods for network security
US20230036739A1 (en) * 2021-07-28 2023-02-02 Red Hat, Inc. Secure container image builds
US11775290B2 (en) * 2021-08-06 2023-10-03 Fujitsu Limited Detection of API backward compatibility across software versions
US11893116B2 (en) 2021-08-19 2024-02-06 Bank Of America Corporation Assessment plug-in system for providing binary digitally signed results
US11805017B2 (en) 2021-08-19 2023-10-31 Bank Of America Corporation Systems and methods for identifying and determining third party compliance
US11546218B1 (en) 2021-08-30 2023-01-03 Bank Of America Corporation Systems and methods for bi-directional machine-learning (ML)-based network compatibility engine
WO2023038957A1 (en) * 2021-09-08 2023-03-16 Lacework, Inc. Monitoring a software development pipeline
CN116028057A (zh) * 2021-10-27 2023-04-28 北京字节跳动网络技术有限公司 代码管理的方法和装置
CN114143110B (zh) * 2021-12-08 2024-04-26 湖北天融信网络安全技术有限公司 一种拟态设备的漏洞处理方法、装置及系统
CN114168972B (zh) * 2021-12-15 2024-05-03 东北大学 一种npm生态系统安全漏洞阻塞点的检测与修复方法
US20230237158A1 (en) * 2022-01-24 2023-07-27 Dell Products L.P. Method and system for detecting vulnerabilities of an installed application before a computing device gets affected
CN117131514B (zh) * 2023-10-25 2024-04-09 中汽智联技术有限公司 一种车联网供应链安全漏洞预警方法、系统和存储介质

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1739552A1 (en) * 2005-06-21 2007-01-03 Hewlett-Packard Development Company, L.P. Software installation method and computer system
JP4722730B2 (ja) 2006-03-10 2011-07-13 富士通株式会社 セキュリティ管理プログラム、セキュリティ管理装置、およびセキュリティ管理方法
KR101478134B1 (ko) * 2012-02-29 2015-01-26 주식회사 팬택 모바일 디바이스의 파일 관리 방법 및 이를 이용한 모바일 디바이스
CN105989283B (zh) * 2015-02-06 2019-08-09 阿里巴巴集团控股有限公司 一种识别病毒变种的方法及装置
US10614223B2 (en) 2015-05-28 2020-04-07 Micro Focus Llc Security vulnerability detection
US9703961B2 (en) * 2015-06-05 2017-07-11 Accenture Global Services Limited Process risk classification
US10277620B2 (en) * 2016-09-08 2019-04-30 Corax Cyber Security, Inc. Determining an assessment of a security breach for an asset of a network infrastructure
US10505981B2 (en) * 2016-11-03 2019-12-10 RiskIQ, Inc. Techniques for detecting malicious behavior using an accomplice model
US10678513B2 (en) * 2017-09-12 2020-06-09 Devfactory Fz-Llc Library upgrade method, apparatus, and system

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112416757A (zh) * 2020-11-03 2021-02-26 前海飞算云智软件科技(深圳)有限公司 组件开发方法、装置、存储介质及电子设备
CN112416757B (zh) * 2020-11-03 2021-11-12 前海飞算云智软件科技(深圳)有限公司 组件开发方法、装置、存储介质及电子设备
CN113139192A (zh) * 2021-04-09 2021-07-20 扬州大学 基于知识图谱的第三方库安全风险分析方法及系统
CN113139192B (zh) * 2021-04-09 2024-04-19 扬州大学 基于知识图谱的第三方库安全风险分析方法及系统
CN113360955A (zh) * 2021-06-16 2021-09-07 深圳市雪球科技有限公司 一种Applet管理方法、装置和服务器
CN113360955B (zh) * 2021-06-16 2024-06-04 深圳市雪球科技有限公司 一种Applet管理方法、装置和服务器
CN114461252A (zh) * 2022-03-08 2022-05-10 牡丹江浪联网络科技有限公司 基于大数据漏洞分析的软件服务升级方法及互联网ai系统
CN114461252B (zh) * 2022-03-08 2022-09-16 广东三鼎实业集团有限公司 基于大数据漏洞分析的软件服务升级方法及互联网ai系统

Also Published As

Publication number Publication date
US11481498B2 (en) 2022-10-25
SG10201912351QA (en) 2020-08-28
US20200242254A1 (en) 2020-07-30
EP3693874B1 (en) 2022-10-19
EP3693874A1 (en) 2020-08-12

Similar Documents

Publication Publication Date Title
CN111488578A (zh) 现代应用程序的连续漏洞管理
US11593492B2 (en) Assessment and analysis of software security flaws
US8613080B2 (en) Assessment and analysis of software security flaws in virtual machines
US10824521B2 (en) Generating predictive diagnostics via package update manager
US8209564B2 (en) Systems and methods for initiating software repairs in conjunction with software package updates
AU2010364976B2 (en) Repairing corrupt software
US11748487B2 (en) Detecting a potential security leak by a microservice
US20080209567A1 (en) Assessment and analysis of software security flaws
US8381036B2 (en) Systems and methods for restoring machine state history related to detected faults in package update process
US9880832B2 (en) Software patch evaluator
US9116802B2 (en) Diagnostic notification via package update manager
US10740464B2 (en) Self-scanning of deployed software applications
US20190361788A1 (en) Interactive analysis of a security specification
Mitropoulos et al. Dismal code: Studying the evolution of security bugs
Lombardi et al. From DevOps to DevSecOps is not enough. CyberDevOps: an extreme shifting-left architecture to bring cybersecurity within software security lifecycle pipeline
CN110990249B (zh) 代码扫描结果处理方法、装置、计算机设备及存储介质
George et al. A preliminary study on common programming mistakes that lead to buffer overflow vulnerability
US11880470B2 (en) System and method for vulnerability detection in computer code
Lee et al. On designing an efficient distributed black-box fuzzing system for mobile devices
Pashchenko Decision Support of Security Assessment of Software Vulnerabilities in Industrial Practice
US20230224317A1 (en) Software security discovery
Murshed An investigation of software vulnerabilities in open source software projects using data from publicly-available online sources.
Sulthana Controlling vulnerabilities in open-source libraries through different tools and techniques
Pietikäinen et al. Steps Towards Fuzz Testing in Agile Test Automation
Oser et al. arXiv: Evaluating the Future Device Security Risk Indicator for Hundreds of IoT Devices

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination