Skip to content

ci: add automated vulnerability remediation workflow#182

Open
ulziibay-kernel wants to merge 2 commits intomainfrom
security/vuln-remediation-workflow
Open

ci: add automated vulnerability remediation workflow#182
ulziibay-kernel wants to merge 2 commits intomainfrom
security/vuln-remediation-workflow

Conversation

@ulziibay-kernel
Copy link
Copy Markdown

@ulziibay-kernel ulziibay-kernel commented Apr 2, 2026

Summary

Adds a weekly Socket.dev vulnerability remediation workflow. Runs a Socket scan with reachability analysis, then uses the Cursor agent to triage alerts and create fix PRs for actionable CVEs.

Adapted for this repo: Go-only, uses root go.mod, Makefile build/test targets.

Test plan

  • Tested end-to-end on kernel-images (Socket scan + agent remediation completed successfully)
  • Merge to main so weekly schedule and workflow_dispatch are active

env:
GH_TOKEN: ${{ steps.app-token.outputs.token }}
run: |
gh api "/repos/${{ github.repository }}/dependabot/alerts?state=open&per_page=100" > dependabot-alerts.json 2>/dev/null || echo "[]" > dependabot-alerts.json
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Silent error suppression hides API misconfiguration permanently

Medium Severity

The 2>/dev/null on the gh api call silently discards all stderr output, including authentication and permission errors. If the GitHub App token lacks the required Dependabot alerts: read permission, the API returns a 403, stderr is suppressed, and || echo "[]" creates an empty alerts file. The agent then reports "No open vulnerability alerts" and exits successfully. Since this is a weekly scheduled workflow, the team believes vulnerability remediation is running while it silently does nothing — potentially for weeks or months. Removing 2>/dev/null while keeping the || echo "[]" fallback would preserve resilience against transient failures while making permanent misconfigurations visible in workflow logs.

Fix in Cursor Fix in Web

Copy link
Copy Markdown

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

Fix All in Cursor

Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

env:
SOCKET_SECURITY_API_KEY: ${{ secrets.SOCKET_API_TOKEN }}
run: |
socket scan create --repo="${{ github.event.repository.name }}" --branch=main --default-branch --report --json > socket-report.json 2>/dev/null || echo '{"healthy":true,"alerts":{}}' > socket-report.json
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scan failure silently produces false healthy report

High Severity

When socket scan create fails (bad credentials, network error, service outage, etc.), the || fallback writes {"healthy":true,"alerts":{}} to socket-report.json, making the workflow believe no vulnerabilities exist. Combined with 2>/dev/null suppressing all error output, scan failures are silently treated as a clean bill of health. This defeats the entire purpose of the vulnerability remediation workflow — real vulnerabilities go undetected and unremediated with no indication anything went wrong.

Fix in Cursor Fix in Web

@ulziibay-kernel ulziibay-kernel requested a review from rgarcia April 3, 2026 19:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant