Event-Driven, Host-Specific Vulnerability Remediation Using Model-Generated Deterministic Tests with Configurable Human Oversight

Inventor(s)

• Jerry F. Howell IIFollow

Abstract

Abstract

A system and method for event-driven, host-specific assessment and remediation of software vulnerabilities.

A host-side service maintains an updated inventory of installed software and relevant system components, including package identities, versions, repository provenance, dependencies, libraries, kernel components, and configuration information. The service monitors multiple vulnerability information sources, normalizes incoming reports, and deterministically matches reported vulnerabilities against the host inventory.

Only relevant vulnerability events trigger model-assisted investigation, reducing unnecessary inference activity. Vulnerability applicability is evaluated in the context of the individual host rather than solely by comparing upstream version numbers. Assessment may account for distribution-specific security backports, package revisions, build configuration, component presence, and runtime usage.

An optional classification stage evaluates candidate vulnerabilities before invoking a more capable remediation agent. The agent generates deterministic tests specific to the reported vulnerability. Generated tests are validated against known-vulnerable and fixed or patched versions before their results are relied upon. Tests capable of triggering the defect may be executed in an isolated environment.

When a host is confirmed vulnerable, the agent generates a remediation patch, including when an upstream or vendor fix is not yet available. The patch may be deployed as a package-manager-tracked local package. Original system state is preserved, the patch is verified by rerunning the test, regression and variant testing, and restarting affected processes, and it is rolled back on failure.

When the upstream fix arrives, a user-selected policy (upstream wins, keep local, or compare and reconcile) is applied after re-running the same test. Every stage can be set to automatic, notify, or require approval. Feed content is treated as untrusted data, and only a deterministic harness modifies the host. Verified patches, with tests and provenance, may optionally be contributed upstream after human review.

1. Technical Field

The disclosure relates to computer security, vulnerability management, automated software remediation, operating system package management, and model-assisted software maintenance.

More particularly, it describes an event-driven system for determining whether reported software vulnerabilities affect a particular host, generating and validating vulnerability-specific tests, producing and applying remediation patches, and verifying remediation through deterministic execution.

The system supports configurable levels of autonomy and human oversight throughout the remediation process.

2. Background

Conventional vulnerability management systems commonly identify potentially affected software by comparing installed package names and versions against known vulnerability information.

This approach can produce inaccurate results when applied to distributions that maintain their own security patches.

For example, a distribution may backport a security fix into an older package version without adopting the upstream version number in which the fix originally appeared. A scanner relying exclusively on upstream version comparisons may consequently report a vulnerability that has already been fixed.

Conversely, the presence of a matching package version does not necessarily establish that the vulnerable component is present in a relevant configuration, used by the system, or exposed to the conditions required to trigger the vulnerability.

Traditional vulnerability management also tends to depend on the availability of an official vendor or distribution patch. Between disclosure of a vulnerability and availability of an official fix, systems may remain exposed.

A further limitation is that vulnerability detection, patch development, and patch verification are often separate activities. A reported vulnerability may be recorded without an independent demonstration that the installed system is actually affected or that a proposed remediation resolves the defect.

There is therefore a need for a system that combines host-specific vulnerability assessment, vulnerability-specific testing, automated patch generation, deterministic verification, and configurable remediation autonomy.

3. Related Work and Prior Art

The following systems and research efforts establish relevant prior work in automated vulnerability discovery, vulnerability assessment, patch generation, dependency scanning, and security remediation. They are identified to describe the existing technical landscape and the context of the present disclosure.

3.1 DARPA AI Cyber Challenge (AIxCC)

DARPA launched the Artificial Intelligence Cyber Challenge (AIxCC) in 2023 as a two-year competition intended to develop artificial intelligence-enabled cyber reasoning systems capable of automatically finding and fixing vulnerabilities in critical open-source software.[1]

The competition culminated in 2025. Its participating systems demonstrated automated vulnerability discovery, proof generation, and patch development. In the final competition, participating systems discovered 54 unique synthetic vulnerabilities across 63 challenges and patched 43. They also discovered 18 real, non-synthetic vulnerabilities and submitted 11 patches for real vulnerabilities.[2]

