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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/25/2024 has been entered.
Response to Amendment
In the response filed on 10/23/2025. The applicant amended claims 1, 2, 5-9, 12-16, 19 and 20 are amended. No claims were added.
Response to Arguments
With respect to 135 U.S.C. §103 rejections:
Applicant's arguments filed on 10/23/2025 have been received and entered. Applicant's arguments with respect to the newly amended independents “Claim Rejections - 35 USC § 103” remarks pages 9-11, have been considered.
Applicant argues that Holz merely catalogs vulnerabilities after scanning and therefore does not teach “detecting at least one new vulnerability added to a vulnerability database” as recited in amended claim 1. Examiner acknowledge the applicant’s perspective, however, respectfully disagrees. Holz explicitly discloses identifying software vulnerabilities and cataloging the identified vulnerabilities in a vulnerability cataloging system for subsequent correlation, tracking and management, see [0037-0038]. One cataloged, such vulnerabilities are newly present within the vulnerability repository, and are available for detection and use in subsequent analysis workflows, [0037,0073]. Under BRI, “detecting at least one new vulnerability added to a vulnerability database” constitute detecting that vulnerability is newly present in a vulnerability repository, regardless of how or when the vulnerability was added. The claim does not require detecting an external feed update, detecting a public database change, or detecting the moment of insertion. Applicant attempt to characterize Holz as merely reactive improperly imports limitations from specification into the claims. The claim does not recite “proactive”, external, or global vulnerability databases and do not exclude detecting based on internally maintained vulnerability repositories. Thus, Holz reasonably teaches the claimed limitation.
Applicant further argues that amended claim 1 requires a proactive workflow triggered by an external event, such as an update to a global vulnerability database. Examiner respectfully disagrees since this argument is not supported by the claim language. Amended claim 1 merely recites detecting a new vulnerability added to a vulnerability database and initiating subsequent actions in response. The claim does not specify the source of the vulnerability database, the mechanism by which vulnerabilities are added, to that the detection must be external to the system. Under BRI Holz disclosure of identifying and cataloging vulnerabilities that subsequently trigger correlation and management action satisfies this limitation.
Applicant further assert that Meacham does not teach searching stored metadata in response to a vulnerability related trigger. Examiner respectfully disagrees. Meacham explicitly discloses storing build metadata, dependency information, and artifact relationships, and for searching such stored metadata to determine downstream impacts when triggering condition occurs, see par [0026, 0093-0099, 0100-0107, 0143]. Also, examiner highlights that the rejection does not rely on Meacham for vulnerability detection itself. It would be obvious to POSITA to apply Meacham’s known metadata search and dependency analysis technique in response to a vulnerability detection event as taught by Holz and Giles, in order to identify additional impacted code repositories.
Applicant argues that Giles only updates configuration files of already running software instances and therefore does not teach updating configuration files of other repositories without modifying source code. Examiner respectfully disagrees. Giles explicitly teaches identifying and modifying software configuration files used to initialize software instances, including Docker files, and dependency manifests, which are repository level artifacts, [0037,0039,0042-0043]. Giles further teaches applying remediation policies by updating such configuration files and dependency specifications without modifying application source code, [0043]. Thus, Giles teaches the claimed limitation. Applicant asserts that the cited combination does not teach proactively identifying vulnerabilities across different code repositories based on stored metadata. Holz teaches corelating vulnerabilities across multiple projects and repositories, [0037, 0073], Meacham teaches identifying impacted dependent artifacts using stored metadata. Giles teaches initiating automated remediation actions by updating configuration file once an impacted artifact is identified. Thus, combined teaching reasonably suggest determining that additional repositories are impacted by a detected vulnerability and initiating remediation actions.
However, Examiner acknowledged Applicant’s perspective, upon further consideration, a new ground(s) of rejection is made in view of Holz (US 20180157842 A1) in view of Lewandowski (US 20230281316 A1).
Claim Objections
Regarding claims 1, 8, and 15, Claim claims 1, 8, and 15 are objected to because of the following informalities: In line 7, 9, and 10 respectively, “in response to detecting the new vulnerability” should read ““in response to detecting the at least one new vulnerability” Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 1 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites a limitation “detecting at least one new vulnerability added to a vulnerability database”, However, the scope of “detecting…added to a vulnerability database” is unclear. It is unclear whether the recited “detecting” refers to detecting the presence/existence of a vulnerability by using the vulnerability database (e.g., querying the database to identify a vulnerability), or the recited “detecting” refers to detecting that the vulnerability database has been updated (i.e., monitoring the vulnerability database for changes, or receiving a notification of an update), and then identifying the vulnerability as “new” based on the update. Because the claim does not specify whether “detecting” is performed by monitoring for changes to the vulnerability database versus using the vulnerability database to discover a vulnerability, the meets and bounds of limitation are uncertain. In addition, claim 1 further recites “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”. The phrase “wherein the detecting comprises searching the stored metadata “ is unclear as to what “the detecting” refers to: the earlier step of “detecting at least one new vulnerability added to a vulnerability database”, or the later impact analysis step (i.e., determining whether the vulnerability impacts the first code repository). In light of specification, searching stored metadata appears to be part of determining impact, not part of detecting the new vulnerability, see (spec of instant application, page 10, line 23-24). Examiner suggest to clarify the scope of claim 1. Dependent claims are also rejected for inheriting the deficiencies set forth above for independent claims. Appropriate correction is required.
Claim 2 recites “ scanning source code of the first code repository to detect at least one additional new vulnerability”, the phrase “additional new vulnerability” is unclear because it is not clear what the vulnerability is “additional” relative to. For example, it is unclear whether “additional” means: “additional relative to “the at least one new vulnerability” recited in claim 1 (i.e., a different vulnerability than the vulnerability detected from the vulnerability database), or additional relative to vulnerabilities found in prior scans (i.e., newly detected compared to earlier scan results). Examiner suggest to clarify the scope of claim 2. Appropriate correction is required.
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, and 14-18 are rejected under 35 U.S.C. 103 as being unpatentable over Holz (US 20180157842 A1) in view of Lewandowski (US 20230281316 A1).
Regarding claim 1, Holz teaches 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 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, 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 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];
detecting at least one new vulnerability added to a vulnerability database (Holz, A data processing system corelates security vulnerability detection across multiple applications (i.e., the plurality of code repositories) The data processing system performs a security vulnerability analysis of first source code of a first application ( i.e., the first code repository) and identifies a security vulnerability in a first portion of the first source code based on results of the security vulnerability analysis, [0009] Many security vulnerabilities have been identified in source code and standardized techniques for detecting their presence have been developed. Standardized methodologies for identifying these known security vulnerabilities that have been devised include the Common Vulnerabilities and Exposures (CVE) initiative which provides a dictionary of common names and identifiers for publicly known information security vulnerabilities, [0026] the application scanner scans the source code of the applications and compares the source code against a plurality of known insecure coding techniques such as code pattern matching, heuristic analysis, function analysis, parameter analysis, boundary failure analysis, etc. The resulting output of the application scanner is a set of flagged portions of source code that have been determined to be potentially insecure, [0033] A lookup operation may be performed by the code vulnerability analysis system 330 in response to detecting a security vulnerability in scanned application source code, such as based on a security vulnerability name, CVE identifier, or other unique identifier of the security vulnerability and the corresponding information, patches/fixes, and the like, may be retrieved and included in the output of the code vulnerability analysis system 330, [0094]) [ Examiner interprets that scanning the first source code to identify a security vulnerability using various techniques such as code pattern matching, heuristic analysis, function analysis, parameter analysis, boundary failure analysis and CVE look up to detect a security vulnerability detecting at least one new vulnerability added to a vulnerability database];
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 (Holz, 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 presence of the application component in another one of the applications in the plurality of applications is identified via a source code repository that stores information about the various source code of applications and the particular contributors and consumers of those source codes. The security vulnerability is associated 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 vulnerability correlation logic 360 correlates the security vulnerability characteristics of the security vulnerability with source code and consumer/contributor mapping information in the application mapping data structures 318 of the SCRAM system.. the security vulnerability is associated with a portion of source code in the application. Information about this portion of source code may be used to perform a lookup of consumer/contributor information for that portion of source code in the application mapping data structures 318. Thus, for example, the application mapping data structures 318 may store information that maps each method of source code with the contributors 322 that contributed to the generation and modification of the method, and with consumers that utilize the method in their applications. The vulnerability correlation logic 360 may communicate with the SCRAM system 310 to perform a lookup operation, based on the method (the term “method” being used in this context to refer to methods in object-oriented programming) in which a security vulnerability is detected by the code vulnerability analysis system 330, to identify the contributors 322 and consumers 320 of that method, [0095]) [Examiner interprets that system corelating metadata such as version info, contributor info with identified security vulnerability (i.e., the new vulnerability) in the source code of an application component of one of those applications when security vulnerability is identified in the first source code as limitation above];
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 the metadata stored in the at least one database for the at least one second code repository (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 whether at least one additional code repository of the plurality of code repositories is impacted by the at least one vulnerability based at least in part on the metadata stored in the at least one database for the at least one additional code repository]; 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 at least one new vulnerability added to a vulnerability database; 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; the one or more automated actions comprise updating a configuration file to partially remediate the at least one vulnerability without changing source code.
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 at least one new vulnerability added to a 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 detecting a build process extracting metadata and storing the extracted metadata in the at least one data base; detecting at least one new vulnerability added to a vulnerability database; 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; 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]
Regarding claim 2, Holz and Lewandowski 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 (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 and Lewandowski 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 and Lewandowski 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 detected 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 and Lewandowski 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.
Claims 5, 6, 12, 13, 19, and 20 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 in further view of Giles (US 20230141524 A1).
Regarding claim 5, Holz and Lewandowski 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 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 and Lewandowski 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, 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 and 20, Claims 19 and 20 recite commensurate subject matter as claim 5 and 6. 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 20240168744 A1: “relates to a system and a method for automatically managing cloud deployment configuration files and container base images associated with the applications”
US 20230275917 A1: “ relates to identifying an attack surface of a cloud deployment”
US 10691810 B1 : “generally to methods and apparatuses, including computer program products, for detecting vulnerabilities associated with a software application build”
US 10592677 B2: “generally relates to computing devices, and more particularly, to methods and systems for patching applications having security vulnerabilities”
US 20200042712 A1 : “relates to the field of information security, and more particularly to software development, installation, and management”
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
/TRONG H NGUYEN/Primary Examiner, Art Unit 2436