Automated security vulnerability remediation in containerized software applications

Abstract

A system includes memory hardware configured to store instructions and processor hardware configured to execute the instructions. The instructions include receiving a set of vulnerabilities associated with a containerized system image from an image scanner. The instructions include programmatically triaging the set of vulnerabilities to create a subset of vulnerabilities. The instructions include automatically generating a patch for the subset of vulnerabilities. The instructions include automatically applying the patch to the containerized system image.

Description

Attorney Docket No. 55882-5AUTOMATED SECURITY VULNERABILITY REMEDIATION IN CONTAINERIZEDSOFTWARE APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 794,042 (Attorney Docket No. 55882-3) filed April 24, 2025, and U.S. Provisional Application No. 63 / 706,324 (Attorney Docket No. 55882-2) filed October 11, 2024. The entire disclosures of the above applications are incorporated by reference.FIELD

[0002] The present disclosure relates to cybersecurity and more particularly to patching system image vulnerabilities.BACKGROUND

[0003] Cybersecurity is a complex component of many electronic systems and applications. Hardware and software continuously evolve, which results in improved technology but also creates new vulnerabilities. Constant updates are needed to resolve newly created errors and vulnerabilities. Determining which vulnerabilities must be addressed is a complex and neverending task.

[0004] The background description provided here is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.SUMMARY

[0005] A system includes memory hardware configured to store instructions and processor hardware configured to execute the instructions. The instructions include receiving a set of vulnerabilities associated with a containerized system image from an image scanner. The instructions include programmatically triaging the set of vulnerabilities to create a subset of vulnerabilities. The instructions include automatically generating a patch for the subset of vulnerabilities. The instructions include automatically applying the patch to the containerized system image.

[0006] In other features, the instructions include sending the containerized system image to the image scanner and scanning the containerized system image with the image scanner. In other features, triaging the set of vulnerabilities includes determining an architecture associated with the containerized system image. In other features, triaging the set of vulnerabilities includes determining a context associated with the containerized system image. In other features, triaging the set of vulnerabilities includes determining whether a severity metric of a respective vulnerability of the set of vulnerabilities has met a severity threshold.Attorney Docket No. 55882-5

[0007] In other features, triaging the set of vulnerabilities includes determining a priority metric based on a set of crowd-sourced data. In other features, the instructions include determining the severity metric of the respective vulnerability. In other features, the severity metric is based on data from a set of public datastores, and / or a set of crowd-sourced data. In other features, the instructions include receiving a set of crowd-sourced data. The set of crowdsourced data includes at least one of a set of persona data, a set of expert data, or a set of comments.

[0008] In other features, automatically generating the patch for the subset of vulnerabilities includes adapting a respective patch associated with a first operating system for a second operating system. In other features, the second operating system is different from the first operating system. In other features, the second operating system is associated with the containerized system image.

[0009] A method includes receiving a set of vulnerabilities associated with a containerized system image from an image scanner. The method includes programmatically triaging the set of vulnerabilities to create a subset of vulnerabilities. The method includes automatically generating a patch for the subset of vulnerabilities. The method includes automatically applying the patch to the containerized system image.

[0010] In other features, the method includes sending the containerized system image to the image scanner and scanning the containerized image with the image scanner.

[0011] In other features, triaging the set of vulnerabilities includes determining an architecture associated with the containerized system image. In other features, triaging the set of vulnerabilities includes determining a context associated with the containerized system image. In other features, triaging the set of vulnerabilities includes determining whether a severity metric of a respective vulnerability of the set of vulnerabilities has met a severity threshold.

[0012] In other features, triaging the set of vulnerabilities includes determining a priority metric based on a set of crowd-sourced data. In other features, the method includes determining the severity metric of the respective vulnerability. In other features, the severity metric is based on data from a set of public datastores, and / or a set of crowd-sourced data. In other features, the method includes receiving a set of crowd-sourced data. The set of crowd-sourced data includes at least one of a set of persona data, a set of expert data, or a set of comments.

[0013] In other features, automatically generating the patch for the subset of vulnerabilities includes adapting a respective patch associated with a first operating system for a second operating system. In other features, the second operating system is different from the first operating system. In other features, the second operating system is associated with the containerized system image.

[0014] A non-transitory computer-readable medium includes processor-executable instructions. The instructions include receiving a set of vulnerabilities associated with a containerized system image from an image scanner. The instructions include programmatically triaging the set of vulnerabilities to create a subset of vulnerabilities. The instructions includeAttorney Docket No. 55882-5 automatically generating a patch for the subset of vulnerabilities. The instructions include automatically applying the patch to the containerized system image.

[0015] In other features, the instructions include sending the containerized system image to the image scanner and scanning the containerized system image with the image scanner.

[0016] In other features, triaging the set of vulnerabilities includes determining an architecture associated with the containerized system image. In other features, triaging the set of vulnerabilities includes determining a context associated with the containerized system image. In other features, triaging the set of vulnerabilities includes determining whether a severity metric of a respective vulnerability of the set of vulnerabilities has met a severity threshold.

[0017] In other features, triaging the set of vulnerabilities includes determining a priority metric based on a set of crowd-sourced data. In other features, the instructions include determining the severity metric of the respective vulnerability. In other features, the severity metric is based on data from a set of public datastores, and / or a set of crowd-sourced data.

[0018] In other features, the instructions include receiving a set of crowd-sourced data. In other features, the set of crowd-sourced data includes at least one of a set of persona data, a set of expert data, or a set of comments.

[0019] In other features, automatically generating the patch for the subset of vulnerabilities includes adapting a respective patch associated with a first operating system for a second operating system. In other features, the second operating system is different from the first operating system. In other features, the second operating system is associated with the containerized system image.

[0020] Further areas of applicability of the present disclosure will become apparent from the detailed description, the claims, and the drawings. The detailed description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The present disclosure will become more fully understood from the detailed description and the accompanying drawings.

[0022] FIG. 1 is a functional block diagram of an example system for resolving vulnerabilities.