AIxCC established that model-assisted and autonomous cyber reasoning systems can perform meaningful vulnerability discovery and software repair at scale.

The competition primarily evaluated cyber reasoning systems against designated software projects and challenge environments. The present disclosure addresses a different operational context: continuous monitoring and remediation of an individual installed host, including its package inventory, distribution-specific revisions, configuration, and runtime conditions.

3.2 All You Need Is A Fuzzing Brain / FuzzingBrain

The team known during AIxCC as all_you_need_is_a_fuzzing_brain developed an LLM-powered cyber reasoning system for automated vulnerability discovery and patching. Its technical paper describes a system that autonomously discovered vulnerabilities, including previously unknown vulnerabilities, and generated patches during the AIxCC competition.[3]

The associated FuzzingBrain project describes its approach as an end-to-end process for finding, proving, and fixing security vulnerabilities. Its published technical descriptions include iterative LLM refinement, multiple model strategies, static and dynamic analysis, fuzzing, coverage feedback, and automated patch generation.[4]

As of the preparation of this disclosure, the project's website reports 124 vulnerabilities reported across 53 open-source projects and 82 patches merged upstream.[4] These are project-reported cumulative results and are distinct from the competition-specific results documented in its 2025 technical paper.

FuzzingBrain is relevant prior work demonstrating autonomous vulnerability discovery, proof generation, and patch development. Its described workflow focuses on finding and repairing vulnerabilities in targeted software projects. The present disclosure focuses on applying vulnerability assessment and remediation to the software actually installed on an individual host, including locally deployed patches and their subsequent lifecycle within the host's package-management environment.

3.3 Google DeepMind CodeMender

Google DeepMind introduced CodeMender in October 2025 as an AI agent for automated software security improvements.[5]

CodeMender analyzes vulnerable code, identifies root causes, generates patches, and validates proposed changes. Its documented techniques include static and dynamic analysis, differential testing, fuzzing, SMT solvers, and specialized critique agents.

Google DeepMind reported that CodeMender had upstreamed 72 security fixes during its first six months of development. It also stated that generated patches were reviewed by human researchers before upstream submission.[5]

CodeMender establishes relevant prior work in model-assisted vulnerability remediation, patch validation, and proactive software security improvement.

The present disclosure addresses an additional system-management context: detecting vulnerabilities in an individual host's installed software, determining host-specific applicability, generating locally deployable fixes before upstream remediation is available, and managing those fixes through package-manager-aware deployment, rollback, and subsequent upstream reconciliation.

3.4 Existing Dependency and Vulnerability Scanners

Several established tools already perform vulnerability matching against package or dependency inventories. Their existence is acknowledged as prior art for vulnerability identification and package matching.

GitHub Dependabot

Dependabot uses GitHub's dependency graph, which identifies dependencies from supported repository manifests, lockfiles, and submitted dependency information. It generates vulnerability alerts and may create pull requests to update affected dependencies to fixed versions.[6]

Dependabot is primarily repository- and dependency-oriented, rather than a continuously operating service assessing all software installed on an individual host.

OSV-Scanner

OSV-Scanner extracts package and dependency information from project files, lockfiles, SBOMs, and supported installed-package representations. Its supported artifacts include Debian and Ubuntu package information from /var/lib/dpkg/status. Extracted package information is matched against known vulnerabilities in the OSV database.[7]

This establishes prior work in deterministic package extraction and vulnerability matching across multiple software ecosystems.

Trivy

Trivy detects vulnerabilities in operating system packages, language-specific packages, and other software components. Its documentation describes scanning container images, virtual machine images, and running hosts for installed OS packages. For operating-system packages, it uses the corresponding vendor security advisories, including Debian security information.[8]

Trivy therefore provides particularly relevant prior art for host and image inventory scanning and distribution-aware vulnerability matching. Its documentation also describes limitations involving third-party packages and the selection of vendor-specific advisory sources.[8]

debsecan

