ReachGuard
Inspiration
Modern software applications depend heavily on open-source packages, but developers often do not know when a dependency becomes a security risk. A single vulnerable package buried deep inside a dependency tree can expose an entire application.
We were inspired by the gap between vulnerability detection and practical risk understanding. Existing scanners can identify CVEs, but developers still have to determine whether a vulnerable dependency is actually reachable, how serious the risk is in their application, and what they should do about it.
This led us to build ReachGuard - an AI-powered dependency security platform designed to go beyond simply reporting vulnerabilities. Our goal was to help developers understand which vulnerabilities actually matter, why they matter, and how they can be remediated.
What ReachGuard Does
ReachGuard analyzes project dependencies and combines vulnerability intelligence with application-level reachability analysis and AI-powered security reasoning.
The platform analyzes dependency information and enriches findings using sources such as:
- NVD vulnerability data
- CVE and CVSS information
- EPSS exploit probability
- CISA Known Exploited Vulnerabilities (KEV)
- Dependency reachability information
- AI-powered risk reasoning
- AI-generated remediation recommendations
Instead of treating every vulnerability equally, ReachGuard produces a more contextual assessment using factors such as severity, exploitability, reachability, and application context.
For each finding, the platform can provide information such as:
- Risk score
- Confidence score
- CVE information
- Severity
- CVSS score
- EPSS score
- KEV status
- Dependency information
- Reachability status
- AI reasoning
- Remediation advice
- Recommended fixed version
How We Built It
ReachGuard was built as a full-stack security platform.
Backend
The backend is implemented using FastAPI and is responsible for the core security analysis pipeline. The backend contains separate components for:
- Dependency scanning
- Vulnerability analysis
- Risk analysis
- Remediation analysis
- Reachability analysis
- NVD integration
- EPSS integration
- CISA KEV integration
- GitHub integration
- Database operations
- AI inference
The architecture uses a model abstraction layer so that the security agents do not depend directly on a particular AI engine.
AI Layer
We integrated Ollama as the real local AI inference backend.
The AI layer is used for contextual security reasoning and remediation analysis rather than simply generating generic text.
The backend's model loader provides an abstraction between the security agents and the underlying inference backend. This allows the application to keep the AI integration modular while using Ollama for actual inference.
The AI receives structured security context and produces reasoning that helps explain why a dependency is risky and what remediation approach should be considered.
Frontend
The frontend provides the interface through which users can initiate scans and inspect security findings.
It is designed to present complex security information in a more understandable way, including risk scores, vulnerability details, reachability information, AI reasoning, and remediation recommendations.
The frontend communicates with the FastAPI backend through APIs rather than implementing security analysis itself.
What We Learned
One of the biggest things we learned was that finding a vulnerability is not the same as understanding its real-world risk.
A vulnerability with a high CVSS score may not necessarily be exploitable in the application's actual execution path, while a seemingly less severe vulnerability could become important depending on how a dependency is used.
We also learned how different vulnerability intelligence sources complement each other:
- CVSS helps describe technical severity.
- EPSS provides an estimate of exploitation likelihood.
- CISA KEV provides evidence of vulnerabilities known to be exploited.
- Reachability analysis provides application-specific context.
- AI reasoning helps translate these signals into a more understandable security assessment.
We also gained practical experience building a modular AI architecture rather than coupling the entire application directly to one model or inference engine.
Challenges We Faced
One of our biggest challenges was integrating AI inference into an existing security-analysis pipeline without making the rest of the application dependent on a specific AI implementation.
We solved this by separating the AI inference layer from the security agents through a model-loader abstraction.
Another challenge was combining information from multiple security sources and presenting it as a meaningful risk assessment instead of simply displaying a list of CVEs.
We also faced challenges during full-stack integration, particularly around connecting the frontend with the existing FastAPI APIs and making the project work as a complete application rather than as independent frontend and backend components.
Managing local AI inference was another important challenge. Running the AI locally through Ollama required us to consider model availability, inference configuration, environment variables, and backend integration.
These challenges helped us understand that building a security product is not just about detecting vulnerabilities- it is about connecting data, context, analysis, and actionable remediation into one workflow.
What Makes ReachGuard Different
ReachGuard aims to move dependency security from:
"This package has a vulnerability." to: "This vulnerability exists, this is how it affects the application, this is how confident we are about the risk, and this is what you can do about it."
By combining vulnerability intelligence, reachability analysis, and local AI-powered reasoning, ReachGuard provides developers with a more contextual and actionable approach to dependency security.
Log in or sign up for Devpost to join the conversation.