ReleaseFence

• 

Inspiration

An npm package doesn't become safe just because nobody changed its version today.

Supply-chain attacks can happen between releases. A dependency that was clean yesterday might be compromised tomorrow, while a developer is fixing a typo, updating documentation, or working on an entirely unrelated feature.

Most dependency checks focus on known vulnerabilities or changes to dependency manifests. I wanted to build something that treats the entire current dependency inventory as a security concern on every commit, including the very first commit in a repository.

That became ReleaseFence, a security gate built around one principle: proof before release.

What it does

ReleaseFence is designed to inspect every commit, regardless of what changed.

The security analysis has four parts:

1. Current dependencies: Inventory the exact npm package versions currently resolved in the project, including dependencies that haven't changed.
2. External threat intelligence: Check packages against OpenSourceMalware (OSM) for known malicious activity.
3. Internal intelligence: Compare packages against ReleaseFence's own threat database.
4. Source inspection: Examine newly added or modified JavaScript and TypeScript for suspicious behavior.

Detection is only the beginning.

The larger goal is an adversarial workflow powered by GitLab Duo:

• Red investigates suspicious findings and attempts to reproduce the risk safely.
• Blue proposes a bounded fix, limited to authorized dependency changes.
• Red retests the exact new commit rather than trusting Blue's explanation.
• The release gate independently evaluates the evidence. Unresolved or inconclusive cases remain blocked for human review.

Neither AI agent gets to approve its own work.

What works in the prototype

The current GitLab CI scanner automatically runs on pushes, inventories resolved npm dependencies, and performs heuristic checks on added JavaScript and TypeScript. It works even when dependencies haven't changed.

In a real GitLab test, MR !21 automatically triggered the installed GitLab Duo Flow. Blue identified a safer version of a synthetic npm dependency, the security precheck rejected the affected version, and the release-hold job blocked the pipeline.

A separate GitLab Duo repair modified only the dependency manifest and lockfile. An independent protected verifier then retested that specific commit.

These are real GitLab executions, not simulated interface results.

The prototype is still incomplete. The current CI scan does not make live OSM queries, the internal database is empty, and source inspection uses heuristics rather than reliable malicious-intent detection. Automatic Blue repair, repeated Red/Blue retesting, and final positive release authorization are not yet connected into one autonomous workflow.

How I built it

I built ReleaseFence around GitLab's native development workflow rather than creating a separate security dashboard that developers would have to remember to visit.

The implementation uses Node.js and JavaScript for dependency analysis, policy evaluation, security checks, and verification utilities. GitLab CI/CD runs the commit scanner and enforces the demonstrated release hold.

GitLab Duo provides the Red and Blue investigation agents. Custom Flow definitions describe their responsibilities, while restricted repair logic is intended to prevent an agent from changing unrelated application code.

I also built a separately controlled verification boundary, SHA-pinned evidence checks, isolated synthetic npm attack fixtures, and YARA-X checks. This keeps security testing reproducible without executing real malware.

The public project website is hosted on GitLab Pages. Engineering code, demonstration repositories, and release-verification components are deliberately separated.

Challenges I faced

The hardest problem wasn't detecting a suspicious dependency. It was determining when an AI-generated security decision could actually be trusted.

An agent saying that it fixed something isn't evidence that the vulnerability is gone. A passing job isn't sufficient if the same workflow can alter its own tests, policy, or approval criteria.

I had to work through GitLab Duo authorization, restricted tool permissions, commit attribution, cross-project verification, and exact-commit evidence binding.

Another challenge was integrating the workflow without requiring personal access tokens or elevated permissions from every developer.

GitLab AI Catalog permissions also prevented activation of the updated automatic repair Flow in the hackathon environment. Instead of bypassing the security boundary, I kept the unverified release-approval path disabled.

Accomplishments I'm proud of

• Implemented a commit-triggered npm inventory scanner that does not depend on package changes.
• Demonstrated a real GitLab Duo Flow starting automatically from a newly created merge request.
• Demonstrated rejection of a synthetic compromised dependency and a failed-closed release hold.
• Produced a real, bounded GitLab Duo dependency repair and independently retested its resulting commit in a separate run.
• Built a public, reproducible demonstration with inert test fixtures, source code, test results, and GitLab evidence.

What I learned

The biggest lesson was that AI can investigate and propose a fix, but it should not be the authority that declares its own fix safe.

The critical part of an agentic security system is the trust boundary between detection, remediation, verification, and release authorization.

I also learned how much of the engineering challenge lies in integration: giving agents enough authority to perform useful work without giving them enough authority to bypass the controls they're supposed to respect.

What's next

The next step is connecting the remaining pieces into one fully autonomous, independently verified workflow.

That includes live OSM intelligence, a populated internal threat database, stronger JS/TS analysis, authenticated Blue-to-writer execution, automatic Red retesting, bounded repair retries, and enforceable human-review decisions.

The long-term goal is simple: developers keep committing code as usual, while ReleaseFence continuously evaluates whether the current project is safe to release.

Code can change automatically. Trust still needs evidence.

Built With

• docker
• gitlab
• gitlab-api
• gitlab-ci/cd
• gitlab-duo
• gitlab-pages
• javascript
• node.js
• npm
• opensourcemalware
• sha-256
• yaml
• yara-x