The Debian Security Analyzer, debsecan, analyzes packages installed on the current host and reports known vulnerabilities using Debian security information.[9]

Its documented behavior is relevant to host-specific package vulnerability assessment. Its manual also identifies limitations arising from Debian's source-package-based vulnerability tracking, including cases in which binary packages that do not contain the vulnerable code may still be reported.[9]

These tools establish that installed-package inventory, advisory matching, and vulnerability reporting are known capabilities. The present disclosure does not claim to originate those functions.

3.5 Distinction of the Present Disclosure

The present disclosure is directed to the integration and operation of host-specific applicability assessment, model-generated deterministic test creation and validation, automated local remediation, package-manager-aware patch deployment, deterministic verification, rollback, upstream reconciliation, and configurable human oversight.

The disclosed workflow is not limited to identifying that a package appears in an affected version range.

It seeks to establish whether the particular host exhibits the conditions of the vulnerability, to generate a test capable of distinguishing vulnerable and fixed software states, and to remediate the affected host even when an official fix is not yet available.

The disclosed system further tracks the locally generated remediation through its subsequent lifecycle, including replacement or reconciliation when an upstream fix becomes available.

The related systems above are acknowledged as existing technical work. The disclosure concerns the particular combination and operational arrangement described herein, rather than asserting that automated vulnerability discovery, package scanning, AI-generated patches, or patch validation are individually new.

4. Summary of the Disclosure

The disclosed system combines several operations into an event-driven remediation workflow.

A host inventory is maintained and continuously updated. Vulnerability feeds are monitored independently of model inference. Incoming reports are normalized and matched against the inventory.

When a relevant event is identified, an assessment process determines the likely applicability of the vulnerability to the host. This assessment may use deterministic rules, distribution-specific security information, an optional classification model, and a more capable reasoning model.

For vulnerabilities requiring further investigation, a model generates a deterministic test specific to the vulnerability. The test is validated against reference software states, including a known-vulnerable version and a fixed or patched version.

When vulnerability is confirmed, the remediation agent generates a patch. The patch is applied under the control of a deterministic execution harness, and the original vulnerability test is repeated to verify the result.

The system preserves sufficient state to restore the previous condition if remediation fails. Subsequent official fixes can be handled according to a configurable upstream-patch policy.

Human oversight is configurable independently for individual stages. The system can operate with approval required at each step, with notifications at selected stages, or in a fully automatic configuration.

5. System Architecture

The system may comprise the following logical components.

5.1 Host Inventory Service

Maintains an updated representation of the host's installed software and relevant system state.

Inventory information may include:

• Package name and identity.

• Installed version and distribution-specific package revision.

• Architecture.

• Repository and package provenance.

• Dependencies and dependent packages.

• Installed libraries.

• Kernel and kernel components.

• Relevant software configuration.

• Runtime presence or usage information.

• Other information relevant to determining vulnerability applicability.

The inventory is periodically refreshed and may also be updated in response to package-manager events or other system changes.

5.2 Vulnerability Feed Monitor

Subscribes to multiple vulnerability information sources.

Sources may include:

• General vulnerability databases.

• Distribution security trackers.

• Package maintainer advisories.

• Vendor security advisories.

• Project security announcements.

• RSS and other machine-readable feeds.

The system does not require every source to publish information at the same time. A vulnerability report from one source may trigger investigation before another source, including a distribution-specific tracker, publishes corresponding information.

Incoming reports are normalized into a common internal representation.

5.3 Matching and Event Generation

A deterministic matching component compares normalized vulnerability reports against the host inventory.

Matching may use package identities, affected components, version ranges, distribution revisions, dependencies, and other available information.

A matching or potentially matching report produces a vulnerability event.

This event-driven architecture avoids continuously invoking a language model when no relevant vulnerability event exists.

5.4 Applicability Assessment Component

Evaluates whether a candidate vulnerability affects the particular host.

The component may consider:

• Installed package identity and revision.

• Distribution-specific security status.

• Known backported fixes.

• Build and compilation configuration.

