dpndncY
Why dpndncY
A self-managed alternative to SaaS application security.

dpndncY runs on your infrastructure. Findings, policy decisions, firewall verdicts, and runtime traces carry cryptographic evidence — verifiable offline with a single binary and a public key. No telemetry. No remote management. Air-gapped operation supported.

Three principles

What changes when security decisions show their work.

01

Decisions should show their work

"Severity High" is a label. The signals that produced it — EPSS with source URL, CISA KEV catalogue version, ExploitDB IDs, reachability proof, CVSS vector, policy version applied — are the evidence. Every dpndncY decision carries the full signal chain.

02

Evidence should be portable

If your customer or your auditor needs proof of a decision you made three years ago, they shouldn't have to log into your vendor's dashboard to get it. Every dpndncY decision is a DSSE envelope over a SLSA in-toto Statement, signed with your keypair. A standalone dpndncy-verify binary checks it offline.

03

Your data shouldn't leave your infrastructure

The default deployment model for AppSec tools today is "send us your code, we'll tell you what's wrong." We disagree. dpndncY runs on your infrastructure, fully air-gappable, with no telemetry. We never see your code, your dependencies, or your scan results — and we don't need to.

The order matters

Same vulnerability. Two different stories.

Where in your workflow the decision lands changes what it costs to fix. Post-scan finds the bad package after it’s already in your lockfile. Pre-install refuses it at the door — and signs the rejection.

Post-scan (legacy AppSec)
  1. 01
    Developer runs npm install on a compromised version
  2. 02
    Package lands in node_modules + lockfile
  3. 03
    CI runs scan → finds vulnerability → opens ticket
  4. 04
    Triage + assign + remediation PR + review + merge
  5. 05
    Total: hours to days
Pre-install (dpndncY)
  1. 01
    Developer runs npm install on a compromised version
  2. 02
    Firewall evaluates signals (KEV, EPSS, ExploitDB, license obligations)
  3. 03
    Install denied → standard package-manager error → signed JWS evidence emitted
  4. 04
    Developer sees rejection inline; never enters tree, never enters lockfile
  5. 05
    Total: sub-second
How dpndncY does it

Three layers. One signing root.

Scan

Multi-ecosystem SCA across 17 ecosystems, native SAST (1,500+ rules / 13+ languages), IaC (Terraform, CloudFormation, Kubernetes), high-precision secrets, container image scanning, attack-path graph, JS/TS reachability. All correlated, all prioritised by CISA KEV + EPSS + ExploitDB + reachability.

Block

Pre-install Dependency Firewall (admission-time policy on every package install) and eBPF Runtime Agent (four CO-RE BPF programs hooking connect, exec, security_file_open, getaddrinfo on your CI runners). In enforce mode, cgroup-BPF actively denies non-allowlisted egress.

Sign

Every decision — firewall verdict, scan finding, CI runtime trace — ships as a DSSE-signed SLSA in-toto Statement. Standalone dpndncy-verify binary checks signatures offline with the public key alone. Optional Sigstore-keyless when an OIDC token is available.

Run dpndncY on your infrastructure.
Read its decisions. Verify them offline.

Self-hosted, fully air-gappable, no telemetry. Every decision the platform makes is signed and verifiable with a public key.