Inspiration
A team fixes a security incident in one service. Weeks later, the same mistake appears in another repository. The original fix worked; the lesson never became a reusable check.
Antibody turns that lesson into tested prevention. It is built for developers and security engineers who need to move from “we fixed this instance” to “we have a reviewable check for this failure pattern.”
What it does
Start with a confirmed incident and Python examples showing the unsafe code and its correction. GitLab Duo proposes an incident-specific Semgrep detector, test fixtures and detection limits. A person reviews the proposal and imports it into a separate draft.
Antibody then runs real Semgrep checks: the unsafe examples must be detected and the fixed examples must be accepted. Additional examples help expose rules that are too broad or too narrow. The operator can scan uploaded source or a bounded GitLab repository snapshot, with findings linked to the exact commit.
Only after successful validation can a person approve the prevention pack. Antibody can export the rule, evidence and CI configuration, or open a GitLab merge request containing the detector, prevention job and root CI include. The team reviews that change through its existing GitLab workflow.
For example, an incident caused by disabling TLS certificate verification can become a tested detector for that Python pattern. The team can find another occurrence in supplied source and propose a CI check that rejects the unsafe pattern on future changes. This is a focused detector, not a claim to discover every TLS vulnerability.
Why this is different
The contribution is the connected workflow around a scanner: incident context → AI proposal → positive and negative tests → source findings → human approval → reviewable CI rollout. A raw AI suggestion is not treated as proof, and approval is not presented as installation. The original incident, reviewed revision and validation evidence remain connected.
How I built it
Antibody uses Next.js, React and TypeScript for the workspace, with Node.js services for incident history, validation, source scanning and GitLab integration. Semgrep scans supplied source without executing it. The hosted release uses PostgreSQL on Neon and a Docker service on Render; SQLite supports local development.
The GitLab Duo Agent Platform integration is real: a custom flow proposes the detector and fixtures; the application starts sessions through the Flows API and retrieves their status and output through GraphQL checkpoints. Agent privileges are read-only. A separate server-side GitLab credential creates a rollout merge request only after the operator's explicit approval.
This entry is Start Fresh: Assisted. Reviewing/importing a proposal, validating it, approving it and requesting rollout are explicit human steps. GitLab CI/CD then runs the resulting prevention check.
Proof that it works
The demonstrated chain includes a completed Duo session, six passing fixture checks on the reviewed detector, and one controlled source finding. These are bounded example results, not an accuracy benchmark.
The unsafe-revision CI job failed with a finding; the corrected-revision job passed. The public repository includes the rollout merge request, source, flow configuration, pipeline history and an evidence index.
Challenges and what I learned
The hardest boundary was between an AI proposal and a check worth trusting. Antibody preserves separate proposal, validation, approval and rollout states instead of collapsing them into a success message. It discloses scan limits and skipped files, preserves commit references, and makes interrupted runs retryable.
A failed CI job and an enforced merge policy are also different things. Antibody reports them separately: project-wide “Pipelines must succeed” enforcement is not enabled in the showcase project and is not claimed.
What I am proud of
A working path from incident examples to actual GitLab CI evidence, with human review and durable incident history. The release passed 27 backend, scanner and PostgreSQL checks, a production build, and container validation/restart checks. The workspace includes useful loading, failure and empty states, alongside a public explanation for first-time visitors.
What's next
The current scope is Python, one detector per pack and bounded scans. Next steps are broader evaluation datasets, carefully validated language support, stronger team access controls and better orchestration. These are future work, not current capabilities.
The goal is simple: make an incident's lesson executable, reviewable and repeatable.
Built With
- gitlab
- semgrep
- typescript
Log in or sign up for Devpost to join the conversation.