• Presence of affected components.

• Runtime usage.

• Relevant system configuration.

• Conditions required to trigger the vulnerability.

The assessment is not restricted to a binary comparison between installed and upstream package versions.

5.5 Optional Classification Component

An optional small classification model may operate between deterministic matching and more extensive model-assisted investigation.

The classifier evaluates candidate vulnerability events and produces a structured assessment containing a classification, supporting evidence, confidence information, and unresolved uncertainties.

Possible classifications include:

• Not applicable.

• Already fixed.

• Potentially affected.

• Likely affected.

• Confirmed vulnerable.

• Needs investigation.

The classification stage may reduce unnecessary invocation of more capable models.

The classifier is optional and does not replace deterministic verification.

5.6 Remediation Agent

A language-model-based agent performs reasoning-intensive operations, including:

• Investigating vulnerability reports.

• Evaluating vulnerability conditions.

• Designing vulnerability-specific tests.

• Interpreting test results.

• Generating remediation patches.

• Reviewing failures and proposing corrections.

• Evaluating upstream fixes against locally generated patches.

The agent may be invoked only when a relevant event requires its participation.

5.7 Deterministic Execution Harness

Controls the execution of tests and system modifications.

The harness is responsible for executing approved or automatically authorized operations, managing relevant state, recording results, and enforcing the configured workflow.

The model generates tests and patches; the harness executes them.

The harness may provide:

• Test execution.

• Patch application.

• Package-manager integration.

• Isolation or sandboxing.

• Backup and restoration.

• Verification.

• Retry handling.

• Logging and provenance records.

Vulnerability feed content and other external information are treated as untrusted data rather than executable instructions to the host.

The harness, rather than the model directly, performs host modifications.

6. Vulnerability Applicability Assessment

A vulnerability report does not necessarily establish that the reported vulnerability affects a particular system.

The system therefore distinguishes between the existence of a vulnerability in a software project and its applicability to an individual host.

For example, a package may have an upstream version number falling within a reported affected range while the installed distribution package already contains a backported security fix.

The applicability assessment may combine deterministic version and package analysis with distribution-specific advisory information and configuration or runtime inspection.

The system may assign one of several graded outcomes: OutcomeMeaning Not applicable The affected software or required conditions are absent Already fixed An applicable security fix is already present Potentially affected The host matches some vulnerability conditions, but applicability is unresolved Likely affected Available evidence strongly indicates applicability Confirmed vulnerable A validated vulnerability test demonstrates the affected behavior Needs investigation Available information is insufficient or conflicting

The assessment may retain supporting evidence and uncertainty information for subsequent review.

A vulnerability's reported severity is treated separately from its applicability. A high-severity vulnerability may not affect a particular host, while a lower-severity vulnerability may be directly relevant to that host.

7. Model-Generated Deterministic Vulnerability Tests

For a vulnerability requiring further investigation, the remediation agent generates a test designed to determine whether the specific vulnerability is present.

The generated test is an executable, deterministic test rather than an independent autonomous agent.

The test may check for a specific vulnerable behavior, configuration, or condition.

7.1 Test Validation

A test result should not be relied upon merely because a generated script executes successfully.

Before a negative result is accepted as evidence that the vulnerability is absent, the test is validated against reference software states.

In one embodiment:

1. The test is executed against a known-vulnerable build.

2. The test is required to fail, indicating that the vulnerable behavior is present.

3. The test is executed against a known-fixed or patched build.

4. The test is required to pass, indicating that the vulnerable behavior has been eliminated.

5. The test is accepted for subsequent host assessment only after satisfying the validation criteria.

This process helps distinguish a functioning vulnerability test from a test that simply fails to detect the defect.

7.2 Isolated Test Execution

Tests capable of triggering vulnerable behavior may be executed in an isolated environment.

Isolation may be provided through a sandbox, container, virtual machine, test image, or other execution boundary.

The degree and type of isolation may depend on the vulnerability and the configured execution policy.

7.3 Test Results

Test results are recorded and associated with the relevant vulnerability, test implementation, software version, and execution environment.

