GitHygiene

Built by TetraFourge for Hacktoberfest Hack Day — Coimbatore 2026
INIT CLUB × iDEA CLUB × MLH

There’s a point in every project where you run a security scanner and get something like:

47 vulnerabilities found.

Great.

Now what?

Which ones actually affect your application?
Which ones are buried three dependencies deep?
Which ones are actually being used?
Which ones can you safely ignore?
And, most importantly, what should you fix first?

That was the problem we wanted to tackle.

The idea

Modern applications are built on top of hundreds of packages.

Your code depends on a package.
That package depends on another package.
That package depends on another package.

Before long, you're responsible for code you've never even seen.

When something breaks somewhere down that chain, traditional scanners are good at telling you that it's broken. They're much less useful at telling you whether your application actually reaches the vulnerable part.

That's where we started building GitHygiene.

So what does it do?

GitHygiene connects to your GitHub repositories and builds a map of your dependencies, vulnerabilities and the code that actually uses them.

It scans package.json, package-lock.json and requirements.txt, builds the dependency tree, checks packages against OSV.dev, and looks for outdated or deprecated dependencies.

But we didn't want to stop at:

"You have a vulnerable package."

We wanted to get closer to:

"You have a vulnerable package, and here's why your code does — or doesn't — reach the vulnerable part."

That's the interesting bit.

The AI doesn't get to guess

We split the AI workflow into separate stages.

First: Gemma 4 reads the advisory and identifies the vulnerable surface — functions, subpaths, trigger conditions and attack vectors.

Then: we put the model aside.

Our gateway searches the actual repository for imports, symbols and call sites related to that vulnerable surface.

Finally: another Gemma 4 model gets the advisory information together with the evidence found in the repository and makes the reachability assessment.

The result is one of four outcomes:

reachable
likely_reachable
not_evidenced
unused

That distinction is important.

A vulnerable package sitting somewhere in your dependency tree isn't necessarily the same thing as vulnerable code being executed by your application.

And we added a rule for the AI

If the AI can't prove where it got something from, we don't show it.

Every file cited by the model has to exist in the evidence collected during static analysis.

If the model returns a schema we can't validate, or cites something that wasn't in the evidence, the result is rejected.

No fabricated file paths.
No imaginary evidence.
No "trust me, bro" security analysis.

The system would rather say AI analysis unavailable than give you a confident answer that's wrong.

Then there's the dependency graph

One vulnerable package doesn't necessarily affect one repository.

You might have:

repo-a
   \
    package-x
   /
repo-b
   \
    package-y
       \
        package-x

So we used Neo4j to model the dependency relationships.

Now, when a package is affected by an advisory, we can trace the dependency graph and see the repositories that inherit that problem.

That's our blast radius view.

Instead of investigating repositories one by one, you can see where the same dependency problem travels across your projects.

Finding a vulnerability isn't the finish line

Once GitHygiene identifies a finding, it can also work out how to deal with it.

It generates remediation recommendations based on whether the dependency is direct or transitive, suggests direct upgrades or overrides, flags potential breaking changes, and can turn the finding into a draft GitHub issue with evidence from the scan.

So the workflow becomes:

Find it → understand it → decide → fix it.

Not:

Find 47 things → stare at dashboard → give up.

What we built

The final system is split into a few pieces:

React 19 + TypeScript
        |
        v
Node.js / Express API Gateway
        |
        +------ Supabase
        |
        +------ Neo4j
        |
        +------ OSV / npm / PyPI
        |
        v
FastAPI AI Service
        |
        v
Gemma 4

The gateway owns the application context and database access.

The AI service only receives the information it needs for a particular analysis and holds no database credentials.

That separation means the AI layer can be replaced, mocked or taken offline without taking the scanner itself down.

If the AI service is unavailable, you can still scan.

If Neo4j is unavailable, you can still scan.

The core functionality shouldn't collapse just because one intelligent-looking box decided to have a bad day.

What makes GitHygiene different?

Most dependency scanners answer:

"What is vulnerable?"

GitHygiene tries to answer three more useful questions:

"Does my code actually reach it?"

"Which of my repositories are affected?"

"What should I do about it?"

That's the direction we wanted to explore.

Not replacing security scanners.

Making their output more useful to the people who actually have to fix the issues.

What we learned

The hardest part wasn't getting an LLM to produce a security verdict.

It was making sure the verdict deserved to be trusted.

We learned that grounding matters more than clever prompting, static analysis is useful but isn't proof of safety, and not_evidenced should never quietly become safe.

We also spent a fair amount of time dealing with the realities of building during a hackathon: structured model responses, parsing edge cases, Python compatibility, testing individual AI stages and making sure all the pieces could fail independently without bringing the entire application down.

Built during Hacktoberfest Hack Day

Everything here was built as part of the Hacktoberfest Hack Day — Coimbatore 2026.

GitHub authentication and repository import.
Dependency extraction.
OSV vulnerability scanning.
Security scoring.
Static analysis.
Gemma-powered reachability analysis.
Neo4j dependency graphs.
Cross-repository blast radius.
Remediation planning.
GitHub issue generation.
And the dashboard tying it all together.

A lot of moving parts.

One slightly obsessive goal:

Make dependency security easier to understand.