Stack3 Security: Building a TigerGraph-Powered Threat Intelligence Graph for Repositories, Packages, and Wallet Requests

Built at Hacker House Goa | TigerGraph Open Innovation Track

Web3 security threats rarely exist in isolation.

A malicious npm package might communicate with a suspicious domain. A compromised repository might contain an automated command that executes when a developer trusts a workspace. A phishing website might request unlimited token approval from a user's wallet.

Individually, these signals might look unrelated. Connected together, they can reveal a much bigger threat.

That's the problem we set out to solve with Stack3 Security — a Web3 security platform built for developers and wallet users, powered by TigerGraph.

This project was built at Hacker House Goa as part of the TigerGraph Open Innovation track.

1. The Problem: Security Signals Are Disconnected

Consider two scenarios.

Scenario A: A malicious repository

A developer receives a GitHub repository as part of a take-home assignment. Hidden inside .vscode/tasks.json is a command that can execute when the developer trusts the workspace.

Opening an unfamiliar repository can therefore introduce risks before the developer even starts reviewing the code.

Scenario B: A malicious Web3 website

A user visits a dApp advertising a reward claim. The website looks legitimate, but the wallet request asks for an unlimited token approval.

The user might approve a transaction without understanding what permissions they are granting.

These events are generally investigated using different tools.

Repository scanners, package security services, phishing detection systems, and wallet security tools operate independently.

The missing piece is shared threat intelligence.

We wanted to connect these signals so that discovering a threat in one environment could provide useful context to another.

2. What We Built: Stack3 Security

Stack3 brings together three security surfaces backed by a shared threat intelligence graph.

VS Code Extension — Repository Security

The VS Code extension allows developers to clone and scan public GitHub repositories before opening them.

Our workflow is designed around one principle: never execute untrusted code during scanning.

The process includes:

• Accepting a public GitHub repository URL.
• Cloning the repository into a quarantine environment.
• Reading project files as data without executing them.
• Detecting suspicious configurations, including auto-run behavior, installation scripts, and exposed secrets.
• Identifying npm dependencies and checking packages through Socket.
• Generating a security verdict before the developer opens the project.

We also provide an Open with Auto-Run Disabled option that moves .vscode and .devcontainer configurations aside before opening the workspace.

This helps reduce the risk of automatically triggered development environment commands.

Chrome Extension — Web3 Website and Wallet Security

The Chrome extension focuses on identifying potentially malicious websites and suspicious wallet interactions.

It analyzes page-level and phishing signals and monitors wallet requests.

One important implementation is wrapping ethereum.request so that wallet interactions can be reviewed before being forwarded to MetaMask.

This allows Stack3 to inspect potentially dangerous requests before the wallet processes them.

We also designed the extension to fail gracefully: if the security extension is unavailable, the underlying wallet functionality should continue working.

Stack3 Dashboard

The dashboard provides a centralized interface for security information.

It includes:

• Email OTP authentication.
• Website scanning.
• Repository scanning.
• One-hop threat graph visualization.
• Connected threat intelligence.

The dashboard allows users to explore relationships between repositories, domains, software packages, endpoints, and wallets.

3. Why TigerGraph?

The most important architectural decision was using TigerGraph as a shared threat intelligence layer.

Traditional security scanners generally produce individual reports.

For example:

• A repository scanner identifies a suspicious package.
• A website scanner identifies a suspicious domain.
• A wallet scanner identifies a potentially dangerous wallet interaction.

But what happens when all three findings are connected?

Imagine the following relationships:

Repository → Package → Domain → Wallet

A package used by a repository communicates with a suspicious domain, and that domain is associated with a wallet already identified in another security report.

Looking at each report independently makes this relationship difficult to discover.

A graph database makes these connections explicit.

TigerGraph allows Stack3 to represent security entities as vertices and their relationships as edges.

This means a finding discovered during one scan can provide useful context during another scan.

4. TigerGraph Architecture and Implementation

We implemented a graph-local schema using TigerGraph Savanna 4.x.

Graph Vertices

Our schema includes five primary vertex types:

Vertex	Purpose
Wallet	Represents blockchain wallet addresses
Domain	Represents websites and hostnames
SoftwarePackage	Represents software packages
Repo	Represents GitHub repositories
Endpoint	Represents network endpoints

We used SoftwarePackage instead of Package because Package is reserved in our environment.

Graph Edges

We implemented relationships between these entities, including reverse edges.

The primary relationships are:

• PACKAGE_DRAINS_TO
• DOMAIN_DRAINS_TO
• PACKAGE_SENDS_TO
• DOMAIN_SENDS_TO
• LOADS_SCRIPT
• DEPENDS_ON
• FUNDED

Reverse edges allow us to explore relationships in both directions and retrieve a more useful one-hop neighbourhood.

Entity ID Normalization

Consistent identifiers are essential when multiple security surfaces write to the same graph.

We normalize identifiers in the API layer.

Examples:

• Wallet: 1:0x…
• Domain: hostname
• npm package: pkg:npm/name@version
• Repository: github:owner/name
• Endpoint: https://…