The test may subsequently be reused to verify a generated patch and to evaluate an official upstream fix.

8. Automated Remediation Patch Generation

When the host is confirmed vulnerable, the remediation agent generates a patch intended to eliminate the identified defect.

The system is not limited to applying patches already published by a software vendor or distribution.

It may generate a local remediation patch during the period between vulnerability disclosure and availability of an official fix.

The remediation workflow may include:

1. Analysis of the vulnerable component.

2. Identification of the defect.

3. Generation of corrective changes.

4. Construction of a locally deployable package.

5. Application of the patch.

6. Re-execution of the original vulnerability test.

7. Additional regression or variant testing.

The patch and its associated metadata are retained for subsequent verification, rollback, and upstream reconciliation.

9. Package-Manager-Tracked Patch Deployment

A generated remediation may be deployed as a package-manager-tracked local package rather than as an untracked modification to installed files.

In one embodiment, the local patch is incorporated into a locally built package with versioning and package metadata that allow the package manager to track its installation and subsequent replacement.

The local package may be constructed so that the official security-fixed package supersedes the local remediation by default when the official fix becomes available.

This avoids leaving the system dependent on unmanaged modifications that may be overwritten or lost during normal package operations.

The implementation may use a local package repository, distribution-native package construction, version ordering, or other package-manager-compatible mechanisms.

10. Verification, Regression Testing, and Rollback

After patch application, the system verifies remediation by repeating the original vulnerability-specific test.

Additional verification may include:

• Regression tests.

• Variant tests.

• Relevant service or process restarts.

• Checks that the affected component loads or operates correctly.

• Package-manager consistency checks.

• Other tests appropriate to the affected software.

The system does not treat successful patch application alone as proof of successful remediation.

10.1 State Preservation

Before applying a patch, the system preserves the state necessary to restore the host.

Preserved information may include affected files, package versions, package-manager state, configuration, and filesystem snapshots where available.

10.2 Failure Handling

If post-patch verification fails:

1. The system restores the preserved state.

2. The restoration is verified.

3. The failure is recorded.

4. The system may initiate another patch-generation or application attempt according to configured retry policy.

5. The system stops when the configured retry limit is reached.

Retry count, delay, backup retention, and failure notification behavior may be configurable.

11. Upstream Fix Reconciliation

A locally generated remediation may be necessary before an official vendor or distribution patch becomes available.

When an official fix is subsequently released, the system handles it according to a user-selected policy.

Three example policies are:

11.1 Upstream Wins

The official security-fixed package supersedes the locally generated remediation.

11.2 Keep Local

The locally generated patch is retained until the user authorizes replacement.

11.3 Compare and Reconcile

The official patch is compared with the locally generated remediation.

The system may then:

1. Obtain the official fixed package or patch.

2. Compare its changes with the local remediation.

3. Re-run the original vulnerability test.

4. Perform relevant regression testing.

5. Evaluate whether the official package can replace the local package.

6. Transition to the official fix when the configured criteria are satisfied.

The history of the original package, local remediation, test results, and official replacement may be retained as patch provenance.

12. Configurable Human Oversight and Autonomy

The system provides configurable control over individual remediation stages.

Each stage may be configured independently for one of several operating modes:

• Automatic: the system proceeds without requiring human intervention.

• Notify: the system performs the operation and notifies the user.

• Approval required: the system pauses until the user authorizes the operation.

Configurable stages may include:

1. Vulnerability alert handling.

2. Applicability assessment.

3. Test generation.

4. Test execution.

5. Patch generation.

6. Patch application.

7. Post-patch verification.

8. Final commit or rollback.

The user may intervene at any configured approval point.

Additional policy settings may include:

• Vulnerability severity thresholds.

• Package inclusion and exclusion lists.

• Patch deployment policy.

• Maintenance windows.

• Retry limits.

• Backup retention.

• Upstream reconciliation policy.

• Model and backend selection.

• Notification behavior.

• Community contribution preferences.

The system supports both fully automated remediation and operation requiring human approval at every stage.