[0023] FIGS. 2A-2C together are a flowchart of an example method for resolving vulnerabilities.

[0024] FIG. 3 is a flowchart of an example method for applying existing patches to system images.

[0025] FIG. 4 is a functional block diagram of an example patch generation system.

[0026] FIG. 5 is a flowchart of an example method for generating a patch.

[0027] In the drawings, reference numbers may be reused to identify similar and / or identical elements.Attorney Docket No. 55882-5DETAILED DESCRIPTIONINTRODUCTION

[0028] Reaching zero vulnerabilities for a system is generally not functionally possible or necessary. Not all existing vulnerabilities are applicable or pose significant risks to a given system. The present disclosure describes a system and method for automatically determining which vulnerabilities are high priority and should be addressed based on a system’s architecture, the system’s configuration (context), the industry in which the system is used, and / or crowdsourced feedback from users of similar systems or experts on a given architecture or technology.IMAGE SCANNING

[0029] Containerized images are lightweight, standalone, executable packages that include everything needed to run a piece of software, including the code, runtime, libraries, and system tools. In some implementations, containerized images are built using containerization technologies like Docker. An example image may have a large number of vulnerabilities (for example, 10, 100, 1000, or 10,000 vulnerabilities). Vulnerability scanners are automated tools designed to identify security weaknesses in systems, networks, and applications. Scanners assess image security by scanning for known vulnerabilities, misconfigurations, and other potential security issues. One or more scanners are used to scan each containerized image and detect vulnerabilities using data from open-source data stores. Scanners use databases of known vulnerabilities, such as the National Vulnerability Database (NVD), Known Exploited Vulnerabilities Catalog (KEV), or CVE (Common Vulnerabilities and Exposures), to compare against the scanned systems. In some implementations, a third-party scanner is used, such as Snyk or Trivy. In some implementations, the system image scanner includes one or more Al agents that use graph-based structures with large language models (LLMs) and / or reasoningspecific models. In some implementations, a system image is received pre-scanned (in other words, with vulnerability data already available).TRIAGING VULNERABILITIES

[0030] Once the set of image vulnerabilities is detected (or received), the vulnerabilities are triaged to an actionable subset of vulnerabilities. In various implementations, the triage process is executed programmatically by a computing system, independent of human involvement. In various embodiments, the triage process and / or other processes are performed automatically. In various embodiments, an automatic process is performed without requiring direct human intervention once the process has been initiated. In various embodiments, an automatic process is initiated by a human operator. In various embodiments, an automatic process is initiated in response to predefined conditions, inputs, or programmed instructions without human intervention. In various embodiments, an automatic process receives human input such asAttorney Docket No. 55882-5 approval and / or data for analysis. In various embodiments, an automatic process occurs in real time or substantially immediately following a triggering event.

[0031] The triage process filters down the set of vulnerabilities to determine which vulnerabilities should be patched and which can be safely ignored. In some implementations, the detected vulnerabilities are filtered based on the architecture of the system (in other words, some vulnerabilities are only applicable to systems of a certain type, such as Intel, AMD, ARM, or other instruction sets). Vulnerabilities that are not applicable to the architecture of the system can be safely ignored. In some implementations, the configuration or context of a system image is used to triage the vulnerabilities. For example, a particular configuration of a system may have a critical vulnerability, but if the system does not use the particular configuration, the critical vulnerability can be ignored. A system’s context may include specific runtime details such as the presence and version of installed software packages (such as OpenSSL 3.1.2), system roles (such as a web server or database system), network exposure (such as externally accessible or isolated within a private subnet), architecture-specific configurations (such as ARM or x86), and / or security context (such as container privilege levels or SELinux policies).

[0032] In some implementations, the vulnerabilities are assigned a severity metric and sorted by severity. In some implementations, vulnerabilities with a severity metric below a threshold are ignored and / or assigned a low priority. In some implementations, the severity metric is based on a score assigned by a third-party scoring system (such as the Common Vulnerability Scoring System (CVSS) or the Exploit Prediction Scoring System (EPSS)). In some implementations, the severity metric is based on whether confidential information can be accessed, whether data can be altered, or whether the system could be disrupted. In some implementations, the severity metric is based on how easily exploitable the vulnerability is (for example, whether prior access is required, the complexity of the attack necessary to exploit the vulnerability, or whether authentication is needed to exploit the vulnerability). In some implementations, other severity metric factors include the number of images or systems that might be affected by the vulnerability. In some implementations, the thresholds, severity and / or priority are dynamic and based on the type of image and / or use case (for example, a high-security system might require more strict vulnerability removal). In some implementations, the severity metric is adjusted based on the type of image and / or use case.

[0033] In some implementations, the same vulnerability triage can be applied to other system images that are similar to the image or applied to a set of images based on a user preference for the same triage to be applied. In some implementations, vulnerability triage is based on one or more Al agents and / or machine learning models.USER FEEDBACK

[0034] In some implementations, severity and / or other triage determinations are based on crowd-sourced information (such as expert opinion, aggregated comments and / or reviews). In some implementations, the crowd-sourced information includes triage selections from users with similar personas (such as similar industries or use cases). Users may select certain types ofAttorney Docket No. 55882-5 vulnerabilities as very important while ignoring or assigning a low priority or severity to others. In some implementations, the crowd-sourced information is based on community collaborators and experts on a particular system or technology. In some implementations, comments are gathered via an API with third-party software (for example, via JIRA tickets). In some implementations, gathered comments are stored in a database and parsed using an Al agent that uses one or more machine learning models (such as an LLM or other reasoning-specific models) and that determines how the comments affect the severity metric and / or vulnerability triage. In some implementations, crowd-sourced comments are solicited by a feedback module that includes a user interface that can be used to submit comments. In some implementations, the crowd-sourced information is weighted, with one or more users influencing the priority or severity of vulnerabilities more than others. In some implementations, the weight of a user depends on the image being triaged.SPECIALIZED AGENTS FOR USER INPUT INTERPRETATION AND INTEGRATION

