Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
In the remarks filed on 03/31/2026. The applicant amended claims 1, 2, 4, 5, 8, 9, 11,12, 15, 16, 18, and 19 have been amended. Claim 20 has been cancelled. Claim 21 has been added.
With respect to claim objections :
Applicant’ claim amendments and remarks filed on 03/31/2026 have been fully considered and overcame the claim objections as presented in the non-final office action filed 01/27/2026. Therefore, objections have been withdrawn.
With respect to 35 U.S.C. §112 rejections:
Applicant’ claim amendments and remarks filed on 03/31/2026 have been fully considered and overcame the 112(b) rejections as presented in the non-final office action filed 01/27/2026. Therefore, 112(b) rejections have been withdrawn.
With respect to 35 U.S.C. § 103 rejections:
Applicant's arguments filed on 03/31/2026 have been received and entered.
Applicant's arguments with respect to the newly amended independent claims, see Applicant Arguments 10-13, with respect to the rejection (s) of independent claims 1,8 and 15 have been fully considered.
Applicant argues that neither Holz nor Lewandowski teaches “detecting, by monitoring a vulnerability database for an update, at least one new vulnerability that has been added to the vulnerability database” and further argues that the cited references fails to teach determining that a second code repository is impacted based on previously extracted metadata, without performing either an additional build process or a vulnerability scan on the second code repository. Examiner respectfully disagrees. As set forth in the rejection, Lewandowski teaches receiving vulnerability updates from a vulnerability repository and matching the updated vulnerability information against dependency declarations. In particular, Lewandowski teaches that a detection agent receives a vulnerability update from a central repository, such as vulnerability repository which may provide a feed of new vulnerabilities, and that the detection agent identifies corresponding dependencies by matching dependency names and version numbers between the newly identified vulnerable dependency and dependency declarations, see [0055-0056]. Therefore, Lewandowski teaches or at least suggests detecting a newly identified vulnerability from a vulnerability repository and determining whether stored dependency information corresponds to the newly identified vulnerability.
Applicant further argues that neither Holz or Lewandowski teaches updating a configuration file associated with the second repository to remediate the vulnerability without changing source code. This argument is not persuasive. Lewandowski teaches that dependency declaration may be files identifying the name and version number of dependencies used by an application build, [0021] and further teaches that the defect manager service can identify a more recent version of vulnerable dependency and can provisionally update the application build to include the more recent version or generate a suggestion to include the more recent version, [0026]. Lewandowski teaches updating a dependency declaration/build configuration file to remediate a vulnerability by changing dependency version information without requiring modification of application source code.
Applicant further argues that Lewandowski is limited to a single application build The rejection does not rely on Lewandowski alone for plurality of repositories rather Lewandowski is relied upon for extracting and storing dependency name/version information from build related files, receiving vulnerability updates, matching vulnerable dependency information against dependency declarations, and updating dependency version information in a file. Holz teaches corelating vulnerabilities across multiple source codes/applications. Applicant argues neither Holz and Lewandowski teaches determining that as second code repository is impacted based on metadata previously extracted from second build process, making the second repository determination “without performing either an additional build process or a vulnerability scan on the at least one second code repository” and newly added claim 21. Examiner understand applicant’s perspective but are moot because the claim amendment introduces new claim limitations that have not previously been considered. Therefore, the new 103 ground of rejection relies on new references in combination as presented below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 7-11, 14-18 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Holz (US 20180157842 A1) in view of Lewandowski (US 20230281316 A1) in further view of Velur (US 20200242254 A1).
Regarding claim 1, A computer-implemented method comprising:
maintaining at least one database associated with a plurality of code repositories (Holz, A source code repository and management (SCRAM) system. The SCRAM system stores entries for a plurality of source codes, each source code being mapped to contributor information identifying individual persons or organizations that contributed to the creation of the source code, and consumer information identifying individual persons or organizations that utilize the source code in one or more applications implemented by the consumer (i.e., a plurality of code repositories), [0012]. The SCRAM system stores and tracks versions of source code, identifies code authors associated with code submissions, identifies other source code packages used by a particular application development project, [0034] Entries in the repository vulnerability cataloging system storage for correlating the application scanner identified security vulnerabilities with the consumer/contributor information may comprise a variety of different types of information stored in corresponding data structures. For example, each entry may comprise specific location information for identifying the specific location of the vulnerable code, identifiers of the contributors and consumers associated with the vulnerable code, a Common Vulnerabilities and Exposures (CVE) # or other standard identifier associated with the security vulnerability, the location or actual remediation of code/patches/etc. for the security vulnerability, [0036] Portions of the source code repository 140 may also be provided on one or more other network attached storage devices or systems, such as storage system 106, or in one or more databases or other computing devices not explicitly shown in FIG. 1, [0064]) [Examiner interprets that SCRAM system storing multiple source codes and tracking versions of source code (i.e., a plurality of code repositories) as maintaining at least one database associated with a plurality of code repositories];
a first build process associated with a first code repository of the plurality of code repositories, extracting metadata related to the first code repository and storing the extracted metadata in the at least one database (Holz, The SCRAM system stores entries for a plurality of source codes (i.e., a plurality of code repositories), each source code (i.e., a first code repository) being mapped to contributor information identifying individual persons or organizations that contributed to the creation of the source code, and consumer information identifying individual persons or organizations that utilize the source code in one or more applications implemented by the consumer (i.e., metadata), [0012]. FIG. 3, the source code repository and management (SCRAM) system 310 comprises logic that maps various types of source code 312-316 with identifiers of consumers 320 and contributors 322 and generates an application mapping data structure 318 that maintains that mapping. The application mapping data structure 318 is updated dynamically as new contributors 322 and consumers 320 of source code 312-316 are identified by the SCRAM system 310. The source code originates from various sources including internal source code 312 which is generated by users, employees, programmers, or the like, employed by an organization that implements the security vulnerability amalgamation engine or external sources such as open source 314 or even third party sources 316, where a third party source is an organization that provides their source code in exchange for financial compensation as opposed to open source code which is available without financial compensation being required, [0088] the security vulnerability amalgamation engine and/or SCRAM system provides the logic of automatic checkout of new versions of source code that specifically remediates the vulnerabilities found in previous source code of the same project or package registered in the SCRAM system and continuous delivery of secure source code is by automated testing (i.e., continuous delivery environment), [0109]) [Examiner interprets that hooking into a code integration event or new code version check in due to update in new contributors as detecting build process and mapping identifiers of each source code repositories and storing relevant information such as location, contributors, versions etc. as for vulnerability scanning and correlation as a first build process associated with a first code repository of the plurality of code repositories, extracting and storing metadata related to the first code repository in the at least one database];
determining that at least one second code repository of the plurality of code repositories is impacted by the at least one new vulnerability (Holz, the data processing system corelates the characteristics of the security vulnerability with second source code of a second application (i.e. at least one second code repository) based on the association of the characteristics of the security vulnerability with the first portion. It generates output to a computing device of a consumer or contributor associated with the second source code identifying a presence of the security vulnerability in the second source code based on the correlation. The method provides correlation of security vulnerabilities across multiple source codes (i.e., at least one second code repository of the plurality of code repositories) based on the detection of the security vulnerability in a first portion of a first source code, [0009] The method allows users of source code security scanners to view overarching security vulnerabilities caused by common code (e.g., frameworks, libraries, copied and pasted code, etc.) across their portfolio of source code for various applications.) and correlate security vulnerabilities in source code with various instances of that source code present in a plurality of applications, potentially across multiple organizations, development teams, or the like, with regard to developers, maintainers, and customers or users of the applications, and further correlates the instances of that source code with the identified security vulnerabilities with individuals or organizations associated with those instance, [0030] [Examiner interprets that taking the vulnerabilities data from the first source code, checking metadata in the SCRAM system to correlate if any other projects or source code shares the common code and has the similar vulnerabilities as determining that at least one second code repository of the plurality of code repositories is impacted by the at least one new vulnerability]; and
initiating one or more automated actions to at least partially remediate the at least one new vulnerability in the at least one second code repository; wherein the method is performed by at least one processing device comprising a processor coupled to a memory; wherein the method is performed by at least one processing device comprising a processor coupled to a memory (Holz, Improved data processing method identifies code vulnerabilities in source code and amalgamates instances of vulnerabilities across projects, as well as identifying individuals responsible for the instances and notifying them of the security vulnerabilities and potential solution, [0001] The method provides correlation of security vulnerabilities across multiple source codes (i.e., at least one second code repository of the plurality of code repositories) based on the detection of the security vulnerability in a first portion of a first source code, [0009] It automatically scans code for a plurality of applications and identifies a security vulnerability in the source code of an application component of one of those applications such as , e.g., the portion of source code, such as a function, class, method, routine, sub-routine, and associates with the other application and information about the presence of the security vulnerability in the identified applications is provided to personnel/organizations (e.g., users, consumers, and/or contributors) associated with the applications, based on a correlation of personnel/organization information with the identified applications, [0029] The fix for the security vulnerability is automatically pushed to the individuals or organizations for implementation into their instances of the source code where the security vulnerability is present, [0031] a check-in and checkout procedure is employed in which when a contributor remediates a previously identified security vulnerability in source code, an automated check-in/checkout procedure to distribute the remediated source code to contributors/consumers of the previous source code having the identified security vulnerability, [0108] A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements, [0126]) [Examiner interprets that system corelating the characteristics of the security vulnerability with second source code of a second application (i.e. at least one second code repository) and automatically fixing or mitigating security vulnerabilities by performing actions such as pushing updated code, sending patches, modifying references, initiating communications etc. as limitation above].
Although, Holz teaches a build process associated with a first code repository of the plurality of code repositories, extracting metadata and storing the metadata related to the first code repository in the at least one database [Holz: 0012,1090] and also teaches automated actions to remediate vulnerability in additional code repository [Holz:0031,0108], Holz does not appear to explicitly teach:
in response to detecting a build process extracting metadata and storing the extracted metadata in the at least one data base; detecting, by monitoring a vulnerability database for an update, at least one new vulnerability that has been added to the vulnerability database; in response to detecting the at least one new vulnerability, determining that the at least one new vulnerability impacts the first code repository of the plurality of code repositories, wherein the determining comprises searching the stored metadata in the at least one database; determining that at least one second code repository of the plurality of code repositories is impacted by the at least one new vulnerability based at least in part on metadata previously extracted from a second build process associated with the at least one second code repository and stored in the at least one database for the at least one second code repository wherein the determination that the at least one second code repository of the plurality of code repositories is impacted by the at least one new vulnerability is made without performing either an additional build process or a vulnerability scan on the at least one second code repository; initiating one or more automated actions, wherein the one or more automated actions comprise updating a configuration file associated with the at least one second code repository to at least partially remediate the at least one new vulnerability in the at least one second code repository without changing source code in the at least one second code repository;
However, Lewandowski teaches:
in response to detecting a build process extracting metadata and storing the extracted metadata in the at least one data base (Lewandowski, identification of security vulnerabilities (e.g., for dependencies in a software application build) can instead be done as part of a regular software development pipeline (e.g., a continuous integration (CI) pipeline). Specialized software agents (e.g., pipelines) can be integrated with a build management tool to listen for relevant events, including the addition of new dependencies, version changes in dependencies, and the identification of new security vulnerabilities for dependencies (e.g., in the NVD or another suitable repository), [0014] the application build 102 is managed by a build management server 110, which includes a vulnerability tracking repository 120 (e.g., a source control repository). A change to the application build 102 is committed (e.g., propagated to a source control repository), generating a commit 104. The commit 104 is transmitted to the build management server 110, [0017] the dependency tracking service 112 analyzes the commit 104 to identify changes to dependencies. For example, the dependency tracking service 112 can parse files in the commit 104 (e.g., a changelog), can parse files identified by the commit 104 (e.g., application build files), or can analyze any other suitable information. The dependency tracking service 112 can identify new dependencies added to the application build 102 (e.g., added by the commit 104) or changes to dependencies in the application build 102 (e.g., new versions of dependencies in the application build 102)., [0019] the dependency declarations 122A-N can be individual files that identify the name and version number for dependencies used by the application build 102, can be entries in one or more files that identify the name and version number of dependencies, or can take any other suitable form, [0021] a dependency tracking service detects a new dependency added to a build… The dependency tracking service can identify added dependencies in the commit (e.g., scanning modified or new build files, reviewing changes in the commit, or using any other suitable technique), [0034]) [Examiner interprets that system extracting dependency name , dependency version (i.e., repository metadata) in response to build related commit, and storing in the vulnerability tracking repository as in response to detecting a build process extracting metadata and storing the extracted metadata in the at least one data base];
detecting, by monitoring a vulnerability database for an update, at least one new vulnerability that has been added to the vulnerability database (Lewandowski, FIG. 5, identifying and resolving newly discovered security vulnerabilities for a software application build, At block 502 a detection agent (e.g., the new dependency detection agent 132 or the version change dependency detection agent 134, both illustrated in FIGS. 1-2) receives a vulnerability update from a central repository (e.g., the vulnerability repository 140 illustrated in FIG. 1) can track vulnerabilities in dependencies. The central repository can notify the detection agent of newly discovered vulnerabilities (e.g., by providing a feed of new vulnerabilities), At block 504, the detection agent identifies corresponding dependencies. For example, the detection agent can receive a new vulnerability notification identifying a dependency with a vulnerability (e.g., identifying the name and version number of the dependency). The detection agent can review entries in a vulnerability tracking repository (e.g., the dependency declarations 122A-N illustrated in FIGS. 1-2), and identify any dependencies with the newly identified vulnerability. For example, the detection agent can match dependency names and version numbers between the newly identified dependency and the dependency declarations, [0055-0056]) [Examiner interprets that vulnerability repository such as NVD detecting newly discovered vulnerabilities and identifying any dependencies with the newly identified vulnerability as limitation above].
in response to detecting the new vulnerability, determining that the new vulnerability impacts the first code repository of the plurality of code repositories, wherein the detecting comprises searching the stored metadata in the at least one database (Lewandowski, At block 504, the detection agent identifies corresponding dependencies. For example, the detection agent can receive a new vulnerability notification identifying a dependency with a vulnerability (e.g., identifying the name and version number of the dependency). The detection agent can review entries in a vulnerability tracking repository and identify any dependencies with the newly identified vulnerability. For example, the detection agent can match dependency names and version numbers between the newly identified dependency and the dependency declarations, [0056] At block 508, the detection agent commits a change adding the vulnerability for the dependency. For example, the detection agent can modify the dependency declaration in the vulnerability tracking repository to add identifying information for the vulnerability. This can include, for example, an identifier, a short description, a link (e.g., an Internet address) to further details on the vulnerability, or any other suitable information. Alternatively, or in addition, the detection agent adds a new entry to the vulnerability tracking repository describing the vulnerability, adds a new entry to another repository describing the repository, or takes any other suitable action. The flow then returns to block 506, and the detection agent determines whether additional newly vulnerable dependencies exist, [0058]) [Examiner interprets that system searching stored dependency declarations (name version metadata stored in the vulnerability tracking repository) to identify matching dependencies for a newly identified vulnerability as limitation above].
the one or more automated actions comprise updating a configuration file to partially remediate the at least one vulnerability without changing source code (Lewandowski, the application build 102 can include a description of source code files to include in the build, library files to include in the build, runtime files to include in the build, and any other suitable files to include in the build. The application build 102 can include a listing of dependencies used by the software application build. This can include libraries and runtimes used by the build, along with any other suitable dependencies, [0016] the dependency declarations 122A-N can be individual files that identify the name and version number for dependencies used by the application build 102, can be entries in one or more files that identify the name and version number of dependencies, [0021] the defect manager service 150 can take steps to automatically resolve the vulnerability. For example, the defect manager service 150 can identify a more recent version of the dependency with the vulnerability (e.g., using the vulnerability repository 140, through an Internet search, or using any other suitable technique). The defect manager service 150 can automatically download the more recent version of the dependency, and can provisionally update the application build 102 to include the more recent version or generate a suggestion for an administrator or engineer to include the more recent version of the dependency in the application build 102, [0026] the dependency declaration can be a file in the vulnerability tracking repository, and can include a name and version number for the dependency. The dependency tracking service can update the version information for the dependency in the file. This is merely one example, and the dependency declaration can take any suitable form (e.g., an additional declaration to an existing file) include any suitable information (e.g., an identifier, a uniform resource locator (URL) or other Internet address, or any other identifying information), [0046]) [Examiner interprets that updating dependency version information of dependency declarations/build artifacts (i.e., configuration file) to resolve vulnerability as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Holz to include a concept of in response to in response to detecting a build process extracting metadata and storing the extracted metadata in the at least one data base; detecting, by monitoring a vulnerability database for an update, at least one new vulnerability that has been added to the vulnerability database; in response to detecting the at least one new vulnerability, determining that the at least one new vulnerability impacts the first code repository of the plurality of code repositories, wherein the determining comprises searching the stored metadata in the at least one database; the one or more automated actions comprise updating a configuration file to partially remediate the at least one vulnerability without changing source code as taught by Lewandowski for the purpose of resolving newly discovered security vulnerabilities for a software application build [Lewandowski :0055] by identifying new vulnerabilities associated with the version of the dependency, modifying the dependency declaration to add identifying information for the new vulnerability, removing any dependency declarations in the vulnerability tracking repository identifying vulnerabilities associated with a prior version of the dependency to cure a security vulnerability [Lewandowski :0050-0051].
Holz and Lewandowski does not explicitly teach:
determining that at least one second code repository of the plurality of code repositories is impacted by the at least one new vulnerability based at least in part on metadata previously extracted from a second build process associated with the at least one second code repository and stored in the at least one database for the at least one second code repository wherein the determination that the at least one second code repository of the plurality of code repositories is impacted by the at least one new vulnerability is made without performing either an additional build process or a vulnerability scan on the at least one second code repository;
However, Velur teaches:
determining that at least one second code repository of the plurality of code repositories is impacted by the at least one new vulnerability based at least in part on metadata previously extracted from a second build process associated with the at least one second code repository and stored in the at least one database for the at least one second code repository (Velur, performing continuous and automatic vulnerability management according to one example. In block 202, known vulnerabilities are detected. This can include mapping each dependency, or library, to an application, where a software package can include multiple applications. A list of vulnerable libraries containing CVEs can be generated. In block 204, the security exposure of microservices is measured. Using the dependency tree mapped from block 202, the list of vulnerable libraries can be analyzed to determine how many times each library's code containing a CVE is called to perform operations of the software package, [0038] In block 304, deployed applications are mapped to their third-party library dependencies. Using the baseline repository generated in block 302, the third-party libraries stored within the repository can be linked to every application that uses each third-party library. For example, the repository can have hundreds of third-party libraries related to network connectivity. One application of a service provider may use half of those third-party libraries, and another application of the service provider may only use a few of those libraries. Each actively deployed application can be mapped, or linked, to each third-party library that is called or otherwise implemented by any code or microservice within the application. Mapping the deployed applications to their third-party library dependencies can include dependency version information, [0042] The result of the generation of the baseline repository and subsequent mapping of dependencies as described in blocks 302, 304, 306 is a dependency tree similar to that of FIG. 1. This reverse mapping of the dependency tree can allow for analysis of direct and transitive dependencies that conventional plug-ins are not able to address, since they are limited to their own libraries. This dependency tree and its contents can then be analyzed to determine which third-party libraries have been updated and which possibly contain CVEs as implemented within a system architecture, [0045] In block 310, the dependency tree created from blocks 302, 304, 306 is analyzed using known vulnerability databases, [0047] The list can also include all of the microservices and APIs affected from the potential vulnerabilities due to the vulnerable direct and transitive dependencies, [0049] Using the microservices-dependencies-versions mapping that was produced in block 302 through 312, all the deployed microservices at risk that need to be patched or upgraded can be identified.., [0067]) [Examiner interprets that system teaching stored dependency version mappings across multiple applications/microservices and identifying all the affected microservices/applications from those mappings as limitation above].
wherein the determination that the at least one second code repository of the plurality of code repositories is impacted by the at least one new vulnerability is made without performing either an additional build process or a vulnerability scan on the at least one second code repository (Velur, Manual inspection for each update of an API or microservice can be time-consuming and resource draining, [0002] New vulnerabilities may not actually be new security holes, but instead only newly disclosed vulnerabilities that impact old, existing code. This means new known vulnerabilities could exist without making any code changes, [0027] Since the library mapped to the application was linked to the source repository URIs previously, the updated information for the third-party library may be retrieved using the URIs, such that a new mapping does not need to be created to retrieve the updated information, [0043] This dependency tree and its contents can then be analyzed to determine which third-party libraries have been updated and which possibly contain CVEs as implemented within a system architecture, [0045] In block 310, the dependency tree created from blocks 302, 304, 306 is analyzed using known vulnerability databases, [0047] a determination is made as to whether an at-risk dependency is stable and backwards compatible. Using the microservices-dependencies-versions mapping that was produced in block 302 through 312, all the deployed microservices at risk that need to be patched or upgraded can be identified.., [0067] A local database containing CVEs can be made current by polling the known vulnerability databases on the Internet for changes intermittently or on demand, [0077]) [Examiner interprets that system using previously create/stored dependency mappings and known vulnerability database updates to determine affected applications/microservices as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Holz and Lewandowski to include a concept of determining that at least one second code repository of the plurality of code repositories is impacted by the at least one new vulnerability based at least in part on metadata previously extracted from a second build process associated with the at least one second code repository and stored in the at least one database for the at least one second code repository wherein the determination that the at least one second code repository of the plurality of code repositories is impacted by the at least one new vulnerability is made without performing either an additional build process or a vulnerability scan on the at least one second code repository as taught by Velur for the purpose of providing more robust and accurate solutions for continuous and automatic vulnerability management for modern applications [Velur:0003].
Examiner notes:
Holz teaches plurality of repositories/applications and cross repository vulnerability correlation.
Lewandowski teaches build process metadata extraction, vulnerability update feed , dependency name/version matching and dependency declaration /config update.
Velur teaches stored dependency/version mapping across applications/microservices, CVE database analysis, identifying affected applications/microservices using previously created mappings, avoiding new mapping/repeated inspection and remediation.
Regarding claim 2, Holz, Lewandowski, and Velur teaches the computer-implemented method of claim 1, further comprising: scanning source code of the first code repository to detect at least one additional new vulnerability in addition to the at least one new vulnerability (Holz, mechanisms for automatically scanning code for a plurality of applications and identifying a security vulnerability in the source code of an application component of one of those applications. The security vulnerability is associated with the application component, e.g., the portion of source code, such as a function, class, method, routine, sub-routine, [0029] the application scanner scans the source code of the applications and compares the source code against a plurality of known insecure coding techniques and implementations, [0033] the output indicates at least one security vulnerability present in the source code of the application, each security vulnerability is associated with a corresponding portion of the application source code, e.g., the function, routine, class, method, sub-routine, etc., in which the security vulnerability was identified. …however, it should be appreciated that principles set forth herein may be applied to multiple security vulnerabilities found in one or more portions of application source code of one or more applications, [0093]) [Examiner interprets that system automatically scanning of application source code stored in repositories and scanning identifying one or more security vulnerabilities, including multiple vulnerabilities in a single scan as limitation above].
Regarding claim 3, Holz, Lewandowski, and Velur teaches the computer-implemented method of claim 1, wherein the metadata related to the first code repository corresponds to at least one of: at least one identifier of at least one software component associated with the first code repository; a set of dependent software components; one or more types of deployment environments; timestamp information related to one or more of: the at least one software component and the set of dependent software components; and version information related to one or more of: the at least one software component and the set of dependent software components (Holz, The SCRAM system stores and tracks versions of source code (i.e., version information the at least one software component), identifies code authors associated with code submissions (i.e., timestamp information the at least one software component) identifies other source code packages used by a particular application development project (i.e., a set of dependent software components), [0034] The source code repository and management (SCRAM) system 310 comprises logic that maps various types of source code 312-316 with identifiers of consumers 320 and contributors 322 and generates an application mapping data structure 318 that maintains that mapping, [0088]).
Regarding claim 4, Holz, Lewandowski, and Velur teaches the computer-implemented method of claim 1, wherein at least a portion of the metadata related to the first code repository is extracted based on a configuration file associated with the first build process (Holz, The SCRAM system stores and tracks versions of source code, identifies code authors associated with code submissions, identifies other source code packages used by a particular application development project, [0034] The system tracks which entity (e.g., user, organization, computing device, etc.) checked out, forked, or cloned a particular version of source code, as well as correlate the source code in the SCRAM system 310 consumer repositories 320 that are sourced from other SCRAM managed code packages belonging to other entities, e.g., contributors 322. The source code 312-316 is organized into projects or packages, each project/package having an owner or owners, e.g., a contributor 322. That source code, and related elements (images, text, web templates, executables, documentation, notes, etc.), are organized into a hierarchical file like system. All operations, updates, checkouts, check-ins, etc. are tracked by the SCRAM system 310 such that each source code element has an associated version history, [0090]) [Examiner interprets that managing and tracking relevant data (i.e., metadata) of the repository such as check-in and check-out process, build files such as libraries, packages, version data (i.e., configuration file) as at least a portion of the metadata related to the first code repository is extracted based on a configuration file associated with the detected build process].
Regarding claim 7, Holz, Lewandowski, and, Velur teaches the computer-implemented method of claim 1, wherein the one or more automated actions comprise: sending a notification of the at least one new vulnerability to one or more users associated with the at least one second code repository, wherein the notification comprises at least one of: a risk level associated with the at least one new vulnerability, one or more recommendations for remediating the at least one new vulnerability, and one or more changes that were automatically performed to address the at least one new vulnerability (Holz, The method generates notifications and/or graphical user interface outputs that are transmitted to other computing devices. The notifications provides various information about the security vulnerability including the identity of the security vulnerability, the nature or type of the security vulnerability, an identifier of the source code in which the security vulnerability was found (e.g., what function, method, sub-routine, etc. the security vulnerability was found in), the location of any solutions, patches, or fixes for the security vulnerability. The security vulnerability is found in source code that is shared by multiple consumers and/or contributors, the notifications is sent to each such consumer/contributor and is customized to the particular application(s) with which that consumer/contributor is associated and in which the security violation is known to be present and identify which applications that consumer/contributor is associated with and which have the identified security vulnerability, [0038]) The patches or fixes for the security vulnerability is automatically pushed to the individuals or organizations for implementation into their instances of the source code where the security vulnerability is present [0073]) [Examiner interprets that sending notification to consumer/ contributors that are associated to the source code containing security vulnerability about their nature/type (i.e. risk level) remediation solutions (i.e. recommendations), automatically pushing patching or fixes to address the vulnerabilities (i.e. one or more changes to address the vulnerability) as sending a notification of the at least one vulnerability to one or more users associated with the at least one additional code repository, wherein the notification comprises at least one of: a risk level associated with the at least one vulnerability, one or more recommendations for remediating the at least one vulnerability, and one or more changes that were automatically performed to address the at least one vulnerability].
Regarding claims 8 and 15, Claims 8 and 15 recite commensurate subject matter as claim 1. Therefore, they are rejected for the same reasons. Except additional elements:
Holz teaches:
A non-transitory processor-readable storage medium having stored therein program code of one or more software programs, wherein the program code when executed by at least one processing device causes the at least one processing device (Holz, The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention, [0047]):
An apparatus comprising: at least one processing device comprising a processor coupled to a memory; the at least one processing device being configured (Holz, The computer readable program instructions is provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus. A programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored, [0052]):
Regarding claims 9-11 and 14, Claims 9-11, and 14 recite commensurate subject matter as claim 2-4, and 7 respectively. Therefore, they are rejected for the same reasons.
Regarding claims 16-18, Claims 16-18 recite commensurate subject matter as claim 2-4. Therefore, they are rejected for the same reasons.
Regarding claim 21, Holz, Lewandowski, and, Velur teaches the computer-implemented method of claim 1, wherein the Holz and Lewandoski teaches first/second repository, central database for vulnerability update, and impacted repository framework, however, Holz and Lewandoski does not explicitly teach:
determining that the at least one second code repository is impacted by the at least one new vulnerability comprises: identifying, based on the at least one new vulnerability, a vulnerable software component and a version associated with the vulnerable software component; and matching the vulnerable software component and the version against dependency information stored in the at least one database for the at least one second code repository
However, Velur teaches:
determining that the at least one second code repository is impacted by the at least one new vulnerability comprises: identifying, based on the at least one new vulnerability, a vulnerable software component and a version associated with the vulnerable software component; and matching the vulnerable software component and the version against dependency information stored in the at least one database for the at least one second code repository (Velur, the third-party library 106 can depend on other libraries or be used as a dependent library upon which other libraries depend upon. The third-party library 106 can have a third-party library version 110, such that different versions of the third-party library 106 have different code where newer versions often include fixes to solve issues with previous versions, [0030] the third-party libraries stored within the repository can be linked to every application that uses each third-party library… Mapping the deployed applications to their third-party library dependencies can include dependency version information. This can provide a snapshot of the current status of each third-party library used by each application, [0042] Both direct and transitive dependencies of the dependency tree can be analyzed to determine if any known CVE issues are present, [0047] The list can include all direct and transitive dependencies that have vulnerabilities, the corresponding versions that are fixed, and a log recording any changes made in updated library version. The list can also include all of the microservices and APIs affected from the potential vulnerabilities due to the vulnerable direct and transitive dependencies, [0049] Using the microservices-dependencies-versions mapping that was produced in block 302 through 312, all the deployed microservices at risk that need to be patched or upgraded can be identified, [0067] The memory 608 can include a database of each currently employed library that upon which each microservice within each software package depends, [0076]) [Examiner interprets that system storing dependency version mapping across applications/microservices, using known CVE/vulnerability databases to analyze the stored dependency tree, identifying all affected microservices/APIs from the stored mappings as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Holz and Lewandowski to include a concept of determining that the at least one second code repository is impacted by the at least one new vulnerability comprises: identifying, based on the at least one new vulnerability, a vulnerable software component and a version associated with the vulnerable software component; and matching the vulnerable software component and the version against dependency information stored in the at least one database for the at least one second code repository as taught by Velur for the purpose of providing more robust and accurate solutions for continuous and automatic vulnerability management for modern applications [Velur:0003].
Claims 5, 6, 12, 13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Holz (US 20180157842 A1) in view of Lewandowski (US 20230281316 A1) in further view of Velur (US 20200242254) in further view of in further view of Giles (US 20230141524 A1).
Regarding claim 5, Holz, Lewandowski, and Velur teaches the computer-implemented method of claim 1, wherein: at least one second code repository and remediating the at least one vulnerability in the at least one second code repository (Holz, The method automatically scans code for a plurality of applications and identifies a security vulnerability in the source code of an application component of one of those applications such as , e.g., the portion of source code, such as a function, class, method, routine, sub-routine, or the like and associates with the other application and information about the presence of the security vulnerability in the identified applications is provided to personnel/organizations (e.g., users, consumers, and/or contributors) associated with the applications, based on a correlation of personnel/organization information with the identified applications, [0029] The patches or fixes for the security vulnerability is automatically pushed to the individuals or organizations for implementation into their instances of the source code where the security vulnerability is present, [0107] The security vulnerability amalgamation engine and/or SCRAM system provides the logic of automatic checkout of new versions of source code that specifically remediates the vulnerabilities found in previous source code of the same project or package registered in the SCRAM system and continuous delivery of secure source code is by automated testing (i.e., continuous delivery environment), [0109]) [Examiner interprets that system automatically fixing or mitigating security vulnerabilities by distributing new or remediated source code, pushing patches and creating continuous delivery pipeline or check-in or checkout routine that triggers new builds as at least one second code repository and remediating the at least one vulnerability in the at least one second code repository].
Holz does not explicitly teach:
the configuration file is updated response to determining that no changes to the source code are needed to remediate the at least one vulnerability; the one or more automated actions further comprise initiating a build process, based at least in part on the updated configuration file
However, Lewandowski teaches:
Updating configuration file to remediate the at least one vulnerability and the one or more automated actions further comprise initiating a third build process, based at least in part on the updated configuration file (Lewandowski, identification of security vulnerabilities (e.g., for dependencies in a software application build) can instead be done as part of a regular software development pipeline (e.g., a continuous integration (CI) pipeline). Specialized software agents (e.g., pipelines) can be integrated with a build management tool to listen for relevant events, including the addition of new dependencies, version changes in dependencies, and the identification of new security vulnerabilities for dependencies (e.g., in the NVD or another suitable repository),[0014] the defect manager service 150 can take steps to automatically resolve the vulnerability… The defect manager service 150 can automatically download the more recent version of the dependency, and can provisionally update the application build 102 to include the more recent version or generate a suggestion for an administrator or engineer to include the more recent version of the dependency in the application build 102, [0026] identifying and resolving security vulnerabilities for a new dependency in a software application build, At block 302, a dependency tracking service detects a new dependency added to a build. …receives a commit (e.g., the commit 104 illustrated in FIG. 1) relating to an application build (e.g., the application build 102 illustrated in FIG. 1). The dependency tracking service can identify added dependencies in the commit (e.g., scanning modified or new build files, reviewing changes in the commit, or using any other suitable technique), [0034]) [Examiner interprets that system operating within a CI/build pipeline, automatically updating build inputs and continuously building lifecycle using updated configuration as limitation above]. Same motivation applies as claim 1.
Holz and Lewandowski does not explicitly teach:
the configuration file is updated response to determining that no changes to the source code are needed to remediate the at least one vulnerability
However, Giles teaches:
the configuration file is updated response to determining that no changes to the source code are needed to remediate the at least one vulnerability (Giles, The method may include receiving trigger data, wherein the trigger data may indicate a first software instance is out of compliance. The trigger data may include a first software instance identifier, and at least one first compliance error (i.e., the vulnerability). The method include comparing the at least one first compliance error with the configuration policies stored in the compliance repository. In response to the at least one first compliance error matching at least one configuration policy stored on the compliance repository beyond a first predetermined threshold, the method may include identifying a first software configuration file based on the first software instance identifier, and applying the at least one matching configuration policy to the first software configuration file to remediate the first software instance. In response to the at least one first compliance error not matching at least one configuration policy beyond the first predetermined threshold, the method may include generating a new configuration policy based at least in part on the at least one first compliance error, validating the new configuration policy, and applying the new configuration policy to the first software configuration file (i.e., updating configuration file associated with the at least one second code repository) to remediate the first software instance, [0005] block 340, the system may determine whether the compliance error matches a configuration policy stored on the compliance repository 140 beyond a predetermined threshold… In response to determining a matching configuration policy stored on the compliance repository beyond a predetermined threshold, the method may move to block 350… 350, the system may identify a first software configuration file associated with the first software instance. 360, the system (e.g., compliance remediation system 110) may apply the at least one matching configuration policy to the first software configuration file to remediate the first software instance, [0041-0043]) [Examiner interprets that system automatically updating the configuration file once the compliance error is identified to remediate the software instance without changing any code of software as the system choses configuration file based remediation path as the configuration file is updated response to determining that no changes to the source code are needed to remediate the at least one vulnerability];
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of , Holz, Lewandowski, and Velur to include a concept of the configuration file is updated response to determining that no changes to the source code are needed to remediate the at least one vulnerability as taught by Giles for the purpose of generating a new configuration policy based at least in part on the at least one first compliance error, validating the new configuration policy, and applying the new configuration policy to the first software configuration file to remediate the first software instance [Giles:0005].
Regarding claim 6, Holz, Lewandowski, Velur, and Giles teaches the computer-implemented method of claim 5, wherein the updating the configuration file comprises: changing a version of a dependent software component that is referenced in the configuration file to a different version of the dependent software component to address the at least one new vulnerability (Lewandowski, the defect manager service 150 can take steps to automatically resolve the vulnerability… The defect manager service 150 can automatically download the more recent version of the dependency, and can provisionally update the application build 102 to include the more recent version or generate a suggestion for an administrator or engineer to include the more recent version of the dependency in the application build 102, [0026] a dependency tracking service (e.g., the dependency tracking service 112 illustrated in FIGS. 1-2) detects a dependency version change for a build.. the dependency tracking service can identify dependencies with version changes in the commit (e.g., scanning modified or new build files, reviewing changes in the commit… the dependency tracking service commits a change identifying the new dependency version to a repository…. The dependency tracking service can update the version information for the dependency in the file, [0042-0046]) [Examiner interprets that system updating dependency declarations/build config to change dependency version and that version change is used as remediation as limitation above] same motivation applies as claim 1.
Regarding claims 12 and 13, Claims 12 and 13 recite commensurate subject matter as claim 5 and 6. Therefore, they are rejected for the same reasons.
Regarding claims 19, Claim 19 recite commensurate subject matter as claim 5. Therefore, they are rejected for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20230025526 A1: “relates to providing new and innovative systems and methods for patching software dependencies using external metadata”
US 20140101633 A1: “relates in general to software development, and more specifically to providing information about software artifacts used in software development”.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SHEWAYE GELAGAY can be reached at (571)272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/S.N.P./Examiner, Art Unit 2436 /SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Prosecution Insights