Shipvigil

Shipvigil is a GitLab release gate. It blocks a dependency only if it is in CISA KEV or has an EPSS score of 0.1 or more, and a Duo flow commits the upgrade.

Inspiration

A dependency scanner tells a team that 25 packages have advisories. Most teams can't fix 25 things before a release, so they either ignore the list or turn the gate off. Severity doesn't help much here. A critical rating says how bad a bug is, not whether anyone is using it.

We wanted a gate that asks a better question: which of these are attackers likely to use now? Two public sources answer that every day. FIRST EPSS gives each CVE a chance of exploitation in the next 30 days, and the CISA KEV catalog lists bugs already exploited in the wild.

What it does

Shipvigil is a release gate on the GitLab Duo Agent Platform, under the MIT license. It has three parts: a CI template, a Duo flow that fixes what the gate blocks, and a small host that needs no deploy secret.

• Rank (secure stage): The shipvigil-deps job sends each lockfile to a public MCP server that checks OSV.dev, EPSS and KEV. It blocks only a malicious release, a CVE in KEV, or an EPSS score of 0.1 or more. Everything else is a warning. The job writes a GitLab code quality report, so the blocked package shows on its lockfile line in the merge request.
• Fix (create stage): A developer adds the custom flow "Shipvigil gate" as a reviewer. Duo runs the same CLI inside its sandbox, upgrades the blocked packages, regenerates the lockfile with --ignore-scripts, checks again, commits to the source branch and posts one verdict note. Its rules allow changes only to package.json and package-lock.json.
• Review (verify and package stages): Tests run, the site builds, and the merge request gets a review app. The review-live job then checks the app from outside. It answers, it is hidden from search engines as a review app should be, and its security headers are set.
• Deploy (release stage): A person starts the production deploy. The job proves who it is with its GitLab ID token, so no deploy key is stored anywhere. If the live check fails after the deploy, the host rolls back to the last good version.
• Release: A tag pipeline creates a GitLab release whose notes carry the gate verdict and link the evidence.
• Monitor: A daily scheduled pipeline checks production again, so an exposed file or a broken page shows up without a release.
• Govern: The rules live in shipvigil.policy.json in the repository, main is protected, and a person approves every production deploy.

On 2026-10-17 we gave it 25 popular npm packages at old versions, each with a published advisory. 3 of the 25 were likely to be exploited: ejs 3.1.6 (EPSS 32.8%), lodash 4.17.20 (21.3%) and moment 2.29.1 (13.9%). vm2 3.9.17 is rated critical, but its EPSS is 8.1% and it is not in KEV, so it gets a warning, not a block.

Autonomy level: Supervised. The flow fixes and commits on its own, and a person approves the outcome: the merge and the production deploy.

How we built it

• GitLab Duo Agent Platform: A custom flow (v1 schema, ambient environment) with two parts. A gate agent has six tools (get_merge_request, read_file, find_files, edit_file, run_command, create_commit), and a one-shot report step can only post a merge request note. The demo project uses the "assign reviewer" trigger. A project skill (skills/shipvigil-gate/SKILL.md) is the agent's playbook, and .gitlab/duo/agent-config.yml keeps the network sandbox on, with only GitLab, api.openkrill.app and registry.npmjs.org allowed.
• GitLab CI/CD: Seven stages (verify, secure, package, review, release, deploy, monitor), review environments with stop jobs, a manual production job, a tag release job and a pipeline schedule. The CI template can be included in any project.
• CLI: Node.js 22 with no runtime dependencies. deps ranks lockfiles, live checks a URL, and publish deploys a static build. It talks to two of our existing public MCP servers, cve and site-check, over Streamable HTTP. They need no key.
• Host: A Cloudflare Worker on the free plan. It checks the GitLab ID token against GitLab's JWKS, serves review apps under /_review/<slug>/ with noindex, keeps the previous production version for rollback, and redirects plain HTTP to HTTPS.
• Tests: 25 unit tests and an 8-check end-to-end script against the live services.

The Shipvigil code, flow, CI and host are new work for this hackathon. The two MCP servers existed before, and Shipvigil calls them like any public API.

Challenges we ran into

• The first flow session failed with "fetch failed". The Duo sandbox reaches allowed domains only through a local HTTP proxy, and Node's built-in fetch ignores HTTPS_PROXY. We wrote a small CONNECT tunnel with no dependencies and added an end-to-end check that runs the CLI behind a proxy. The next session fixed the merge request.
• The first scheduled pipeline failed when it was created, because the production job needs jobs that don't run on a schedule. A rule now keeps the deploy out of scheduled pipelines.
• Shipvigil's own live check flagged our host: workers.dev also answered plain HTTP. We added an HTTPS redirect, and the next deploy and the next daily check passed.

Accomplishments that we're proud of

The whole loop runs on real data in a public project. A merge request that pins ejs 3.1.6 fails the secure stage, the flow commits the fix, the new pipeline passes, the review app passes its live check, and production deploys with no stored secret.

The gate stays quiet. In our 25-package test it blocked 3 packages, not 25.

What we learned

A flow is easiest to trust when it can change very little. Ours takes its evidence only from Shipvigil's JSON, its report step can only post a note, and every fix it commits runs the full pipeline again.

We also learned that the sandbox, not the model, is usually where a first flow run fails.

What's next for Shipvigil

• Fix other ecosystems in the flow (it already ranks pnpm, yarn, Poetry, uv, Cargo and Go lockfiles).
• Turn on the "pipeline failed" trigger in the demo project too, so the flow starts without a reviewer. The docs already describe it.
• Make the policy thresholds per project, for teams that want a stricter or looser gate.

Built With

• cisa-kev
• cloudflare-workers
• epss
• gitlab-ci
• gitlab-duo-agent-platform
• mcp
• node.js
• osv