The degree of autonomy is determined by the user's configuration rather than by a fixed system-wide trust policy.

13. Security of External Inputs and Execution

Vulnerability feeds, advisories, retrieved documents, and other external information are treated as untrusted input.

The existence of a vulnerability report does not itself grant permission to execute arbitrary operations.

Generated tests and patches are passed to the deterministic execution harness, which controls their execution according to the configured policy.

Tests that may trigger vulnerable behavior can be isolated from the host.

The harness records relevant execution activity, test outcomes, patch operations, and restoration results.

The system's model-assisted reasoning and deterministic execution responsibilities are separated: the model proposes tests and patches, while the harness controls their execution and any resulting host modifications.

14. Optional Verified Patch Contributions

The system may provide an optional mechanism for contributing locally developed remediations to an upstream project or shared patch repository.

A contribution may contain:

• The generated patch.

• The affected package and version.

• Associated vulnerability identifiers.

• Test definitions.

• Test results.

• Patch provenance.

• Relevant verification information.

Contribution is opt-in.

Contributed patches may be subject to human review and independent validation before acceptance or distribution.

The system does not automatically distribute locally generated patches from one user's host to other hosts.

15. Deployment Embodiments

The system may operate as a standalone local installation or as part of a centralized architecture.

15.1 Standalone Deployment

A local installation performs inventory maintenance, feed monitoring, matching, model invocation, testing, patching, verification, and rollback on the host.

15.2 Centralized Control Plane with Host-Side Execution

A centralized service may aggregate vulnerability feeds, maintain event queues, and coordinate assessment and remediation workflows.

A lightweight host-side service performs local inventory operations, vulnerability tests, patch application, verification, and rollback.

The host-side service may initiate outbound communication with the control plane.

15.3 Distributed or Hybrid Deployment

Components may be distributed across local hosts and remote services, provided that host-specific state and host modifications remain associated with the relevant execution environment.

The described components may be implemented as separate services or combined into one application.

16. Example Operational Sequence

The following sequence illustrates one possible operation of the system.

1. A host inventory service records an installed package, its distribution revision, repository provenance, dependencies, and relevant configuration.

2. The vulnerability feed monitor receives an advisory identifying a vulnerability in a software component.

3. The report is normalized.

4. The deterministic matching component determines that the host contains a potentially affected package.

5. An event is generated.

6. An optional classifier assesses the report and determines that further investigation is warranted.

7. The remediation agent investigates the vulnerability and generates a deterministic test.

8. The test is validated against a known-vulnerable reference build and a fixed or patched reference build.

9. The validated test is executed against the host, within an appropriate isolation boundary where required.

10. The test confirms that the host exhibits the vulnerable behavior.

11. The remediation agent generates a corrective patch.

12. The harness preserves the original state and constructs or installs the locally tracked patched package.

13. The original vulnerability test is executed again.

14. Regression and variant tests are performed as configured.

15. If verification succeeds, the remediation is recorded as successful.

16. If verification fails, the original state is restored and verified.

17. When an official security fix becomes available, the configured upstream reconciliation policy is applied.

18. The final remediation history and associated test results are retained.

The user may configure any applicable stage to pause for approval or issue a notification.

17. Alternative Implementations and Variations

The disclosure is not limited to a particular operating system, package manager, vulnerability database, model provider, classifier architecture, or deployment topology.

Possible variations include:

• Linux distributions using different package managers.

• Package-based and non-package-based software inventories.

• Multiple vulnerability feed formats.

• Deterministic-only applicability assessment.

• Optional small-model classification.

• Different language models for investigation, test generation, and patch generation.

• Local or remote model inference.

• Different isolation technologies.

• Local, centralized, or distributed execution.

• Alternative mechanisms for preserving and restoring system state.

• Alternative package construction and versioning mechanisms.

• Different human oversight and autonomy policies.

• Optional upstream contribution workflows.

Individual components may be omitted, replaced, combined, or implemented as separate services without departing from the overall event-driven, host-specific remediation approach.

18. Conclusion