This ensures that the same entity can be referenced consistently across different scanning services.

5. Integrating with TigerGraph REST++

We used TigerGraph REST++ APIs rather than installed GSQL query files.

The integration uses the following endpoints:

Authentication

POST /gsql/v1/tokens

We encountered an issue with the older /restpp/requesttoken endpoint, which returned HTTP 400 in our environment. We switched to the token endpoint above.

Graph Upsert

POST /restpp/graph/stack3

This endpoint handles writing and updating graph entities and relationships.

Vertex Retrieval

GET /restpp/graph/stack3/vertices/{type}/{id}

Edge Retrieval

GET /restpp/graph/stack3/edges/{type}/{id}?limit=200

The vertex and edge retrieval endpoints power our one-hop neighbourhood visualization.

6. Data Flow: PostgreSQL + TigerGraph

We deliberately designed the architecture so that TigerGraph is not the only source of truth.

Our data flow is:

1. A security scan generates a report.
2. The report is persisted in PostgreSQL first.
3. A background worker attempts to synchronize the relevant threat entities and relationships with TigerGraph.
4. The dashboard requests graph information.
5. If graph synchronization is pending or TigerGraph is unavailable, the application can fall back to PostgreSQL.

This approach gives us reliable report persistence while allowing graph synchronization to happen asynchronously.

PostgreSQL handles the primary report storage, while TigerGraph provides relationship-based threat intelligence.

The architecture can be represented as:

VS Code Extension ──┐
                    │
Chrome Extension ───┼──► FastAPI
                    │       │
Website Scanner ────┘       │
                            ▼
                        PostgreSQL
                      (Source of Truth)
                            │
                            ▼
                     Background Worker
                            │
                            ▼
                        TigerGraph
                     (Threat Intelligence)
                            │
                            ▼
                       Dashboard
                     (Graph Explorer)

Our APIs run on Cloudflare Workers and containers.

Authentication uses email OTP and JWT. Billing is integrated with Dodo in test mode.

7. What Would Not Be Possible Without a Graph?

This is where TigerGraph becomes particularly important.

Imagine a repository scan discovers that a particular software package communicates with wallet X.

Separately, a website scan discovers that a particular domain is also associated with wallet X.

Both findings are stored independently.

Without a graph, connecting these findings requires additional lookup logic across different reports and databases.

With TigerGraph, we can query wallet X and retrieve its one-hop neighbourhood, including incoming and outgoing relationships.

This gives Stack3 a shared context across different security surfaces.

A repository scan can contribute intelligence that becomes useful to a website scan, and vice versa.

That is the core value of the graph architecture.

8. Results and Current Implementation

We have implemented and deployed several working components.

• Live Cloudflare Workers for the Chrome API.
• VS Code repository scanning API.
• Live website.
• GitHub clone-and-scan workflow for public repositories.
• npm dependency extraction, including handling ^ version ranges when no lockfile is available.
• Socket integration for package security checks.
• Prioritization of flagged packages in scan results.
• TigerGraph upserts and one-hop neighbourhood retrieval.
• PostgreSQL fallback when graph synchronization is pending.
• Dashboard-based graph visualization.

We also made an important distinction in our security reporting.

Stack3 never labels a result simply as Safe.

Instead, we use the following levels:

• Critical
• High
• Caution
• Unknown
• No Known Issues

Failed checks are marked as Not Checked, rather than being treated as successful checks.

A clean Socket response is represented as "Checked, No Alerts" rather than notChecked.

We believe security products should communicate uncertainty honestly instead of giving users a false sense of security.

9. Current Limitations

There are still limitations in the current implementation.

• Repository clone-and-scan currently supports public GitHub repositories.
• Wallet security currently focuses on EVM wallets.
• The first container request can take longer because of initialization.
• Graph intelligence currently focuses on writes and one-hop lookups.
• We do not currently implement vector search, PageRank, or MCP integration.
• A successful scan does not guarantee that a repository or website is completely safe.

These are important boundaries of the current implementation, not capabilities we want to overstate.

10. What's Next?

Our next focus is expanding the threat intelligence layer.

Some areas we want to explore include:

• Deeper relationship traversal across threat entities.
• Improved wallet and transaction risk analysis.
• More sophisticated dependency and package risk correlation.
• Better phishing and malicious domain intelligence.
• Expanding repository scanning capabilities.
• More comprehensive threat visualization.

The long-term goal is to make Stack3 a shared security intelligence layer for Web3 developers and wallet users.

11. Explore the Code

Stack3 Security is being developed as an integrated security platform.

GitHub Repository:

https://github.com/yashjain197/stack3security

TigerGraph Schema:

chrome-extension-backend/backend/graph/schema.gsql

We would love to hear feedback from the TigerGraph and Web3 security communities, especially around graph modelling, threat relationship discovery, and practical ways to improve cross-surface security intelligence.

---

Built at Hacker House Goa for the TigerGraph Open Innovation Track.

Stack3 Security — Connecting threats before they become incidents.