VulnSlayer is an autonomous AI agent that takes a Jira vulnerability ticket from scan to merged-ready PR — with zero developer involvement in the fix path.
Every enterprise running containerised software pays a hidden tax on developer productivity. Security scanners — Mend SCA, Twist Lock, Prisma Cloud — scan continuously. They raise one Jira ticket per vulnerable package, per component. In a platform with three services and 50+ Java dependencies, a single CVE can generate 10–15 tickets in one scan run.
It is not hard work. It is not creative work. It is assembly-line work — identical steps, every time, for every ticket. For hybrid-ipaas, this was consuming one developer's full attention every quarter.
VulnSlayer is a purpose-built custom mode inside IBM Bob — not a generic chatbot. It has its own role, tool access, safety guardrails, and a deterministic 6-phase workflow.
⭐ github-extras MCP was built and open-sourced to fill a gap in the official GitHub MCP — PR reviewer/assignee APIs were missing.
Available on npm: vidhya03/mcp-github-extras
Every use case is grounded in real production tickets from March–July 2026.
The temporal/admin-tools image generated 38 Jira tickets (SCI-17720 → SCI-17757) from a single Twistlock scan run. VulnSlayer's Opensource Path handled the entire incident:
| Cluster | Root Cause | Packages / CVEs | Tickets | GitHub Issue |
|---|---|---|---|---|
| A | tctl binary compiled with Go 1.15.11 (EOL Aug 2021) |
25 stdlib packages — net/http, crypto/tls, html/template, crypto/x509 + 21 more |
25 | #1107 ↗ |
| B | Stale Go third-party modules in go.mod |
jwt-go, grpc, protobuf, yaml.v3, logrus, go-jose, thrift |
7 | #1107 ↗ |
| C | Python 2.7.18 runtime (EOL Jan 2020) bundled in image | pip, setuptools, wheel, thrift, click — 40+ CVEs, no patches possible |
6 | #1108 ↗ |
"The fix needs to happen upstream. We've reported it clearly and professionally. We've documented why each ticket is closed. We're done — and the upstream project has everything it needs to act."
Dependabot and Renovate have no answer for this scenario — they only handle repositories you control. For enterprise platforms that pull third-party images, VulnSlayer is the only automated path.
This is not theoretical. This is the actual change in how a security-focused developer spends their sprint.
bob-autofix (10 min). PRs raised by afternoon.The human is still essential. They review every PR. They make the merge decision. They own the security posture. They just work one level up.
VulnSlayer v2.0 doesn't just patch the CVE. It explains why the fix was chosen, and surfaces the alternative the team should consider for long-term health.
PR: "Bump jackson-databind 2.21.2 → 2.21.5"
Reviewer thinks: Does this conflict with Spring Boot? Should I upgrade SB instead? I don't know, I'll just merge it.
<jackson-bom.version>2.21.5</jackson-bom.version> property override.3.5.14 → 3.5.16. SB 3.5.16 ships jackson 2.21.5 natively.| Release | Period | Tickets | PRs | 🔴 Critical | Dev hrs saved |
|---|---|---|---|---|---|
| 11.3.4.0 | Mar 14–24 | 15 | 12 | 5 | ~30 hrs |
| 11.3.5.0 | Mar 26–Apr 24 | 24 | 18 | 4 | ~48 hrs |
| 11.3.6.0 | May 4–Jun 1 | 54 | 20 | 9 | ~108 hrs |
| 11.3.7.0 | May 26–Jun 18 | 38 | 12 | 0 ✅ | ~76 hrs |
| 11.3.8.0 | Jul 2026 | 28+ | 6 | 0 ✅ | ~56 hrs |
| Total | Mar–Jul 2026 | 159+ | 68+ | 0 open | ~318+ hrs |
11.3.7.0 was the first ever zero-Critical release in the team's history. 11.3.8.0 maintained it. Every ticket maps to a PR, a CVE, and a release — fully auditable.
Dependabot and Renovate manage dependencies. VulnSlayer manages security incidents. These are different problems requiring different solutions.
| Capability | VulnSlayer v2.0 | Dependabot | Renovate |
|---|---|---|---|
| Trigger | Jira ticket from security scan | Scheduled poll | Scheduled poll |
| CVE source | NVD + GHSA + description parsing | GitHub Advisory only | Multiple (basic) |
| Fix target | Minimum safe version | Latest version | Configurable |
| Framework detection | ✅ Spring Boot, Jakarta EE, Quarkus, Micronaut | ❌ None | ⚠️ Limited |
| Dual recommendations | ✅ Option A + B with confidence scores | ❌ Single path | ❌ Single path |
| Jira integration | ✅ Bidirectional — reads + writes | ❌ None | ⚠️ Configurable |
| STIG-hardened images | ✅ Native — reads internal STIG catalog | ❌ No | ❌ No |
| Multi-component batching | ✅ Groups by repo, optimises PRs | ❌ One PR per package | ⚠️ Can group |
| Upstream/OSS path | ✅ Files upstream issues, closes tickets | ❌ Can't handle | ❌ Can't handle |
| Wave cleanup PR | ✅ Auto-removes superseded overrides | ❌ No | ❌ No |
| FedRAMP / STIG compliance | ✅ Designed for regulated environments | ❌ No | ❌ No |
| Failure handling | ✅ Comments on Jira, marks manual-review | ❌ Silently skips | ⚠️ Email alerts |
| Open source contribution | ✅ mcp-github-extras on npm | GitHub-proprietary | ✅ Open source |
Normally that meant a developer starting Monday with a full week of tedious patch work. Instead, someone added the bob-autofix label to each ticket.
By Monday morning, 17 PRs were waiting for review. Each one had the CVE research done, the fix applied, the reviewers assigned, and the Jira ticket updated.
The developer spent 90 minutes reviewing the PRs. All 17 merged by noon.
The afternoon was free.