ResilienceAI Inspiration
Payment systems depend on hundreds of open-source libraries and tools. A vulnerability in just one of these dependencies can potentially affect multiple services and, in turn, the financial institutions connected to them.
Most vulnerability scanners give developers a list of CVEs, their severity and possible fixes. That's useful, but it doesn't tell the whole story. In a payment network, knowing that a library is vulnerable isn't enough. We also need to understand what happens if that vulnerability is exploited and which connected services could be affected.
That's the problem we wanted to solve with ResilienceAI.
We wanted to build something that goes beyond vulnerability detection and helps visualize how security issues can affect an entire financial infrastructure.
Another thing that influenced our approach was the March 2026 compromise involving Trivy's releases and GitHub Actions. It reminded us that even the security tools we rely on can become part of the attack surface. We took this into account while designing our scanning pipeline.
What it does
ResilienceAI combines vulnerability scanning, dependency analysis and AI-powered explanations into a single platform.
Here's what it can do:
Dual vulnerability scanning: Scans public GitHub repositories using Trivy and OSV-Scanner simultaneously, combining their results into one deduplicated report.
SBOM generation: Generates a CycloneDX Software Bill of Materials for every scan.
Severity classification: Standardizes vulnerabilities into CRITICAL, HIGH, MEDIUM, LOW and UNKNOWN categories. If a vulnerability doesn't have a severity score, we leave it as UNKNOWN rather than making assumptions.
Finding attribution: Shows which scanner detected each vulnerability. If both scanners detect the same issue, it appears only once.
Infrastructure simulation: Models three independent banks (Bank A, Bank B and Bank C) as separate services and uses NetworkX to analyze how vulnerabilities can spread across their dependencies.
AI-powered explanations: Converts technical vulnerability reports into understandable explanations, helping developers identify the risks and prioritize fixes.
Payment integration: Connects with the PayPal Sandbox to demonstrate how these vulnerabilities could affect an actual payment workflow.
Dashboard: Provides a Next.js interface where users can submit repositories, view scan results and explore the infrastructure impact.
How we built it
We divided development into four major parts, with separate file ownership to make parallel development easier and reduce merge conflicts.
- Security intelligence engine
Tech stack: Python, FastAPI, Pydantic
This is where the vulnerability scanning happens.
We integrated Trivy and OSV-Scanner as independent subprocesses and run them concurrently. Both scanners have execution timeouts, and if one fails, the other can still return its results.
Since the scanners produce different output formats, we built a normalizer that converts everything into a common Finding model. It handles vulnerability IDs, severity levels and available fixed versions.
We also implemented deduplication so that the same vulnerability reported by both scanners doesn't appear twice.
For repository scanning, we use shallow Git clones and restrict input to valid public GitHub repository URLs. Git hooks, submodules, password prompts and execution of repository code are disabled or restricted. Temporary repositories are deleted after scanning.
The engine also exposes three main API endpoints:
POST /api/scan – Starts a scan in the background.
GET /api/scan/{id} – Retrieves the scan report.
GET /api/scan/{id}/sbom – Downloads the generated SBOM.
We also developed a CLI tool that can be integrated into CI pipelines. It generates reports and SBOMs and returns an exit code based on the severity of the findings.
- CI/CD security
Tech stack: GitHub Actions
One of the things we paid particular attention to was the security of our own scanning pipeline.
Following the March 2026 Trivy compromise, we decided not to rely on Trivy's third-party GitHub Actions. Instead, our workflow downloads pinned releases of Trivy and OSV-Scanner and verifies their SHA-256 checksums before execution.
The workflow runs with read-only permissions and uploads the generated vulnerability report and SBOM as build artifacts.
- Banking simulator
Tech stack: Docker
To demonstrate how vulnerabilities can affect interconnected financial systems, we created a small banking simulation.
Bank A, Bank B and Bank C run as separate containerized services. Each has its own dependencies, allowing us to model relationships between different components and study how a compromised dependency could affect other services.
This gives us a controlled environment to demonstrate infrastructure-level risks without interacting with real banking systems.
- Backend integration, graph analysis and AI
Tech stack: FastAPI, NetworkX
We use NetworkX to represent the banking infrastructure as a dependency graph.
When a vulnerable component is identified, we can trace its connections and determine which services might be affected. This helps move the analysis beyond individual CVEs and towards understanding the broader impact on the network.
We also integrated an AI layer that explains vulnerabilities in plain English and helps prioritize remediation.
The PayPal Sandbox integration connects this analysis to a simulated payment flow, making it easier to demonstrate the potential consequences of security issues in a payment environment.
This part also handles the integration of the individual modules and deployment.
- Frontend
Tech stack: Next.js
We built a dashboard that brings everything together.
Users can submit a public GitHub repository, monitor the scan, browse vulnerabilities by severity and inspect the generated SBOM.
The dashboard also includes the resilience view, where users can explore the simulated banking network and understand how vulnerabilities in one component could affect connected services.
Challenges we ran into
We faced a few interesting challenges while building ResilienceAI.
Combining different scanners: Trivy and OSV-Scanner don't report vulnerabilities in exactly the same way. Their severity formats and detection coverage also differ. Building a common format without losing important information took quite a bit of work. In our test fixture, 17 findings were detected by both scanners, while OSV-Scanner identified another 15.
The Trivy compromise: Learning that a security tool we were using had itself been compromised forced us to rethink part of our CI/CD pipeline. We moved away from third-party actions and implemented pinned downloads with checksum verification.
Handling untrusted repositories: Scanning arbitrary GitHub repositories comes with security risks. We had to make sure that repository contents were never executed and that cloning operations were restricted and cleaned up properly.
Handling failures properly: We didn't want the platform to produce misleading results just because one scanner failed. We made sure failures were explicitly reported and that missing severity information was never replaced with guessed values.
Parallel development: With four people working on different parts of the project, integration was another challenge. Defining API contracts and file ownership early helped us avoid unnecessary merge conflicts.
Accomplishments we're proud of
Getting all the individual components to work together was probably our biggest achievement.
Some results from our testing:
A deliberately vulnerable test fixture produced 32 merged findings, including 3 critical, 13 high and 16 medium vulnerabilities.
Scanning OWASP NodeGoat produced 197 findings and an SBOM containing 381 components.
Both test runs completed without scanner errors.
We successfully integrated two independent vulnerability scanners into one reporting pipeline.
We implemented a CI pipeline with pinned scanner versions and checksum verification.
We connected vulnerability detection, dependency graph analysis, AI explanations and a simulated PayPal payment flow into one platform.
Most importantly, we built a system that doesn't stop at telling developers what's vulnerable. It also gives them a way to understand why it matters.
What we learned
Building ResilienceAI taught us quite a bit about application security and distributed systems.
Using multiple scanners can improve detection coverage, but combining their results requires careful normalization and deduplication.
We also realized how important it is to secure the tools used in a security pipeline. A vulnerability scanner shouldn't automatically be considered trustworthy just because its purpose is security.
Another important takeaway was the difference between identifying a vulnerability and understanding its actual impact. A medium-severity issue in a widely shared dependency could potentially deserve more attention than a critical issue isolated to a single service.
Finally, working in a team of four taught us the importance of defining clear responsibilities, agreeing on API contracts and keeping modules independent during development.
What's next for ResilienceAI
There are several things we'd like to improve and expand.
Persistent scan history: Move scan results from in-memory storage to a database so users can revisit previous scans.
Private repository support: Add authentication and support scanning private repositories and specific branches.
Improved SBOM coverage: Include transitive dependencies that may not appear in the current Trivy SBOM.
Additional security checks: Integrate secret scanning and infrastructure-as-code analysis.
Better risk prioritization: Incorporate EPSS scores and known-exploited vulnerability databases to identify issues that are more likely to be exploited.
Automated remediation: Add pull request comments and suggestions for fixing vulnerable dependencies.
Larger infrastructure simulations: Expand beyond three banks and introduce additional failure scenarios to study how vulnerabilities affect larger networks.
Our long-term goal is to make ResilienceAI useful not just for finding vulnerabilities, but for helping developers understand and improve the resilience of the systems they build.
