Enji Guard

Vulnerability autofix: what Guard can change, and where review stays in control

Turn security audit evidence into a focused fix run, with a GitHub issue by default and a pull request when the patch is clear enough to review. The useful question is what the run can trust, what it can change, and what a later audit or rerun must verify.

What it runs

Vulnerability autofix is part of Guard's improvement loop. The run takes one verified surface and tries to move it forward after audit or product evidence makes the next step clear.

That does not give Guard open-ended permission to rewrite the repository. The run keeps the work small, records why this candidate was chosen, and produces output a person can review before anything lands.

Its closest audit source is Security audit, but the improvement still checks the current repository before proposing work.

Starting evidence

Security audit evidence, current repository files, GitHub issue or pull-request history, and the requested write mode.

Earlier Guard context helps only when it still matches the target. The run revalidates access, looks for duplicate GitHub work, and treats stale or missing evidence as a reason to stop rather than a reason to guess.

Allowed change

The run starts from security-audit context, revalidates the current repository, and works on one credible candidate instead of trying to clear a whole vulnerability backlog.

  • Narrow security hardening in the affected code path.
  • A reviewable GitHub issue when the code change needs product judgment.
  • A pull request only when the patch and verification are bounded.
Auto improvements

One focused run keeps the change small enough to review.

Auto improvementsVulnerability autofix

Turn security audit evidence into a focused fix run, with a GitHub issue by default and a pull request when the patch is clear enough to review.

Enabled
Run nowEnable regular
The Guard control keeps the selected improvement, current state, immediate run, and recurring schedule in one compact surface.

Boundaries

Guard improvements stay useful because they are constrained. A run stops or falls back to a report when repository access, target scope, source context, or the write path is not clear enough.

  • It does not merge changes automatically.
  • It does not trust stale audit context when current code contradicts it.
  • It does not broaden a focused fix into a security refactor.

Candidate selection

Guard chooses a candidate only when the source context still matches the repository and the remediation can be explained, verified, and reviewed.

  1. 1

    Resolve the target

    Read the repository identity, selected improvement, and any linked website or paired audit context.

  2. 2

    Validate current state

    Check repository access and current files before relying on earlier Guard evidence.

  3. 3

    Deduplicate existing work

    Read relevant GitHub issues and pull requests so Guard does not repeat stale findings or rejected fix patterns.

  4. 4

    Pick the smallest useful candidate

    Prefer one improvement that can be explained, reviewed, and verified.

  5. 5

    Record the stopping reason

    If the run cannot safely write, the report explains whether the outcome is report-only, issue-only, or blocked by missing evidence.

Outputs

The final report names the repository revision, the issue or pull request outcome, the verification that ran, and any reason the task stopped at report-only or issue-only output. Output choice depends on the runbook and product mode. The report remains the durable record even when the visible result is a GitHub issue or pull request.

Vulnerability autofix output modes.
OutputWhen it fits
ReportThe run inspected the target and needs to record the outcome, limitation, or verification.
IssueThe evidence is real but the fix needs product, security, or architecture judgment.
Pull requestThe candidate is narrow, reviewable, and has a credible verification path.
FindingsDownload
Selected work

Missing authorization check on an account export route

Issue opened; pull request proposed after route guard verification

IssuePull request
The report keeps the repository, revision, selected work, and output links together, even when the run stops short of a code change.

Product surface

Guard exposes improvements from the audit or repository surface, not a separate code-writing workspace. The same action can appear in the control panel, recent activity, and report history after a completed run.

Autofix historyVulnerability autofix
TodayPull request createdLast runIssue opened for reviewer decisionEarlierReport-only; source evidence was stale
History keeps completed runs reviewable after the immediate notification is gone.

Review and rerun

A later security audit re-scores the new revision. The autofix report records the work; the audit proves whether the project moved closer to green.

This is the same health model as the audit pages: Guard improves a concrete surface, a person reviews the output, and a later audit or improvement rerun evaluates the new revision. The maintained state is the green zone, not an untouched backlog of findings.