The disclosed system combines host-specific vulnerability assessment, model-generated deterministic testing, automated patch generation, package-manager-aware deployment, and verified remediation in an event-driven architecture.

By separating model-assisted reasoning from deterministic execution, the system can use language models for the tasks that require software analysis and patch development while retaining controlled, reproducible execution of tests and system modifications.

The system can generate local fixes before official security patches become available, verify those fixes against vulnerability-specific tests, and reconcile local remediations with subsequent upstream releases.

Configurable human oversight allows the same architecture to support fully autonomous operation or closely supervised remediation.

The result is a general-purpose approach to automated, host-specific software vulnerability remediation.

References and Footnotes

[1] Defense Advanced Research Projects Agency (DARPA), “DARPA AI Cyber Challenge Aims to Secure Nation’s Most Critical Software,” August 9, 2023. Describes the launch of the two-year AI Cyber Challenge and its goal of developing systems to automatically find and fix software vulnerabilities. https://www.darpa.mil/news/2023/ai-cyber-challenge-software

[2] DARPA, “AI Cyber Challenge Marks Pivotal Inflection Point for Cyber Defense,” August 8, 2025. Reports the final competition results, including synthetic vulnerability discovery and patching, as well as real-world vulnerability disclosures and patches. https://www.darpa.mil/news/2025/aixcc-results

[3] Ze Sheng et al., “All You Need Is A Fuzzing Brain: An LLM-Powered System for Automated Vulnerability Detection and Patching,” arXiv:2509.07225, September 2025. Describes the All You Need Is A Fuzzing Brain cyber reasoning system and its AIxCC competition results. https://arxiv.org/abs/2509.07225

[4] FuzzingBrain, “Autonomous Vulnerability Discovery & Patching,” project website, accessed November 3, 2026. Describes its autonomous vulnerability discovery and patching architecture and reports cumulative project results, including 82 upstream-merged patches. These project-reported figures should not be confused with competition-specific figures in [3]. https://fuzzingbrain.github.io/

[5] Google DeepMind, Raluca Ada Popa and Four Flynn, “Introducing CodeMender: An AI Agent for Code Security,” October 6, 2025. Describes the CodeMender security agent, validation techniques, and reported upstream security fixes. https://deepmind.google/blog/introducing-codemender-an-ai-agent-for-code-security/

[6] GitHub Documentation, “How the Dependency Graph Recognizes Dependencies” and “Dependabot Security Updates.” Describes dependency identification from manifests, lockfiles, and submitted dependency information, as well as vulnerability alerts and automated dependency update pull requests. https://docs.github.com/en/code-security/concepts/supply-chain-security/dependency-graph-data https://docs.github.com/en/code-security/concepts/supply-chain-security/dependabot-security-updates

[7] Google, OSV-Scanner Documentation, “Usage,” “Supported Artifacts and Manifests,” and “Project Source Scanning.” Describes extraction and matching of dependency and package information, including supported Debian/Ubuntu dpkg package status information and SBOM formats. https://google.github.io/osv-scanner/usage/ https://google.github.io/osv-scanner/supported-languages-and-lockfiles/ https://google.github.io/osv-scanner/usage/scan-source

[8] Aqua Security, Trivy Documentation, “Vulnerability Scanning.” Describes vulnerability detection for installed OS packages, language-specific packages, container images, VM images, and running hosts, including use of operating-system vendor security advisories. https://trivy.dev/docs/latest/scanner/vulnerability/

[9] Debian Project, debsecan(1) Manual Page, Debian Trixie. Describes analysis of installed packages on the current host and known limitations arising from source-package-based vulnerability tracking. https://manpages.debian.org/trixie/debsecan/debsecan.1.en.html

Creative Commons License

This work is licensed under a Creative Commons Attribution 4.0 License.

Recommended Citation

Howell, Jerry F. II, "Event-Driven, Host-Specific Vulnerability Remediation Using Model-Generated Deterministic Tests with Configurable Human Oversight", Technical Disclosure Commons, ()
https://www.tdcommons.org/dpubs_series/12731