# What Socket.dev Shows About GunDB's Supply Chain in 2026 — and How GenosDB Answers It

> A technical, source-cited comparison of the install-time supply-chain surface of `gun` (GunDB) as reported by Socket.dev, and how **GenosDB** — a zero-dependency, zero-trust, real-time peer-to-peer graph database — is designed to keep that surface empty. If you are weighing GunDB for production, or looking for a maintained GunDB alternative, this is the security-and-architecture comparison in full.

*Reading time: ~18 min. Written by* [*Esteban Fuster Pozzi*](https://github.com/estebanrfp)*, maintainer of GenosDB.*

* * *

## Context

Full disclosure: I built GenosDB, so I have a stake in this comparison — read it knowing that. Here's the rest of the context, so you can weigh it for yourself.

I spent years working with GunDB — building on it, building its documentation platform, and getting to know genuinely talented developers along the way. GunDB made real-time, offline-first, peer-to-peer data feel possible years before the rest of the ecosystem caught up, and it shaped how I think about decentralized systems.

GunDB defined a category: a real-time, offline-first, peer-to-peer graph database that runs in the browser. It is a reference point for decentralized, serverless data on the web, alongside projects like OrbitDB, Scuttlebutt and RxDB. GenosDB works in the same category — a distributed graph database with real-time P2P sync — and this post compares it with GunDB on one specific axis: **the security and supply-chain posture of the data/sync layer**, as measured by an external tool that scans npm packages statically, [Socket.dev](https://socket.dev).

Socket now provides a complete, itemized report of GunDB's install-time surface. This is the value of the exercise: what used to be described informally ("Gun's dependency tree is heavy") is now a set of concrete, countable facts. This post presents those facts, explains what each alert measures, traces the architectural pattern behind them, and describes how GenosDB's design produces a different report.

Everything here is verifiable. Every count comes straight from Socket's public pages, quoted as reported.

* * *

## What Socket.dev measures

Socket statically analyzes the *behavior* of every package in a dependency graph — whether it spawns a shell, reads environment variables, runs an install script, ships obfuscated or minified blobs, or contacts external URLs — and it does this **transitively**, across the full tree that an install would resolve.

Two properties of the method matter for reading the report:

1.  **It is transitive.** The counts below aggregate GunDB's entire dependency graph — every package Gun pulls in, directly and indirectly. A single `npm install gun` resolves this whole tree onto your machine.
    
2.  **It is behavioral, not just CVE-based.** Socket flags capabilities and code patterns (install scripts, `eval`, native binaries, obfuscation) because these are the primitives that supply-chain attacks use. The [jscrambler npm compromise Socket documented on July 11, 2026](https://socket.dev) — a malicious `preinstall` hook running hidden native binaries across Linux, macOS and Windows — is a recent example of this exact shape.
    

With that method in mind, here is the report.

![](https://cdn.hashnode.com/uploads/covers/6924809544867700748ef043/656dab93-596a-4598-86d3-e3cf0f68e0be.png align="center")

* * *

## The report: every Socket alert on `gun@0.2020.1241`

Source: `socket.dev/npm/package/gun/alerts/0.2020.1241?tab=dependencies`. Counts are "instances / packages affected" across Gun's dependency tree, quoted as Socket reports them.

### A. Known vulnerabilities (CVEs)

| Alert | Severity | Reach |
| --- | --- | --- |
| **Critical CVE** | 🔴 Vulnerability | 4 instances in 4 packages |
| **High CVE** | 🟠 Vulnerability | 24 instances in 16 packages |
| **Medium CVE** | 🟡 Vulnerability | 16 instances in 14 packages |
| **Low CVE** | Vulnerability | 5 instances in 4 packages |

The dependency tree carries published, catalogued CVEs at every severity tier, including four critical ones. Each is a documented compromise path with an identifier, present in a package Gun depends on. The path to remediation for a dependency CVE is a version bump upstream; as section C shows, that upstream cadence has stopped, so these fixes are not arriving.

The mechanism is timing: Gun's last release is from 2020, which froze its dependency ranges. Every CVE disclosed in those dependencies since then resolves into a fresh `npm install gun` today.

### B. Supply-chain behavior

**Obfuscated code** — *2 instances in 2 packages.* Files packaged to conceal their behavior. Socket's classification: a potential malware indicator.

**Uses** `eval` **/ dynamic code execution** — *38 instances in 38 packages.* Runtime `eval()` constructs and executes code that is absent from the audited source. It bypasses static analysis and requires relaxed CSP to run.

**Install scripts** — *2 instances in 2 packages.* `preinstall`/`postinstall` hooks execute automatically during `npm install`, with access to the shell, environment variables, and CI tokens. Two packages in Gun's tree run code at install time — the jscrambler vector.

**Shell access** — *20 instances in 20 packages.* Twenty packages can spawn a system shell, i.e. execute arbitrary commands.

**Network access** — *22 instances in 22 packages.* Twenty-two packages can open network connections. Combined with the environment and filesystem access below, this is the full read-secrets-and-transmit capability set.

**Filesystem access** — *78 instances in 78 packages.* Seventy-eight packages can read the disk, and therefore any sensitive data on it.

**Environment-variable access** — *75 instances in 75 packages.* Seventy-five packages read `process.env`, where credentials and tokens live. Socket's classification associates this with credential harvesting.

**URL strings** — *78 instances in 77 packages.* Hardcoded URLs / external IPs the package may contact at runtime — the potential destinations for data.

**Dynamic requires** — *19 instances in 19 packages.* Modules resolved at runtime rather than statically, which loads code a scanner cannot see in advance.

**Debug / reflection access** — *15 instances in 15 packages.* Debug, reflection and dynamic-execution features that expand runtime self-modification.

**Native code** — *2 instances in 2 packages.* Compiled binaries / shared libraries, which are opaque to source review.

**AI-detected potential code anomaly** — *52 instances in 50 packages.* Socket's ML flagged unusual behavior across fifty packages for human review.

**Trivial package** — *23 instances in 23 packages.* Twenty-three dependencies under ~10 lines of code. Each is a full third-party trust relationship, and an independent takeover target, for logic that could be inlined.

**AI-detected potential typosquats** — names in the tree close to far more popular packages (Socket names `camelcase` and `babel-plugin-transform-react-jsx` as the likely targets). Typosquatting is a primary malware-delivery technique.

**Nonexistent author / New author** — packages published by an npm account that no longer exists, and (*36 instances in 36 packages*) first-time publishers. Both correlate with account-takeover and namespace-hijack events.

**Potential vulnerability** — flagged by initial human review, pending confirmation.

### C. Maintenance

**Unmaintained** — *201 instances in 201 packages.* Two hundred and one packages in the tree have gone more than five years without an update. This is the majority of the tree, and it is the reason the CVEs in section A stay open: the upstream cadence that would ship fixes has stopped.

**Deprecated** — *23 instances in 23 packages.* Twenty-three dependencies the maintainers themselves marked as superseded.

### D. Quality

**Minified code** — *12 instances in 9 packages.* Source shipped minified, which reduces auditability. **Unpopular package** — *2 instances in 2 packages.* Low-usage dependencies, with fewer reviewers. **Floating dependency** — a dependency on a floating range that can pull a breaking major without notice.

### E. License

**Multiple license problems**, **unidentified license**, **copyleft license**, **non-permissive license.** For commercial software, the tree introduces license ambiguity and copyleft/non-permissive terms that carry legal obligations.

* * *

## The pattern behind the numbers

The counts aggregate GunDB's transitive tree, and read together they describe one coherent architectural situation:

> A large dependency graph — hundreds of packages, the majority unmaintained for five-plus years — carrying four critical CVEs (plus dozens of high and medium) with no upstream path to a fix, alongside install scripts, native binaries, obfuscated files, and typosquat-adjacent names.

This describes the **architecture of trust** the design asks you to accept: a broad, deep dependency tree, taken on faith, frozen since 2020. Two design choices produce it:

1.  **A broad runtime dependency tree.** Every convenience pulled from npm is a permanent, transitively-multiplied trust relationship. Gun's tree grew the way most 2018-era JavaScript libraries' trees grew.
    
2.  **A dormant maintenance cadence.** With the last release in 2020, the tree accumulates CVEs over time and sheds none, because remediation depends on upstream updates that have stopped.
    

`npm audit fix` operates on this tree; it cannot restructure it. The path to a different report is a different architecture — one that keeps the tree empty from the start. That architecture is the design goal of GenosDB.

* * *

## The maintainer's own account

The maintenance status is also on the record from the source. GunDB's creator, Mark Nadal, characterizes Gun as "actively used and in production" and scalable to millions of monthly users. In the same statement he describes the current maintenance cadence directly: he reached "about 70%" through fixing known bugs, has stepped back from day-to-day upkeep since around 2020, and frames the reduced-support period as running with "no promised timeline" until the next Gun release, pointing users to community forks for prioritized fixes in the meantime.

These are the maintainer's own words: a production claim on one side, and a paused upstream maintenance cadence with unresolved known bugs on the other. When you choose a foundation to build on for the long term, the useful question is not which claim to believe — it is what you can run and confirm yourself. That is the axis where GenosDB is designed to be checked.

* * *

## How GenosDB produces a different report

GenosDB (GDB) is a distributed, real-time, peer-to-peer graph database — the same category as GunDB. The comparison here is on the same axis: the security and supply-chain posture of the data/sync layer, measured by the same tool.

Here is [GenosDB's Socket.dev report](https://socket.dev/npm/package/genosdb):

| Metric | GenosDB | Meaning |
| --- | --- | --- |
| **Dependencies** | **0** | A self-contained package; the audit target is the package itself. |
| **Vulnerability** | **100 / 100** | Clean. |
| **Supply-chain security** | 79 | Strong, and rising as the package ages. |
| **Quality** | 99 | — |
| **Maintenance** | 96 | 100+ versions on a weekly release cadence held since inception. |
| **License** | 80 | A single, declared license. |

Mapped back to Gun's report, class by class:

### 1\. Zero dependencies

![](https://cdn.hashnode.com/uploads/covers/6924809544867700748ef043/58e2e605-88ca-457b-a00e-6d63e07d46b8.png align="center")

GenosDB ships zero runtime dependencies, which Socket confirms: `Dependencies: 0`.

Every alert in sections B, C, D and E is an alert *about a dependency*. A self-contained package resolves the entire category structurally: the audit target is one package, and it is the exact artifact a scanner analyzes, because what ships on npm is the whole product.

The primitives GenosDB builds on — Ethereum key/signature handling, MessagePack serialization, Pako compression — are pinned to exact versions, reviewed on each bump, and bundled into the published `dist` at build time. They live in `devDependencies` and travel inside the artifact rather than resolving fresh from npm on each install. This vendored-and-pinned model is why Socket reports `0`: at install time, the package is complete on its own.

### 2\. Clean vulnerability score

With a self-contained package, section A's dependency CVEs are absent, and GenosDB's own code carries a clean vulnerability score (Socket: 100). The active release cadence (section 4) means a future finding has a channel to a fix.

### 3\. A minimal install-time footprint

*   **Install runs files only.** GenosDB's `package.json` defines no `preinstall`/`postinstall` hooks, so `npm install genosdb` copies the package and stops there.
    
*   **Pure JavaScript, pure ESM** (`"type": "module"`). The artifact is readable source, transparent to review.
    
*   **The sync and security layers are built from static code**, keeping runtime dynamic execution out of the architecture.
    

### 4\. Active maintenance

GenosDB has more than 100 published versions on a weekly release cadence held since the project began, and a maintenance score of 96. Development runs on a **Spec-Driven Development** method: Esteban Fuster Pozzi as architect and accountable owner, supported by qualified developers and a cluster of audited AI systems whose output is verified against written specifications before it ships. A self-contained base plus a specification-first cadence is what holds the report above stable as the project grows.

### 5\. A single declared license

GenosDB ships under one declared license (Socket: License 80), with a `THIRD_PARTY_LICENSES.md` accounting for the bundled primitives. A self-contained package keeps license terms singular and explicit.

### 6\. Bundle, license, and governance

GenosDB's published bundle is free, public, and licensed for commercial use — free to install, inspect, run in production, and ship commercially. Its source is curated on a **Spec-Driven Development** method — Esteban Fuster Pozzi as accountable architect, qualified developers, and a cluster of audited AI systems working against written specifications — and that process is what keeps the dependency surface at zero: dependencies are chosen deliberately, primitives are pinned and reviewed on each bump, and every change is validated against a spec before it ships. The properties in sections 1–5 are the direct output of that model.

Auditability tracks the artifact you run. The published bundle is complete JavaScript on npm, and it is exactly what Socket.dev — and you — analyze. You audit the code that executes on your machine.

A door stays open for the future. As the project matures, additional developers qualified in Spec-Driven Development may be incorporated — selected by consensus — to secure continuity over the very long term, extending the same specification-first discipline that produces the report above.

### 7\. The feature surface is demonstrated, not asserted

A database is worth what you can run. GenosDB ships its entire feature surface as self-contained, runnable example apps — more than fifty of them in the repository, each a single HTML file you open and use on the same engine you would deploy. The set spans the whole surface: CRUD and cursor pagination; real-time chat, kanban, collaborative whiteboard and rich-text editors, live cursors and presence; peer-to-peer audio, video and file streaming; geo-spatial queries; the full security suite — RBAC, WebAuthn, node-level ACLs, governance, client-side encryption; and cellular-mesh scaling monitors. Every capability described in this post has a working demo behind it.

![](https://cdn.hashnode.com/uploads/covers/6924809544867700748ef043/3eb5a2f5-d599-41f3-884b-ce3891d7b98e.png align="center")

This is the falsifiable form of a database claim. Rather than "trust that it works," the standing invitation is "open these and watch them work" — the same way you would evaluate any foundation before you build on it. Verification, not belief, is the design stance, from the install-time report down to each example.

* * *

## The data plane: cryptographic enforcement at runtime

![](https://cdn.hashnode.com/uploads/covers/6924809544867700748ef043/4f2d6499-028b-44cf-8068-9bfc613e232a.png align="center")

Sections 1–6 concern the install-time surface. A peer-to-peer database also governs a second axis at runtime: once peers are connected, who is authorized to change what. With no server to enforce rules, GenosDB enforces them cryptographically, and each peer verifies every operation independently. From the [distributed trust model](https://github.com/estebanrfp/gdb) and the source:

*   **Signed operations.** Every write is signed by the author's Ethereum key (`signOutgoingOperations`) and verified by each receiving peer (`verifyIncomingOperations`) before it applies. Identity is cryptographic.
    
*   **Zero-trust default.** A new identity is a write-blocked `guest` with a single welcome exception — creating its own user node — where the engine forces the role to `guest`, so first-message self-promotion resolves to guest. Higher permissions arrive when a `superadmin` signs a promotion.
    
*   **RBAC.** A `guest → user → manager → admin → superadmin` hierarchy, enforced locally by each peer's Security Manager. A peer verifies the signed role that authorizes each operation, so a locally-edited client acts within its actual granted role on the network.
    
*   **Node-level ACLs, enforced across peers.** Since v0.14.0, per-node `read`/`write`/`delete` grants are checked against the cryptographically-verified author of each incoming operation, on every peer. A node accepts writes from its owner and collaborators.
    
*   **Governance.** A superadmin declares promotion/demotion rules as native GenosDB queries; the engine resolves each user's role by last-match-wins and signs every change for peers to verify — optionally 24/7 via an always-on [Fallback Server](https://github.com/estebanrfp/gdb).
    
*   **Decentralized signaling.** The real-time layer (GenosRTC) discovers peers over **Nostr relays** with its own audited crypto/codec, and can encrypt the signaling channel with a shared password.
    
*   **Client-side encryption.** `db.sm.put()` / `db.sm.get()` store data end-to-end encrypted, readable by the user who wrote it.
    

The two axes share one design principle: replace trust with verification. Peers verify every operation cryptographically; the package stays self-contained.

* * *

## Downloads, and the last word

A download is a trial, not an outcome. npm counts package fetches — installs, CI runs, mirrors, reinstalls — not developers who shipped a system and kept it running. Popularity measures how many people arrive at a technology, not how many build something durable on it and stay. For a foundational dependency, that gap is where the risk lives: reputation brings developers in the door, and a paused maintenance cadence with unpatchable issues is what some of them find on the other side.

No download count settles that. A clean install-time report, a self-contained package, and a feature surface you can run exist to put the decision where it belongs — with the developer who tries it. Build the same small thing on each, and let the result speak. The last word is the developer's.

* * *

## The ask

I want help spreading GenosDB, and I'm asking for it directly.

The value an independent maintainer benefits from most is reach and scrutiny:

*   **If the architecture makes sense to you, say so where developers will see it.** A star on [github.com/estebanrfp/gdb](https://github.com/estebanrfp/gdb), a reshare, or a mention in a thread where someone is choosing a real-time P2P database moves an independent project forward.
    
*   **Test it adversarially.** The public bundle and the live demos are enough: run two browsers, try to forge a signed operation or promote past the zero-trust guard, and report what you find via `SECURITY.md`. Black-box scrutiny is the highest-value contribution to a security-adjacent project.
    
*   **Port one feature from GunDB.** A single slice is enough to feel the zero-dependency, zero-trust version and to tell me where it can improve.
    
*   **If you align with this approach and you're strong technically, introduce yourself.** Contribution opens progressively to a small, vetted, aligned team chosen by consensus, and I'm keeping a list for when that starts.
    

GunDB defined this category. The goal here is to give it a foundation that a 2026 supply-chain scanner reports clean — and to invite the people who care about that to help prove it, or test it, in public.

The surface is measured now. Let's build on the one that stays empty.

* * *

## Frequently asked questions

**Is GunDB still maintained in 2026?** GunDB remains widely installed and is used in production. Active upstream maintenance of the current line, though, is paused by the maintainer's own account since around 2020 — known bugs remain, there is no committed timeline for the next release, and users are pointed to community forks for prioritized fixes. Socket.dev's scan reflects it: the majority of Gun's dependency tree is flagged as unmaintained.

**Is GunDB safe to use in production?** It depends on your risk tolerance. GunDB has real production deployments and a decade of decentralized-data work in its own source. On the supply-chain axis, Socket.dev reports its dependency tree carries four critical CVEs (plus dozens of high and medium), install scripts, obfuscated code and native binaries, with most of the tree unmaintained for five-plus years — issues without an upstream path to a fix while maintenance is paused. Weigh that install-time surface against your use case.

**What is a maintained alternative to GunDB?** GenosDB is a maintained, actively-released alternative in the same category — a distributed, real-time, peer-to-peer graph database in pure JavaScript, reporting zero dependencies and a clean vulnerability score on Socket.dev. Other decentralized options include OrbitDB (on IPFS/libp2p), Scuttlebutt and RxDB; see this [P2P & CRDT database comparison](https://genosdb.com/popular-p2p-distributed-databases) for the wider landscape.

**How does GenosDB compare to GunDB?** Both are real-time, offline-first, peer-to-peer graph databases. GenosDB ships zero runtime dependencies (versus GunDB's flagged transitive tree), a zero-trust security model with signed operations, RBAC, node-level ACLs and governance, and OPFS + Web Worker persistence that keeps the main thread non-blocking (GunDB's default persistence is commonly localStorage, a synchronous ~5 MB store on the main thread). Its real-time layer, GenosRTC, pairs WebRTC with decentralized Nostr signaling.

**How does GenosDB compare to OrbitDB, Scuttlebutt or RxDB?** OrbitDB builds on IPFS/libp2p; Scuttlebutt is a log-based social protocol; RxDB is a local-first database with pluggable replication. GenosDB is browser-native and serverless, with integrated WebRTC transport and Nostr signaling, a MongoDB-style query layer with recursive graph traversal, and a built-in zero-trust security model — at zero runtime dependencies. Full landscape: [Best P2P & CRDT databases in 2026](https://genosdb.com/popular-p2p-distributed-databases).

**Does GenosDB have dependencies?** Zero, at install time — Socket.dev reports `Dependencies: 0`. The primitives it builds on (Ethereum signatures, MessagePack, Pako) are pinned, reviewed and bundled into the published artifact at build time, rather than resolved from npm as a transitive tree.

**Is GenosDB free and open source?** The GenosDB bundle is free, public and licensed for commercial use — free to install, inspect, run in production and ship commercially. The source is curated under a Spec-Driven Development method, and contribution opens progressively to qualified, consensus-selected developers to secure continuity over the long term.

* * *

**GenosDB** — distributed, real-time, peer-to-peer graph database. Zero dependencies, zero-trust, serverless. 🔗 [github.com/estebanrfp/gdb](https://github.com/estebanrfp/gdb) · [npm: genosdb](https://www.npmjs.com/package/genosdb) · [Socket report](https://socket.dev/npm/package/genosdb)

## Author

Esteban Fuster Pozzi (@estebanrfp) - Full Stack JavaScript Developer

* * *

### Sources & verification

*   GunDB Socket report: `socket.dev/npm/package/gun/alerts/0.2020.1241?tab=dependencies` (all alert counts quoted verbatim).
    
*   GenosDB Socket report: `socket.dev/npm/package/genosdb` (scores; 0 dependencies).
    
*   GenosDB security model: `SECURITY.md`, `docs/zero-trust-security-model.md`, `docs/genosdb-distributed-trust-model.md`, `docs/genosdb-features.md` in the GenosDB repository.
    
*   Architecture claims (signing/verification, ACLs, governance, Nostr signaling) verified against the GenosDB, GenosRTC and GenosSRV source.
    

### My personal take

These figures are a snapshot: CVE counts, unmaintained packages and Socket scores all shift as the community patches, so re-run the scan whenever you read this and let today's numbers speak.

GunDB stays a solid choice for prototypes, internal tools and many wonderful production apps.

* * *

> **This article is part of the official documentation of GenosDB (GDB).**  
> GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by **Esteban Fuster Pozzi (**[**estebanrfp**](https://github.com/estebanrfp)**)**.

📄 [Whitepaper](https://github.com/estebanrfp/gdb/blob/main/WHITEPAPER.md) | overview of GenosDB design and architecture

🛠 [Roadmap](https://github.com/estebanrfp/gdb/blob/main/ROADMAP.md) | planned features and future updates

💡 [Examples](https://github.com/estebanrfp/gdb/blob/main/docs/genosdb-examples.md) | code snippets and usage demos

📖 [Documentation](https://github.com/estebanrfp/gdb/blob/main/docs/index.md) | full reference guide

🔍 [API Reference](https://github.com/estebanrfp/gdb/blob/main/docs/genosdb-api-reference.md) | detailed API methods

📚 [Wiki](https://github.com/estebanrfp/gdb/wiki) | additional notes and guides

💬 [GitHub Discussions](https://github.com/estebanrfp/gdb/discussions) | community questions and feedback

🗂 [Repository](https://github.com/estebanrfp/gdb) | Minified production-ready files

📦 [Install via npm](https://www.npmjs.com/package/genosdb) | quick setup instructions

🌐 [Website](https://estebanrfp.com/) | [GitHub](https://github.com/estebanrfp) | [LinkedIn](https://www.linkedin.com/in/estebanrfp/)