[0035] In various embodiments, specialized agents interpret, integrate, and apply user- provided inputs. These agents have narrowly scoped roles designed specifically to process and utilize user feedback without requiring traditional NLP methods, as the underlying GPT-based text transformer models inherently handle text interpretation effectively.

[0036] A user input interpretation agent directly evaluates user feedback provided through UI or API inputs to leverage GPT-based reasoning models (such as OpenAI GPT-4.5) to interpret user comments and extract key details about user perceptions of vulnerability severity, importance, and / or prioritization without the need for traditional NLP methods.

[0037] A severity adjustment and prioritization agent perform several tasks. First, the agent integrates GPT-interpreted user inputs into the overall triage logic. Second, the agent dynamically adjusts internal severity scoring and prioritization criteria based directly on GPT model assessments of user feedback. Third, the agent coordinates with other triage and patchgeneration agents within an agentic graph structure, ensuring the triage and patching processes align closely with user-specific vulnerability prioritization. These agents form part of the agentic graphic structure and ensure continuous, accurate integration of real-time user feedback into automated vulnerability triage and patching workflows.USER FEEDBACK WEIGHTING AND INTEGRATION

[0038] User feedback weighting is inherently integrated through the reasoning performed by specialized triage agents rather than through explicit numeric scoring. Agents directly consider all user feedback as contextual inputs during their evaluation process, combining user feedback with system-defined rules to guide vulnerability assessment and prioritization. For example, when users explicitly mark a vulnerability as “not affecting” or downgrade its severity to “low,” predefined triage rules are applied to automatically incorporate and act upon this information. The rules enable the triage agents to filter and deprioritize vulnerabilities explicitly identified by users as irrelevant, significantly lowering or eliminating the priority assigned to theseAttorney Docket No. 55882-5 vulnerabilities. The rules also enable agents to explicitly document the rationale for such decisions within automatically generated VEX (Vulnerability Exploitability exchange) statements, clearly communicating user-provided severity adjustments and the resulting triage outcomes to users. Thus, while traditional numeric weight metrics are not explicitly assigned to individual user inputs, the agent-driven system inherently respects, integrates, and transparently communicates the significance of user-provided severity assessments through agentic decisionmaking logic, automated filtering, and explicit VEX documentation.PATCHING

[0039] Potential patches to the triaged vulnerabilities are found from open-source databases and are collected, tested, and validated before being applied. Once validated, patches are automatically applied. In some implementations, the patch is applied via a script or command line interface commands. In some implementations, patches must be adapted before being applied to the system image. For example, a vulnerability exists on two different operating system distributions, but a patch is only available for one of the distributions. If possible, the patch is then adapted and applied to the second distribution. In some implementations, the patch is created by one or more Al agents that use graph-based structures with LLMs and reasoningspecific models. In some implementations, the image scanning, vulnerability triaging, and / or patching occurs at regular intervals (for example after a timer has elapsed, or a threshold time has been met, such as once an hour, day, week, etc.).

[0040] In various embodiments, patching is performed via one or more Al agents. The agents begin by actively seeking and identifying potential patches from authoritative sources (such as GitHub) or other repositories. The agents identify commits or software releases explicitly marked as addressing security vulnerabilities (often referenced by CVE identifiers). Relevant proof-of-concept (POC) exploit code is also gathered from internet sources to serve as a baseline for vulnerability understanding and subsequent testing.

[0041] Once potential patches are identified, agents clone and perform detailed comparative analyses between two repositories: the source repository containing the original patch (typically a newer software version or a different operating system distribution), and the target repository (typically an earlier or alternative distribution requiring adaptation). Using advanced reasoning and instruction-based LLMs, the agents intelligently rewrite and adapt patches to accommodate differences in dependencies, APIs, code structure, and function signatures of the target repository.

[0042] After patches are adapted and applied to the target repository, a rigorous validation process is executed, involving:1) Automated Compilation: the system automatically recompiles the patched repository to ensure syntactic correctness and build- level integrity;2) Unit and Regression Testing: existing unit and regression test suites provided by the original repository authors are executed to verify continued functional correctness;Attorney Docket No. 55882-53) Test Suite Augmentation: additional tests specifically designed to confirm remediation of the vulnerability and to enhance test coverage are created and executed; and4) POC Exploit Verification: previously gathered POC exploit code is used to validate conclusively that the applied patch successfully addresses and mitigates the identified security vulnerability.

[0043] To minimize hallucinations or inaccuracies typically associated with generative Al, the system implements multiple complementary strategies:1) Narrow and Specialized Roles: agents have deliberately narrow scopes, sharply defined prompts, and tasks tailored to minimize ambiguity and improve outcome reliability;2) Advanced Prompt Engineering and Contextual Anchoring: carefully engineered, rolespecific prompts combined with Retrieval-Augmented Generation (RAG), embeddings, curated examples, and detailed context guide agent reasoning toward accuracy;3) Cross-Verification by Specialized Agents: dedicated “watchdog,” “reviewer,” and “collaborator” agents specifically evaluate and cross-check outputs from other agents, providing an additional verification layer to detect and correct inaccuracies; and4) Model Selection and Fine-Tuning: purposeful selection of reasoning and codegeneration models matched to task demands and selective fine-tuning further reduce hallucination risks.

[0044] Ultimately, human analysts and security researchers provide critical oversight through structured Git-based workflows (such as pull requests or merge requests), reviewing detailed diffs, analyses, test results, and agent-generated summaries before approving patches. In cases where automated agent adaptation encounters issues, the system preserves the entire analytical context - including branch states, detailed summaries of agent analyses, test outcomes, and attempted strategies - handing this comprehensive package directly to human experts who finalize and approve the patch manually. This sophisticated hybrid system, combining agentic Al-driven automation with rigorous human oversight and detailed validation, ensures highly reliable, accurate, and secure patch adaptation across diverse software versions and distributions.

[0045] In various embodiments, patch generation and validation module 148 and / or patching module 128 include an Al-driven, swarm-based framework that autonomously identifies, backports, validates, and packages source-level patches for open-source software vulnerabilities. The framework operates as a continuous pipeline under human-in-the-loop (HIL) governance, ensuring trust, safety, and verifiability at key control gates while maintaining near-autonomous throughput. In various embodiments, the framework includes various modules. For example, FIG. 4 is a diagram of an example set of modules used to generate a patch. In various embodiments, patch generation and validation module 148 and / or patching module 128 include one or more modules depicted in FIG. 4.

[0046] In various embodiments, the patching process begins at the input signals stage. The patching framework continuously ingests multiple vulnerability intelligence sources such as public CVE databases, NVD, GitHub advisories, vendor feeds, scanner outputs from various scanners, intelligence heuristics that detect newly emerging vulnerabilities, and direct userAttorney Docket No. 55882-5 requests for patch analysis or remediation. The various input signals trigger autonomous workflows orchestrated by a researcher swarm (for example, a swarm controlled and / or implemented by researcher swarm module 404).

[0047] The researcher swarm is a coordinated network of Al agents designed to locate, contextualize, and assess candidate fixes. In various embodiments, the researcher swarm has several responsibilities such as: i) identifying the fix tree (the upstream or future version repository that contains the relevant remediation commit); ii) determining the target repository (the older or customer-specific version requiring a backported fix); iii) collecting, parsing, and analyzing commits, diffs, and release notes; iv) using contextual reasoning (RAGs, CVE semantics, exploit data, POCs) and structural reasoning (dependency graphs, ASTs, call trees, and type graphs) to determine patchability; and v) compiling all evidence, rationale, and testing recommendations into a research dossier. The research dossier includes CVE metadata, fix commit hypotheses, references to proof-of-concept exploits, affected version ranges, candidate diffs, build / test notes, and an overall patchability assessment.

[0048] In various embodiments, a human reviewer examines the Al-generated dossier (for example, via human review module 408). In various embodiments, the human reviewer validates: i) whether the proposed fix tree is correct and applicable; ii) the credibility of patchability conclusions; iii) availability of POC or regression tests for validation; and iv) licensing, compliance, and policy acceptance. If the dossier is approved, the patching process is advanced to the patcher swarm stage. If the dossier is not approved, it is moved to a deferred queue for further research.

[0049] In various embodiments, deferred dossiers are not discarded. They enter a re-evaluation scheduler (for example, deferred queue and re-evaluation scheduler module 440) that periodically re-runs the researcher swarm against updated CVE data, new commits, or revised POC information. When new evidence emerges, the dossier re-enters the review cycle. This allows the system to continuously improve coverage for previously indeterminate vulnerabilities.

[0050] Once approved, the patcher swarm (for example, as represented by patcher swarm module 412) autonomously performs semantic backporting to create the minimal patch necessary to neutralize the vulnerability. The patcher swarm relies on two coordinated reasoning engines. The first engine is structural reasoning, which analyzes code semantics via ASTs, control and / or data flow graphs, type hierarchies, and dependency structures. The second engine is contextual reasoning, which leverages CVE context, exploit details, RAG knowledge, prior patch patterns, and prompt frameworks refined through experience. The patcher swarm extracts relevant diff fragments from the fix tree, interprets and re-contextualizes them into the target repository, and synthesizes a compatible patch that preserves original functionality.

[0051] In various embodiments, generated patches undergo multi-level testing (for example, via testing module 416) such as: i) upstream regression, unit, and integration tests from maintainers; ii) functional equivalence tests to verify that no behavioral drift is present; iii) proof-of-concept exploit testing to ensure the vulnerability is neutralized; and iv) system-Attorney Docket No. 55882-5 level validation, where applicable, by running dependent applications or containerized environments.

[0052] In various embodiments, the process includes a second round of human review (for example, via human review module 420) that examines the patch, testing results, and exploit validation data. In various embodiments, human review module 420 and human review module 408 are the same module. In various embodiments, human review module 420 and human review module 408 are different modules. In various embodiments, human review module 420 and human review module 408 have different user interfaces and / or different permissions. If the patch is approved, the patch advances to the build and packaging stage. If the patch is not approved (for example, because the patch is incomplete or ambiguous), the patch is transferred to a patch workbench (for example, patch workbench module 424).

[0053] The patch workbench is an interactive environment that allows user to collaborate with the patcher swarm in real time. In various embodiments, the patch workbench allows users to provide corrective hints, enforce additional constraints, or perform guided edits. In various embodiments, the patch workbench instructs the patcher swarm to reanalyze, re-test, and propose a corrected patch version. In various embodiments, once validated, the revised patch is resubmitted to human review for approval.

[0054] Approved patches are committed into controlled forks and built within a software factory (for example, software factory module 428). In various embodiments, the software factory: i) packages the updated source and binaries (for example, into .whl, .jar, .so, .deb, or .rpm files); ii) generates attested SBOM deltas, VEX records, and provenance documentation; and iii) signs all artifacts for traceability and compliance. The resulting artifacts are pushed into a patched library repository (for example, patch library repository module 432), which is a curated, versioned collection of verified patches. An agentic vulnerability remediation (AVR) system (for example, agentic vulnerability remediation module 436) consumes these patched libraries as trusted inputs. AVR automatically selects the correct fix packages based on policy, context, and image composition to remediate container images at scale, which effectively closes the loop from vulnerability detection to fully patched, redeployable images.

[0055] Throughout this entire lifecycle, the system collects reinforcement data from successes, failures, testing outcomes, and human feedback. This learning loop continuously: i) refines prompt and agent specialization; ii) updates a computational knowledge graph and fixes pattern libraries; iii) improves tool integration (such as MCP servers, analyzers, retrieval engines); and iv) evolves the decision logic of both the researcher and patcher swarms. This adaptive reinforcement improves patching capability with every iteration, which reduces the need for human intervention over time.

[0056] FIG. 5 is a flowchart of an example method for generating a patch with the system of FIG. 4. Control begins at 504 and determines whether input (such as vulnerability data) has been received. If no input has been received, control remains at 504. In input has been received, control continues to 508.Attorney Docket No. 55882-5

[0057] At 508, control analyzes the input with the researcher swarm to generate a research dossier. At 512, the research dossier is reviewed (for example, by a human reviewer or other approval process). If the dossier is approved, control continues to 516. If the dossier is not approved, control transfers to 532 and adds the dossier to a deferred queue. At 536 control waits for updated data (for example, updated vulnerability data). Once updated data has been received, control returns to 508.

[0058] At 516, control analyzes the dossier and synthesizes a patch using the patcher swarm. At 520, control tests and validates the patch and continues to 524 for approval. If the patch is approved (for example, by a human reviewer or other approval process), control continues to 528. If the patch is not approved, control transfers to 540 and adds the patch to the patch workbench. After adding the patch to the patch workbench at 540, control continues to 544 and waits for new instructions (for example, hints, constraints, or edits for the patcher swarm). Once new instructions have been received, control returns to 516. At 528, control builds the patch and pushes it to a repository. After 528, control ends.Al GENT STRUCTURE

[0059] In various embodiments, Al agents are structured as a collaborative network of highly specialized agents operating within a computational graph. Each agent has a narrowly defined role, deliberately constrained to improve accuracy, reduce errors, and minimize the risk of hallucinations inherent in Al-driven workflows.

[0060] Agents are specialized for distinct tasks, such as patch seeking, patch analysis, patch detail gathering, patch viability assessment, patch generation, patch fixing, and patch summarization. Agents coordinate dynamically and adaptively within the graph structure, interacting through well-defined interfaces and shared contextual memory. Decision points and branching logic allow agent workflows to respond intelligently to real-time analysis outcomes, complexity of patches, compatibility considerations, and the specific details of vulnerabilities. When patches are particularly complex - such as being embedded within large commit histories or significantly incompatible with the target repository - specialized reasoning (such as OpenAI’s ol reasoning model) and code-generation capable LLMs (such as GPT-4.5) are selectively invoked.EXAMPEES

[0061] FIG. 1 is a functional block diagram of an example system for resolving vulnerabilities. Vulnerability analysis and resolution system (VARS) 104 is used to remediate images stored in image storage 106. VARS 104 is managed by workflow logic module 176, which coordinates and controls the various modules of VARS 104. In various embodiments, workflow logic module 176 stores the locations of various resources, such as user credentials, images, etc. Image storage 106 stores one or more system images that require remediation and / or stores images that have been remediated (also called patched images). Image scanner 120 scans images from image storage 106 for vulnerabilities identified by vulnerability database 112. ImageAttorney Docket No. 55882-5 scanner 120 outputs a list of vulnerabilities found in a respective image. In various embodiments, the list of vulnerabilities includes metadata such as vulnerability locations in the image and / or severity metrics. In various embodiments, images are also scanned by optional image scanner 108 and the vulnerability output is transmitted to VARS 104. In various embodiments, optional image scanner 108 is external to VARS 104.

[0062] The list of vulnerabilities from optional image scanner 108 and / or image scanner 120 is transmitted to severity scoring module 132 and applicability and context module 124. Severity scoring module 132 determines the severity of each vulnerability found in an image. In various embodiments, the severity metric is based on a score assigned by a third-party scoring system and / or whether confidential information can be accessed or altered. In various embodiments, severity scoring module 132 includes one or more Al agents that collect data from third-party scoring systems, determine whether confidential information can be accessed or altered, and determine the severity metric.

[0063] Priority determination module 136 determines a priority of the vulnerabilities found in the image based on the severity metric determined by severity scoring module 132, user preferences stored in user preference module 160, and / or feedback data from community collaboration module 152. In various embodiments, priority determination module 136 includes one or more Al agents that determine the priority based on the user preferences, community feedback data, and / or the severity metric. For example, feedback data may indicate that a particular vulnerability requires extensive internal access before it can be exploited and therefore is a low priority vulnerability. As another example, a user associated with the respective image may only require certain types of vulnerabilities to be addressed. Feedback data can be provided to community collaboration module 152 by user device 180 via collaboration API 168 and / or user interface module 172. In various embodiments, community collaboration module 152 includes one or more Al agents that determine how community comments affect the severity metric and / or vulnerability triage. User interface module 172 can also be used to set user preferences used by user preference module 160. In various embodiments, user preference module 160 stores user credentials required to access image storage 106 and the location (such as a web address or IP address) of image storage 106. In various embodiments, user preference module 160 stores and / or manages the importance of various types of vulnerabilities to the user.

[0064] Threshold determination module 140 determines whether vulnerabilities found in the image meet a seven ty / priority threshold (in other words, whether vulnerabilities meet the severity / priority threshold required for remediation).

[0065] Applicability and context module 124 determines whether the vulnerabilities found in the image are applicable to the image system. For example, some vulnerabilities are only applicable to systems of a certain type, such as Intel, AMD, ARM, or other instruction sets. As another example, a particular configuration of a system may have a critical vulnerability, but if the system does not use the particular configuration, the critical vulnerability can be ignored. In various embodiments, applicability and context module 124 includes one or more Al agents that determine whether the vulnerabilities are applicable by determining the image configuration andAttorney Docket No. 55882-5 context. Triage module 144 uses information from applicability and context module 124 and threshold determination module 140 to create an actionable list of vulnerabilities. In various embodiments, triage module 144 includes one or more triage agents that determine the actionable list of vulnerabilities.

[0066] Patch generation and validation module 148 collects patches from patch resources 1 16. Patch generation and validation module 148 includes various Al specialized agents such as a patch-seeking agent, a patch viability agent, a patch generation agent, a patch adapting agent, etc. The patch-seeking agent collects patches from patch resources 116. In various embodiments, patch resources 116 includes open-source databases. The patch viability agent of patch generation and validation module 148 validates available patches for the actionable list of vulnerabilities from triage module 144. For some vulnerabilities, a patch may not be available or may need to be adapted by the patch adapting agent for a system and / or architecture. The patch is generated by the patch generation agent of patch generation and validation module 148 and is then applied via a patching agent of patching module 128. In various embodiments, patching is performed by creating a new Docker file with a new layer containing the differences between the old and new image. In various embodiments, the new Docker file layer includes actions that need to be performed to apply to the patch to that layer.

