Kestrel

Inspiration

When was the last time you used AI to develop and push code?

Probably not long ago.

Because technology has made software development faster than ever before. With tools like AI assistants, a single developer can build an entire application overnight.

But speed does not come without risk. When we move faster than we understand, small mistakes can become expensive ones.

Professional engineering teams solve this problem with security engineers and expensive tools scanning every repository. But amateur developers - students, indie builders, hackathon participants - don’t have a security team watching over their code. They often don’t even know what vulnerabilities to look for in the first place.

And as AI becomes a larger part of the development process, this problem is only getting worse. Developers can now generate large amounts of code instantly - but that code may contain secrets, unsafe dependencies, or security vulnerabilities hidden beneath the surface.

The result is a growing gap between the speed at which we build software and the ability to secure it.

Existing security tools attempt to solve this problem, but many are built for large companies. They require complex configuration, security expertise, and often act as black boxes that simply report errors without explaining them.

What developers really need is something different.

What it does

Kestrel is a personal security sidekick for developers. With a single click, it runs powerful open-source security scanners like Gitleaks, Trivy, and Semgrep across your repository, detecting exposed secrets, vulnerable dependencies, and unsafe code patterns.

But Kestrel doesn’t stop at detection.

Instead of returning cryptic warnings, it provides clear explanations and educational feedback that help developers understand what went wrong and how to fix it. The goal isn’t just to patch vulnerabilities - it’s to help developers learn how to avoid them in the future.

Because security tools shouldn’t just fix problems.

They should teach developers how to build safer code in the first place.

How we built it

Kestrel combines open-source security tooling with an AI-powered explanation layer to make repository security accessible and explainable to any developer.

The system works in three stages.

First, developers connect their GitHub repository through OAuth authentication. This allows Kestrel to securely access the repository without exposing credentials. Second, Kestrel runs repository scanners for different types of vulnerabilities:

Gitleaks detects leaked secrets and API keys

Trivy scans dependencies for known vulnerabilities

And then finally, the results are processed by an AI layer that converts raw security findings into clear explanations, actionable fixes, and educational guidance.

The application itself is built with:

ReactJS frontend and Typescript
GitHub OAuth for repository access
Supabase Database
Open Source Security tools such as Trivy and Gitleaks
Gemini AI for translating the complex findings into developer-friendly insights

Challenges we ran into

One of the biggest challenges was handling GitHub OAuth securely across the entire stack.

Access tokens are a central point of the system interacting with basically everything else, including the frontend, backend, database, and deployment environment. Ensuring tokens were stored securely, passed safely between services, and never exposed to the client required careful design and lots of debugging and pain.

Another challenge was orchestrating multiple security scanners in a way that produced consistent results. Each tool has its own output format and scanning approach, so we had to build a normalization layer that converts all results into a unified structure.

Finally, we had to solve the problem of making security findings understandable. Raw scanner output is often designed for security engineers, not everyday developers. Turning these results into clear, educational explanations required careful prompt design and formatting.

What we learned

Throuhgout the production Kestrel, the team learned about the many difficulties of real world tool building. The challenges of time constraint, working in a team and the many different factors to account for in real world usage that may not come up for something like a university assignment. This was an invaluable experience for the team on their journey to real software engineering.

What's next for Kestrel

In the future, we want to expand the platform to include:

Pull request security reviews that analyze code before it is merged
Expand the tooling to many other open soruce security tools all running concurrently
Having the choice of specific types of vulnerabilities and running certain kinds of tools

The vision is to turn Kestrel into a personal security mentor for developers, helping them build safer software without slowing down innovation.