DiffFence

DiffFence is a local-first pre-push safety gate that runs one-time baseline scan, then uses diff-aware incremental checks to catch only newly introduced security and production risks in every change.

Comment

Inspiration

I built DiffFence because I kept seeing the same problem in developer workflows: security checks are important, but most tools are either too noisy, too slow, or too disconnected from how people actually code. When a tool reports everything in the whole repo every time, it becomes hard to tell what really matters in the code I just changed. I wanted to build something simpler and more practical, a tool that fits naturally into Git-based development and helps catch risky changes early without adding too much friction.

What it does

DiffFence is a local-first CLI tool that scans code changes for security and production risks. Instead of always scanning the entire repository, it focuses on changed files, staged files, or paths I provide. On the first run, it creates a baseline of existing findings. After that, it compares new scans against that baseline and mainly highlights newly introduced issues. It can detect things like hardcoded secrets, unsafe eval usage, weak configuration choices, and risky new dependencies, while also generating readable reports for review.

How we built it

I built DiffFence as a Python command-line application with a modular structure so each part had a clear responsibility. The CLI was built using argparse, the terminal output was improved with Rich, and the interactive shell was supported with prompt-toolkit. I used Git commands to detect what changed in the repository, then passed those files into a scanning engine that combines regex rules, Python AST checks, dependency analysis, and baseline comparison. I also added optional Ollama support for local AI-assisted review and optional OSV lookups for dependency advisories, while keeping the main tool usable without either one.

Challenges we ran into

The biggest challenge was reducing noise. It was not very hard to make a scanner that found issues, but it was much harder to make one that reported useful issues without overwhelming the user. That is what led me to the baseline-first approach. Another challenge was balancing simplicity and features. I wanted DiffFence to support reports, Git hooks, dependency checks, and optional AI review, but I did not want it to feel bloated or difficult to use. A final challenge was making sure optional integrations stayed optional, especially AI, so the project could remain local-first and still work well even without extra services running.

Accomplishments that we're proud of

I’m proud that DiffFence became more than a script and turned into a usable developer tool. The baseline-first workflow, Git-aware scanning, and local-first design made it feel practical and real.

What we learned

I learned how to structure a proper CLI project, work with Git programmatically, manage local state, and think more deeply about developer experience. The biggest lesson was that a good tool is not just about finding problems, it is about showing the right problems at the right time.

What's next for DiffFence

Next, I want to expand rule coverage, support more languages and frameworks, add better tests, and improve configuration and CI integration. The goal is to keep DiffFence lightweight while making it more useful in real developer workflows.

Built With

  • argparse
  • git
  • ollama
  • osv.dev
  • prompt-toolkit
  • python
  • python-ast
  • rich
Share this project:

Updates