Woodpecker — Security Triage

Inspiration

Security incidents are in the news almost every week. Each time, my first question is: Is anything I own or keep running affected?

I run a small lingerie brand, and I am not an engineer. Scanners give me long lists of “high” and “critical” findings. I cannot judge them alone, and I do not want to become a human “Approve” button for every alert.

My first major task with an AI agent was reducing my Gmail inbox from about 280,000 emails to about 8,000. We agreed on what mattered and what to remove, then worked in batches of 100 so I could check and stop the process. That taught me what responsible automation means: deciding in advance what to let go of, what to delegate within clear limits, and what to keep under review.

Woodpecker brings that idea to security maintenance: an executive summary that helps a nontechnical owner understand the risk, make a decision, and follow the repair through.

What it does

Woodpecker is a custom GitLab Duo Agent Platform flow, built around an existing MIT-licensed application: my brand’s virtual fitting room.

1. Investigate the exact version. Read dependency-scan results, inspect the application code, and use a real test container to assess whether reported vulnerabilities are reachable.
2. Rehearse the repair. Work on a separate branch and run the actual CI checks.
3. Explain the decision. Produce a plain-language card covering severity, evidence of damage, urgency, estimated effort, additional cost, affected scope, and what remains unknown. A dependency scan alone cannot establish whether damage has occurred.
4. Apply bounded autonomy. Serious findings (A), or missing evidence needed for a decision, stop for human review. Lower-risk, well-understood findings (B/C) are designed for automatic handling only within pre-authorised limits, with complete evidence and passing checks. This automatic route has not yet passed live end-to-end acceptance.
5. Keep actions separate. Opening a repair merge request is not permission to merge or deploy. Each requires a separate decision.

How we built it

• GitLab Duo Agent Platform runs the multi-step workflow: read the issue and code, rehearse the repair, create the decision card, request approval when required, and open the repair MR.
• Deterministic scripts from the trusted main branch enforce the boundaries: allowed files, same-major version changes, scan results, checks for secrets and personal data in public reports, and approval records bound to a full commit SHA and a specific action.
• CI/CD covers the build, dependency scanning, npm audit, container testing, release preflight checks, and the control-room page.
• AI judgment remains part of risk classification and reachability analysis. Mechanical checks constrain actions; they do not prove every judgment correct. Missing decision-critical evidence must stop the flow.

What we have actually demonstrated

The following acceptance runs used an isolated private demo project with synthetic data.

Human approval works

Decision card #5, session 9994900, was classified as A and stopped for approval. The approval record was bound to commit 294b9bba132e84f21dd5bd34762d940ea164d3b9 and the action “open a repair MR.”

The gate returned APPROVAL: OK, and draft MR !2 was opened. Pipeline 2983688908 passed all seven jobs. Nothing was merged or deployed.

Clicking Approve is not enough without a matching record

On card #4, session 9994613, Woodpecker stopped rather than releasing the repair without the required matching approval record.

A separate, generic Duo Developer session on the same card opened draft MR !1. That MR was closed without merging. We include this exception because it happened; the Woodpecker gate should not be mistaken for a platform-wide restriction on every agent.

Passing CI does not override missing evidence

On card #7, session 9995743, CI passed, but the gate returned HUMAN because the evidence was incomplete. No MR was opened, and the session was closed with Reject.

Not yet demonstrated

Automatic B/C handling has not passed a live end-to-end run. The route is implemented and tested in code, but its live acceptance remains pending.

Challenges

A clean scanner result is not the same as a verified repair.

During the demo, a version override reduced the scanner’s reported findings to zero, while a Vercel package still contained its own embedded copy of an older zod version that the override did not replace.

In the contest build, we addressed this by removing the unused Vercel Gateway/OIDC fallback dependency that carried the embedded copy, rather than ignoring the alert or weakening the release gate.

At the latest recorded validation on main, both npm audit and GitLab Dependency Scanning reported zero findings. A container check also verified that, in the tested no-API-key configuration, no paid model or try-on request was sent. These are scoped verification results, not a claim that the application has no remaining security risks.

What we learned

Trust with an agent grows through clear limits, inspectable evidence, and gradually delegated responsibility.

For a nontechnical owner, the useful output is not another wall of alerts. It is a clear explanation of what may be affected, what is known, what remains uncertain, and exactly which action is being requested.

Automation should reduce the burden of decision-making without hiding uncertainty or turning approval into a reflex.

What’s next

• Pass a live end-to-end acceptance run for the automatic B/C route.
• Complete review and publish flow v1.2.4, with stricter scan-source and runtime-evidence requirements.
• Add bilingual decision cards generated by Woodpecker itself.

How we worked: people and agents

I set the rules and made the decisions. Claude Opus wrote the code. ** Codex Sol6.1** independently reviewed changes, reproduced edge cases, and identified problems that were fixed and checked again. Astra handles deployment and billing work.

Agent names used on a shared account are audit labels, not separate verified identities. We distinguish independent review activity from the account identity recorded by the platform.

Built With

• claude
• dependency-scanning
• docker
• gitlab
• gitlab-ci
• gitlab-duo-agent-platform
• gitlab-pages
• google-cloud-run
• next.js
• node.js
• typescript