[0067] The remediated image is re-scanned by image scanner 120. Security review module 164 compares the unpatched and the remediated image to confirm that the actionable vulnerabilities have been eliminated. In various embodiments, security review module 164 includes one or more review Al agents that review the images to confirm that vulnerabilities have been eliminated. A report of the image remediation is transmitted by security review module 164 to user interface module 172. In various embodiments, the report includes a software bill of materials (in other words, the source of all the patches used) and / or VEX statements. The remediated image is saved to image storage 106. In various embodiments, security review module 164 is manually assisted by one or more security experts via security expert device(s) 184. In various embodiments, security expert device(s) 184 are used to develop additional patches and / or determine the priority of various vulnerabilities.

[0068] FIGS. 2A-2C together are a flowchart of an example method for resolving vulnerabilities. At 202, control starts (for example, based on a scheduled interval or event) and determines whether there are unscanned images (for example, images stored in image storage 106 and determined by user preferences). If there are no unscanned images, control ends. If there are unscanned images, control continues to 204 and selects an unscanned image. At 206, control receives a set of vulnerabilities from an image scanner (for example, after the image scanner has scanned the selected image). At 208, control determines the architecture of the selected image. At 210, control selects a first vulnerability of the set of vulnerabilities received from the image scanner. At 212, control determines whether the selected vulnerability is related to the image architecture. If the selected vulnerability is related to the image architecture, control transfers to 228. If the selected vulnerability is not related to the image architecture, control transfers to 214.Attorney Docket No. 55882-5

[0069] At 214, control removes the selected vulnerability from the set of vulnerabilities and continues to 216. At 216, control determines whether there are unreviewed vulnerabilities remaining. If there are unreviewed vulnerabilities remaining, control transfers to 218 and selects the next vulnerability. If there are no unreviewed vulnerabilities remaining, control transfers to 220.

[0070] At 220, control applies a patch list (which is generated as depicted in FIG. 2C) to the selected image. At 222, control determines whether the patch list is applicable to other (unselected) images. If the patch list is not applicable to other images, control returns to 202. If the patch list is applicable to other images, control transfers to 224 and marks the other applicable images as scanned. At 226, control applies the patch list to the applicable images and returns to 202.

[0071] At 228, control determines the context in which the selected vulnerability is applicable. At 230, control determines whether the vulnerability context and the image context are the same. If the vulnerability context is not applicable to the image, control transfers to 214. If the vulnerability context is applicable to the image, control transfers to 232. At 232, control determines whether the vulnerability is applicable based on user preferences. If the vulnerability is not applicable based on user preferences, control transfers to 214. If the vulnerability is applicable based on user preferences, control transfers to 234 and determines the severity of the vulnerability. At 236, control determines whether the severity meets a severity threshold. If the severity is not above a severity threshold, control transfers to 214. If the severity has met the severity threshold, control transfers to 238. At 238, control determines similar secondary users. At 240, control determines whether the vulnerability is applicable to the image based on user preferences of similar secondary users. If the vulnerability is applicable based on the secondary users, control transfers to 242. If the vulnerability is not applicable based on the secondary users, control transfers to 214.

[0072] At 242, control determines whether a patch exists for the selected vulnerability. If there is no existing patch, control transfers to 254. If there is an existing patch, control transfers to 246. At 254, control marks the vulnerability as outstanding and returns to 216. At 246, control determines whether the patch is designed for the image context. If the patch is designed for the image context, control transfers to 252. If the patch is not designed for the image context, control transfers to 248.

[0073] At 252, control adds the vulnerability to the patch list and returns to 216. At 248, control determines whether adjusting the patch for the image context is possible. If adjustment is not possible, control transfers to 254. If adjustment is possible, control transfers to 250. At 250, control adjusts the patch for the image context and transfers to 252.

[0074] FIG. 3 is a flowchart of an example method for applying existing patches to system images. Control begins at 304 and determines whether a new patch is available for an existing vulnerability. If there is no new patch, control remains at 304. If a new patch is available, control transfers to 308. At 308, control determines a set of images where the new patch is applicable. At 312, control determines whether the set of images is an empty set. If the set of images isAttorney Docket No. 55882-5 empty, control returns to 304. If the set of images is not empty, control continues to 316 and marks the set of images as unscanned, and initiates the patching process (for example, by transferring to 202 in FIG. 2A).CONCLUSION

[0075] The foregoing description is merely illustrative in nature and is in no way intended to limit the disclosure, its application, or uses. The broad teachings of the disclosure can be implemented in a variety of forms. Therefore, while this disclosure includes particular examples, the true scope of the disclosure should not be so limited since other modifications will become apparent upon a study of the drawings, the specification, and the following claims. In the written description and claims, one or more steps within a method may be executed in a different order (or concurrently) without altering the principles of the present disclosure. Similarly, one or more instructions stored in a non-transitory computer-readable medium may be executed in a different order (or concurrently) without altering the principles of the present disclosure. Unless indicated otherwise, numbering or other labeling of instructions or method steps is done for convenient reference, not to indicate a fixed order.

[0076] Further, although each of the embodiments is described above as having certain features, any one or more of those features described with respect to any embodiment of the disclosure can be implemented in and / or combined with features of any of the other embodiments, even if that combination is not explicitly described. In other words, the described embodiments are not mutually exclusive, and permutations of one or more embodiments with one another remain within the scope of this disclosure.

[0077] Spatial and functional relationships between elements (for example, between modules) are described using various terms, including “connected,” “coupled,” and “engaged.” Unless explicitly described as being “direct,” when a relationship between first and second elements is described in the above disclosure, that relationship encompasses a direct relationship where no other intervening elements are present between the first and second elements as well as an indirect relationship where one or more intervening elements are present between the first and second elements.

