Provenance Guard

• 

  Attestation Bootstrap triggered from a GitLab issue and posting a structured incident note

• 

  Flow-generated remediation merge request for CI supply chain hardening

• 

  Project overview for Provenance Guard and Attestation Bootstrap

Inspiration

In March 2026, the Trivy supply chain incident showed how fragile CI trust can be when teams rely on mutable references and unverified installer paths. A pipeline can look normal while silently pulling attacker-controlled code from upstream. That incident was the inspiration for this project.

The idea behind Provenance Guard is simple: most security tools detect risk, but they do not move the work forward. We wanted to build something on GitLab Duo that does more than explain a problem. It should inspect a repository, identify CI trust gaps, open a reviewable remediation merge request, and leave a traceable incident note directly inside GitLab.

What it does

Provenance Guard has two parts:

• Provenance Guard: a custom GitLab Duo agent for investigation and follow-up explanation
• Attestation Bootstrap: a custom ambient GitLab Duo flow that reacts to an issue or merge request mention

When triggered, the flow inspects CI/CD-relevant files such as .gitlab-ci.yml and .github/workflows/*, looks for Trivy-style risk patterns, and then takes the smallest safe action it can. The main patterns it targets are:

• mutable GitHub Action references such as @master or major tags
• remote shell installer patterns like curl | sh and wget | sh
• floating image references like latest
• missing attestation-minded build and scan steps

If a safe patch is possible, the flow creates a branch, opens a merge request, and posts a structured note back on the original thread. If not, it leaves findings and explicit manual follow-up instead of forcing a risky change.

How we built it

We built the project on the GitLab Duo Agent Platform using:

• a public custom agent in agents/agent.yml
• a public ambient custom flow in flows/flow.yml
• GitLab Duo built-in tools for repository inspection, CI linting, commit creation, MR creation, and issue notes

The project was intentionally grounded in a realistic demo target. We added weak CI patterns inspired by the Trivy incident, including mutable GitHub Action refs and unsafe remote installer usage, then triggered the flow from a GitLab issue mention. The flow inspected the repo, classified the risk, and opened a merge request with a remediation attempt.

We also wanted the repository to demonstrate a real attestation-oriented path rather than only talking about one. So the current GitLab CI demo now wraps the build, scan, and release stages through a local cilock-action bootstrap. That lets the project combine GitLab Duo-driven detection and remediation with a concrete cilock-backed pipeline pattern.

We also documented the whole lifecycle in the repository:

• the weak before-state
• the flow-generated merge request
• the incident note
• the human-reviewed hardening follow-up
• architecture, setup, severity rubric, and demo evidence

Challenges we ran into

The biggest challenge was balancing automation with credibility. It is easy to make an AI system that always proposes a patch, but much harder to make one that behaves responsibly in CI. We found that even when the flow identifies the right issues, a human still needs to review whether the generated patch is truly production-safe.

That turned into an important part of the project story. We kept the flow-generated merge request as evidence, and treated the final repository state as a human-reviewed follow-up rather than pretending the AI output was perfect. That made the project more honest and more useful.

Another challenge was working within the GitLab Duo hackathon environment itself. The strongest path was to keep the project GitLab-native: issue mentions, flow execution, MR creation, and follow-up chat all inside GitLab.

What we learned

We learned that GitLab Duo custom flows are powerful when they are scoped to a narrow, concrete operational problem. Instead of trying to build a general-purpose security chatbot, we focused on one specific SDLC trust failure and one useful workflow: detect, patch, open an MR, and leave a note.

We also learned that the best AI security experience is not “AI replaces the engineer.” It is “AI creates a clear first remediation draft, and the human reviewer stays in control.”

We also learned that it is important to be explicit about limits. The current cilock integration is an attestation bootstrap, not full end-to-end policy verification or complete SLSA compliance. That honesty made the project stronger and easier to explain.

Why this matters

Provenance Guard is useful because it turns CI supply chain findings into GitLab-native action. It shortens the gap between discovering a risky pattern and starting a real remediation workflow. That is the difference between a tool that only reports problems and one that helps a team move forward.

Built With

• cilock
• claude
• devsecops
• duo
• gitlab
• in-toto
• supply-chain-security
• witness