Security Vulnerabilities Patcher

Security Vulnerabilities Patcher

Turn GitHub security alerts into batched, Dependabot-style pull requests for axelixlabs/axelix.

The key idea is batch by Axelix dependency surface, not by individual CVE. The desired shape is:

• one PR for master/front-end dependency updates,
• one PR for master/build.gradle.kts and directly coupled master backend build files,
• one PR for starter Gradle build files,
• and separate PRs for other clearly distinct dependency surfaces when needed.

The goal is still patch-release safety: each PR should stay locally understandable and safe to review, but it may fix several vulnerabilities at once if they belong to the same surface.

What this skill is for

Use this workflow for axelixlabs/axelix when the repository has security findings from:

• CodeQL code scanning alerts.
• Trivy SARIF alerts uploaded into GitHub code scanning.
• Dependabot alerts or other GitHub dependency alerts surfaced through the GitHub API.
• A CI job such as security-check that is expected to fail on open HIGH/CRITICAL findings, and the user wants AI-authored remediation PRs.

This skill is intentionally Axelix-specific. It assumes the target repository is axelixlabs/axelix and that its security workflow uploads Trivy SARIF into GitHub code scanning, so GitHub API queries can see both CodeQL and Trivy findings.

Core operating rules

1. Batch by dependency surface, not by CVE. Group vulnerabilities that are fixed by the same manifest, lockfile, Gradle build, or tightly coupled module area.

2. Do not batch across unrelated Axelix surfaces. master/front-end does not belong in the same PR as starter Gradle files. master/build.gradle.kts does not belong in the same PR as Docker base image remediation unless the same build surface truly requires it.

3. Prefer patch-safe remediations. Favor:

   • same-major dependency upgrades,
   • lockfile refreshes that follow from those upgrades,
   • minimal container base image bumps,
   • tiny local hardening patches that do not alter public behavior.

4. Do not break public APIs or contracts. The fix must be safe for a patch release. Avoid changes to public DTOs, REST contracts, starter configuration contracts, public Java APIs, or user-facing workflows unless the user explicitly accepts that risk.

5. Do not hide the problem. Do not "fix" alerts by suppressing them, loosening the scanner, or adding ignores unless the user explicitly asks for that path and understands the trade-off.

6. Do not invent vulnerability identifiers. Prefer real CVE identifiers when they exist. If some findings are GHSA-only, say so plainly instead of fabricating CVEs.

Preferred Axelix batch boundaries

Use these batch boundaries by default unless the live alert data strongly suggests a better split:

1. master/front-end Group vulnerabilities remediated through master/front-end/package.json, master/front-end/package-lock.json, or equivalent front-end dependency files.

2. Master backend Gradle Group vulnerabilities remediated through master/build.gradle.kts, root Gradle version catalogs or shared Gradle declarations that primarily affect master backend dependencies.

3. Starters Gradle Group vulnerabilities remediated through sbs/build.gradle.kts, sbs/axelix-spring-boot-2/build.gradle.kts, sbs/axelix-spring-boot-3/build.gradle.kts, or directly coupled starter build files.

4. Shared/common Gradle If vulnerabilities live primarily in common/ modules or shared build logic, use a separate PR when that keeps the blast radius smaller and clearer.

5. Docker/image surface If Trivy image findings are fixed via Docker base image changes rather than application manifests, keep that in its own PR unless the user explicitly wants it combined.

When in doubt, ask: "Would a maintainer naturally review these updates together like a single Dependabot PR?" If not, split them.

Supported alert sources

1. Code scanning alerts

Use GitHub's code scanning alerts API for:

• CodeQL findings.
• Trivy findings that were uploaded as SARIF.

Recommended command:

export GH_TOKEN="$GITHUB_PAT"
gh api "repos/OWNER/REPO/code-scanning/alerts?state=open&per_page=100" --paginate

Typical fields worth extracting:

• number
• html_url
• tool.name
• most_recent_instance.category
• rule.id
• rule.description
• rule.security_severity_level
• most_recent_instance.location.path
• most_recent_instance.ref

For this repository, expect Trivy categories such as trivy-artifacts and trivy-image.

2. Dependabot alerts

Use GitHub's Dependabot alerts API for dependency vulnerabilities that include package and patched-version information.

Recommended command:

export GH_TOKEN="$GITHUB_PAT"
gh api "repos/OWNER/REPO/dependabot/alerts?state=open&per_page=100" --paginate

Typical fields worth extracting:

• number
• html_url
• dependency.package.name
• dependency.manifest_path
• security_advisory.ghsa_id
• advisory identifiers or aliases that include a CVE when available
• security_advisory.cwes
• security_advisory.severity
• security_vulnerability.first_patched_version.identifier
• security_vulnerability.package.ecosystem

GitHub alert payloads evolve. If an exact key is different in the live API response, use the equivalent returned field and do not invent missing data.

3. Out-of-scope by default

If a workflow failed but the finding is visible only in raw logs or artifacts and not in GitHub alerts, say that you are outside the API-driven path of this skill. You can still help manually, but do not pretend it came from the GitHub alerts API.

Step 1 - Resolve repository and permissions

This skill must use the GITHUB_PAT environment variable for GitHub API access.

Before any gh api, gh pr, gh repo view, or other GitHub network call:

1. Check whether GITHUB_PAT is present in the environment.
2. If GITHUB_PAT is missing or empty, stop immediately.
3. Report back to the user that GitHub access cannot proceed because GITHUB_PAT is not set.
4. Do not try the GitHub API unauthenticated. Do not probe first "just to see if it works."

Preferred pattern:

export GH_TOKEN="$GITHUB_PAT"

Resolve OWNER/REPO from git first:

git remote get-url origin

Expect the default answer to be axelixlabs/axelix. If the current workspace points somewhere else, stop and confirm with the user before proceeding, because this skill is written specifically for the Axelix monorepo and its release-safety constraints.

Then confirm GitHub CLI authentication using GITHUB_PAT:

export GH_TOKEN="$GITHUB_PAT"
gh auth status

You need enough access to:

• read security alerts,
• read repository contents,
• push a branch,
• create a PR,
• edit PR labels.

If authentication is missing or insufficient, stop and explain what permission is needed rather than guessing.

Also resolve the default branch:

export GH_TOKEN="$GITHUB_PAT"
gh repo view OWNER/REPO --json defaultBranchRef

Step 2 - Fetch and summarize the open security backlog

Fetch open alerts from every supported source that applies.

Before choosing what to fix, summarize counts by:

• source,
• severity,
• tool,
• whether a CVE is present.

The summary should look like:

• critical: N
• high: N
• medium: N
• low: N

And then a short source breakdown such as:

• code-scanning / CodeQL
• code-scanning / Trivy
• dependabot

Also produce a surface grouping summary. For each alert, map it to the most likely Axelix batch boundary:

• master/front-end
• master backend gradle
• starters gradle
• common/shared gradle
• docker/image
• other / needs review

The point of the summary is to show both the severity queue and the likely Dependabot-style PR buckets before you start fixing anything.