[0078] The term “set” generally means a grouping of one or more elements. The elements of a set do not necessarily need to have any characteristics in common or otherwise belong together. However, in various implementations a “set” may, in certain circumstances, be the empty set (in other words, the set has zero elements in those circumstances). As an example, a set of search results resulting from a query may, depending on the query, be the empty set. In contexts where it is not otherwise clear, the term “non-empty set” can be used to explicitly denote exclusion of the empty set — that is, a non-empty set will always have one or more elements.

[0079] A “subset” of a first set generally includes some of the elements of the first set. In various implementations, a subset of the first set is not necessarily a proper subset: in certain circumstances, the subset may be coextensive with (equal to) the first set (in other words, the subset may include the same elements as the first set). In contexts where it is not otherwise clear,Attorney Docket No. 55882-5 the term “proper subset” can be used to explicitly denote that a subset of the first set must exclude at least one of the elements of the first set. Further, in various implementations, the term “subset” does not necessarily exclude the empty set. As an example, consider a set of candidates that was selected based on first criteria and a subset of the set of candidates that was selected based on second criteria; if no elements of the set of candidates met the second criteria, the subset may be the empty set. In contexts where it is not otherwise clear, the term “non-empty subset” can be used to explicitly denote exclusion of the empty set.

[0080] The phrase “at least one of A, B, and C” should be construed to mean a logical (A OR B OR C), using a non-exclusive logical OR, and should not be construed to mean “at least one of A, at least one of B, and at least one of C.” The phrase “at least one of A, B, or C” should be construed to mean a logical (A OR B OR C), using a non-exclusive logical OR.

[0081] In the figures, the direction of an arrow, as indicated by the arrowhead, generally demonstrates the flow of information (such as data or instructions) that is of interest to the illustration. For example, when element A and element B exchange a variety of information, but information transmitted from element A to element B is relevant to the illustration, the arrow may point from element A to element B. This unidirectional arrow does not imply that no other information is transmitted from element B to element A. Further, for information sent from element A to element B, element B may send requests for, or receipt acknowledgments of, the information to element A.

[0082] In this application, including the definitions below, the term “module” can be replaced with the term “controller” or the term “circuit.” In this application, the term “controller” can be replaced with the term “module.” The term “module” may refer to, be part of, or include processor hardware (shared, dedicated, or group) that executes code coupled with memory hardware (shared, dedicated, or group) that stores code executed by the processor hardware.

[0083] The module may include one or more interface circuits. In some examples, the interface circuit(s) may implement wired or wireless interfaces that connect to a local area network (LAN) or a wireless personal area network (WPAN). Examples of a LAN are Institute of Electrical and Electronics Engineers (IEEE) Standard 802.11-2020 (also known as the WIFI wireless networking standard) and IEEE Standard 802.3-2018 (also known as the ETHERNET wired networking standard). Examples of a WPAN are IEEE Standard 802.15.4 (including the ZIGBEE standard from the ZigBee Alliance) and, from the Bluetooth Special Interest Group (SIG), the BLUETOOTH wireless networking standard (including Core Specification versions 3.0, 4.0, 4.1, 4.2, 5.0, and 5.1 from the Bluetooth SIG).

[0084] The module may communicate with other modules using the interface circuit(s). Although the module may be depicted in the present disclosure as logically communicating directly with other modules, in various implementations the module may actually communicate via a communications system. The communications system includes physical and / or virtual networking equipment such as hubs, switches, routers, and gateways. In some implementations, the communications system connects to or traverses a wide area network (WAN) such as the Internet. For example, the communications system may include multiple LANs connected toAttorney Docket No. 55882-5 each other over the Internet or point-to-point leased lines using technologies including Multiprotocol Label Switching (MPLS) and virtual private networks (VPNs).

[0085] In various implementations, the functionality of the module may be distributed among multiple modules that are connected via the communications system. For example, multiple modules may implement the same functionality distributed by a load balancing system. In a further example, the functionality of the module may be split between a server (also known as remote, or cloud) module and a client (or, user) module. For example, the client module may include a native or web application executing on a client device and in network communication with the server module.

[0086] The term code, as used above, may include software, firmware, and / or microcode, and may refer to programs, routines, functions, classes, data structures, and / or objects. Shared processor hardware encompasses a single microprocessor that executes some or all code from multiple modules. Group processor hardware encompasses a microprocessor that, in combination with additional microprocessors, executes some or all code from one or more modules. References to multiple microprocessors encompass multiple microprocessors on discrete dies, multiple microprocessors on a single die, multiple cores of a single microprocessor, multiple threads of a single microprocessor, or a combination of the above.

[0087] The memory hardware may also store data together with or separate from the code. Shared memory hardware encompasses a single memory device that stores some or all code from multiple modules. One example of shared memory hardware may be level 1 cache on or near a microprocessor die, which may store code from multiple modules. Another example of shared memory hardware may be persistent storage, such as a solid-state drive (SSD) or magnetic hard disk drive (HDD), which may store code from multiple modules. Group memory hardware encompasses a memory device that, in combination with other memory devices, stores some or all code from one or more modules. One example of group memory hardware is a storage area network (SAN), which may store code of a particular module across multiple physical devices. Another example of group memory hardware is random access memory of each of a set of servers that, in combination, store code of a particular module. The term memory hardware is a subset of the term computer-readable medium.

[0088] The apparatuses and methods described in this application may be partially or fully implemented by a special-purpose computer created by configuring a general-purpose computer to execute one or more particular functions embodied in computer programs. Such apparatuses and methods may be described as computerized or computer-implemented apparatuses and methods. The functional blocks and flowchart elements described above serve as software specifications, which can be translated into the computer programs by the routine work of a skilled technician or programmer.

