About Deptic

Built to make software supply chains transparent

Deptic started with one question: how can a developer know exactly what their software is made of? We built the answer.

The problem we're solving

Modern software doesn't exist in isolation. A typical web application depends on hundreds — sometimes thousands — of third-party packages. A React frontend alone can have 1,200+ transitive dependencies. A Spring Boot backend routinely pulls in 300+ Maven artifacts. Most developers have no idea what's inside their stack.

This isn't a theoretical risk. In December 2021, a single vulnerability in log4j-core@2.14.1 — a logging library buried deep in the transitive dependency tree of millions of Java applications — became the most critical security incident in a decade. The majority of affected teams didn't even know they were using log4j.

US Executive Order 14028 (May 2021) and the EU Cyber Resilience Act (2024) now legally require software vendors selling to government and enterprise to provide a complete Software Bill of Materials — a full inventory of every component in their product. Most teams have no way to generate one.

Deptic solves this.

What Deptic does

Complete dependency visibility

Deptic scans any GitHub repository and resolves the full dependency tree — direct and transitive — across npm, pip, Maven, Go, Rust, Ruby, PHP, and .NET. A scan of spring-projects/spring-petclinic returns 63 components. facebook/react returns 845. gin-gonic/gin returns 35. Every package, every version, every license.

Real vulnerability detection

Every component is matched against OSV.dev and NVD — two authoritative CVE databases. Deptic doesn't use fuzzy name matching. It uses Package URLs (PURLs) for precise identification. CVEs are returned with severity scores, affected version ranges, and the exact version you need to upgrade to.

Government-grade compliance

Deptic automatically checks all 7 NTIA minimum elements defined in EO14028: supplier name, component name, version, unique identifiers, dependency relationships, SBOM author, and timestamp. It exports machine-readable SBOMs in CycloneDX 1.5 and SPDX 2.3 formats — both accepted by US federal agencies.

Automated remediation

When a vulnerability is found, Deptic doesn't just report it — it fixes it. The Fix with PR feature queries OSV for the complete affected version history, finds the latest release with zero known CVEs, and opens a GitHub Pull Request with the exact version bump needed. One click. Every CVE patched.

Who built Deptic

Deptic was built by Balasanjeev C, a computer science engineering student at Nandha Engnerring Collge, TamilNadu, India. What started as a final year capstone project grew into a production-grade platform after months of real engineering work — building Go scanners that call Maven Central, writing CVE resolution algorithms that cross-reference OSV.dev, and designing a UI that makes complex security data readable to non-security engineers.

The name Deptic comes from dependency + diagnostic — the core of what the product does.

Deptic is built on a modern stack: Go + Fiber for the backend API, Next.js 14 for the frontend, PostgreSQL via Supabase for persistence, Redis via Upstash for caching, and iDrive E2 (S3-compatible) for SBOM file storage. The scanner architecture supports all 8 major package ecosystems with transitive dependency resolution and PURL-based CVE matching.

Why this matters now

EO 14028
US federal mandate requiring SBOMs for all government software vendors (2021)
EU CRA
EU Cyber Resilience Act requiring SBOMs for all software sold in the EU (2024)
1 in 5
npm packages have at least one known vulnerability in their transitive tree

The regulatory window is closing. US federal agencies have begun requiring CycloneDX or SPDX SBOMs as part of procurement. The EU CRA enforcement began in 2024. Companies that cannot produce a signed, compliant SBOM on demand are losing contracts.

Deptic makes compliance the default — not an afterthought.

How it's built

Go 1.22 + Fiber
Next.js 14
PostgreSQL (Supabase)
Redis (Upstash)
iDrive E2 (S3)
OSV.dev API
GitHub OAuth
CycloneDX 1.5
SPDX 2.3
Web Push (VAPID)

The scanner core is written in Go for performance — resolving 1,000+ transitive npm dependencies takes under 30 seconds using a semaphore-controlled goroutine pool with Redis caching. The CVE matching engine sends batched parallel queries to OSV.dev, caching results by package+version with a 24-hour TTL. Every SBOM file is SHA-256 signed before being stored in object storage with pre-signed URLs that expire in 1 hour.

Get in touch

General enquiries

Security issues

For responsible disclosure of vulnerabilities in Deptic itself

Enterprise sales

Custom plans, self-hosted deployment, dedicated support