[0089] The computer programs include processor-executable instructions that are stored on at least one non-transitory computer-readable medium. The computer programs may also include or rely on stored data. The computer programs may encompass a basic input / output system (BIOS) that interacts with hardware of the special-purpose computer, device drivers that interactAttorney Docket No. 55882-5 with particular devices of the special-purpose computer, one or more operating systems, user applications, background services, background applications, etc.

[0090] The computer programs may include: (i) descriptive text to be parsed, such as HTML (hypertext markup language), XML (extensible markup language), or JSON (JavaScript Object Notation), (ii) assembly code, (iii) object code generated from source code by a compiler, (iv) source code for execution by an interpreter, (v) source code for compilation and execution by a just-in-time compiler, etc. As examples only, source code may be written using syntax from languages including C, C++, C#, Objective C, Swift, Haskell, Go, SQL, R, Lisp, Java®, Fortran, Perl, Pascal, Curl, OCaml, JavaScript®, HTML5 (Hypertext Markup Language 5th revision), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash®, Visual Basic®, Lua, MATLAB, SIMULINK, and Python®.

[0091] The term non-transitory computer-readable medium does not encompass transitory electrical or electromagnetic signals propagating through a medium (such as on a carrier wave). Non-limiting examples of a non-transitory computer-readable medium are nonvolatile memory circuits (such as a flash memory circuit, an erasable programmable read-only memory circuit, or a mask read-only memory circuit), volatile memory circuits (such as a static random access memory circuit or a dynamic random access memory circuit), magnetic storage media (such as an analog or digital magnetic tape or a hard disk drive), and optical storage media (such as a CD, a DVD, or a Blu-ray Disc).

Claims

Attorney Docket No. 55882-5CLAIMS1. A system comprising: memory hardware configured to store instructions; and processor hardware configured to execute the instructions, wherein the instructions include: receiving a set of vulnerabilities associated with a containerized system image from an image scanner; programmatically triaging the set of vulnerabilities to create a subset of vulnerabilities; automatically generating a patch for the subset of vulnerabilities; and automatically applying the patch to the containerized system image.

2. The system of claim 1 wherein the instructions include: sending the containerized system image to the image scanner; and scanning the containerized system image with the image scanner.

3. The system of claim 1 wherein triaging the set of vulnerabilities includes: determining an architecture associated with the containerized system image; determining a context associated with the containerized system image; and determining whether a severity metric of a respective vulnerability of the set of vulnerabilities has met a severity threshold.

4. The system of claim 3 wherein triaging the set of vulnerabilities includes determining a priority metric based on a set of crowd-sourced data.

5. The system of claim 3 wherein: the instructions include determining the severity metric of the respective vulnerability, and the severity metric is based on at least one of: data from a set of public datastores, and a set of crowd-sourced data.

6. The system of claim 1 wherein: the instructions include receiving a set of crowd-sourced data, and the set of crowd-sourced data includes at least one of: a set of persona data, a set of expert data, or a set of comments.Attorney Docket No. 55882-57. The system of claim 1 wherein: automatically generating the patch for the subset of vulnerabilities includes adapting a respective patch associated with a first operating system for a second operating system, the second operating system is different from the first operating system, and the second operating system is associated with the containerized system image.

8. A method comprising: receiving a set of vulnerabilities associated with a containerized system image from an image scanner; programmatically triaging the set of vulnerabilities to create a subset of vulnerabilities; automatically generating a patch for the subset of vulnerabilities; and automatically applying the patch to the containerized system image.

9. The method of claim 8 further comprising: sending the containerized system image to the image scanner; and scanning the containerized system image with the image scanner.

10. The method of claim 8 wherein triaging the set of vulnerabilities includes: determining an architecture associated with the containerized system image; determining a context associated with the containerized system image; and determining whether a severity metric of a respective vulnerability of the set of vulnerabilities has met a severity threshold.

11. The method of claim 10 wherein triaging the set of vulnerabilities includes determining a priority metric based on a set of crowd-sourced data.

12. The method of claim 10 further comprising determining the severity metric of the respective vulnerability, wherein the severity metric is based on at least one of: data from a set of public datastores, and a set of crowd- sourced data.

13. The method of claim 8 further comprising receiving a set of crowd-sourced data, wherein the set of crowd-sourced data includes at least one of: a set of persona data, a set of expert data, or a set of comments.

14. The method of claim 8 wherein: automatically generating the patch for the subset of vulnerabilities includes adapting a respective patch associated with a first operating system for a second operating system, the second operating system is different from the first operating system, and the second operating system is associated with the containerized system image.Attorney Docket No. 55882-515. A non- transitory computer-readable medium comprising processor-executable instructions, the instructions including: receiving a set of vulnerabilities associated with a containerized system image from an image scanner; programmatically triaging the set of vulnerabilities to create a subset of vulnerabilities; automatically generating a patch for the subset of vulnerabilities; and automatically applying the patch to the containerized system image.

16. The non- transitory computer-readable medium of claim 15 wherein the instructions include: sending the containerized system image to the image scanner; and scanning the containerized system image with the image scanner.

17. The non-transitory computer-readable medium of claim 15 wherein triaging the set of vulnerabilities includes: determining an architecture associated with the containerized system image; determining a context associated with the containerized system image; and determining whether a severity metric of a respective vulnerability of the set of vulnerabilities has met a severity threshold.

18. The non-transitory computer-readable medium of claim 17 wherein: triaging the set of vulnerabilities includes determining a priority metric based on a set of crowd-sourced data, the instructions include determining the severity metric of the respective vulnerability, and the severity metric is based on at least one of: data from a set of public datastores, and the set of crowd-sourced data.

19. The non-transitory computer-readable medium of claim 15 wherein: the instructions include receiving a set of crowd-sourced data, and the set of crowd-sourced data includes at least one of: a set of persona data, a set of expert data, or a set of comments.

20. The non-transitory computer-readable medium of claim 15 wherein: automatically generating the patch for the subset of vulnerabilities includes adapting a respective patch associated with a first operating system for a second operating system, the second operating system is different from the first operating system, and the second operating system is associated with the containerized system image.

Images