Software supply chain security,
built for enterprise teams

dpndncY is an enterprise-grade, self-hosted software supply chain security platform. Its lead product is the Dependency Firewall — pre-install enforcement that blocks risky packages before they enter node_modules, site-packages, or your local Maven repository. Each block / allow / bypass carries a signed JWS attestation with EPSS, CISA KEV, ExploitDB, reachability, attack-path, and trust-delta evidence — verifiable offline with the public key.

The same multi-signal stack also powers full software composition analysis (SCA), static application security testing (SAST), container image scanning, IaC scanning, and secrets detection — all within your own infrastructure perimeter.

Deployable as a Docker container, a Kubernetes workload via Helm, or a Windows Server installer — no developer toolchain required on the host.

Architecture

dpndncY runs as a single containerized process backed by an embedded SQLite database. There are no external service dependencies — no Redis, no Postgres, no message queue — making deployment simple and operations lightweight.

Quick Start

The fastest path to a running instance is Docker Compose. Copy the snippet below, fill in three environment values, and you're up.

version: "3.8"
services:
  dpndncy:
    image: dpndncy/platform:2.9.0
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      JWT_SECRET: "change-to-a-long-random-string"
      ADMIN_EMAIL: "admin@yourcompany.com"
      ADMIN_PASSWORD: "change-me-on-first-login"
    volumes:
      - dpndncy_data:/app/data

volumes:
  dpndncy_data:

docker compose up -d
# Open http://dpndncy.com — log in with ADMIN_EMAIL / ADMIN_PASSWORD

See Docker deployment for production-hardened configuration, or Kubernetes + Helm for enterprise-scale deployments.

Docker Deployment

Docker Compose is the recommended deployment method for teams that want a production-ready instance without Kubernetes overhead. Requires Docker Engine 20.10+ and Docker Compose v2.

Production docker-compose.yml

version: "3.8"

services:
  dpndncy:
    image: dpndncy/platform:2.9.0
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"    # Bind to localhost; expose via reverse proxy
    environment:
      NODE_ENV: production
      JWT_SECRET: "${JWT_SECRET}"
      ADMIN_EMAIL: "${ADMIN_EMAIL}"
      ADMIN_PASSWORD: "${ADMIN_PASSWORD}"
      SESSION_DURATION: "8h"
      # GitHub integration (optional)
      GITHUB_TOKEN: "${GITHUB_TOKEN}"
      # Email notifications (optional)
      SMTP_HOST: "${SMTP_HOST}"
      SMTP_PORT: "587"
      SMTP_USER: "${SMTP_USER}"
      SMTP_PASS: "${SMTP_PASS}"
    volumes:
      - dpndncy_data:/app/data
      - dpndncy_scans:/app/data/scans    # Scan history & snapshots
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://dpndncy.com/api/health"]
      interval: 30s
      timeout: 10s
      retries: 3
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "5"

volumes:
  dpndncy_data:
  dpndncy_scans:

Store secrets in a .env file alongside the compose file (never commit it to source control):

JWT_SECRET=your-very-long-random-secret-64-chars-minimum
ADMIN_EMAIL=admin@yourcompany.com
ADMIN_PASSWORD=initial-password-change-on-first-login
GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx
SMTP_HOST=smtp.yourcompany.com
SMTP_USER=dpndncy-alerts@yourcompany.com
SMTP_PASS=your-smtp-password

Reverse proxy with nginx

In production, run dpndncY behind nginx or another reverse proxy for TLS termination:

server {
    listen 443 ssl http2;
    server_name sca.yourcompany.com;

    ssl_certificate     /etc/ssl/certs/sca.yourcompany.com.crt;
    ssl_certificate_key /etc/ssl/private/sca.yourcompany.com.key;

    location / {
        proxy_pass         http://127.0.0.1:3000;
        proxy_set_header   Host              $host;
        proxy_set_header   X-Real-IP         $remote_addr;
        proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_read_timeout 120s;
        client_max_body_size 50m;
    }
}

server {
    listen 80;
    server_name sca.yourcompany.com;
    return 301 https://$host$request_uri;
}

Starting and managing the service

# Start in background
docker compose up -d

# View logs
docker compose logs -f dpndncy

# Restart after config change
docker compose restart dpndncy

# Stop
docker compose down

# Update to a new version (data persists in named volumes)
docker compose pull
docker compose up -d

Kubernetes + Helm

The dpndncY Helm chart deploys the platform as a Kubernetes Deployment with a PersistentVolumeClaim for data, a Service, and an optional Ingress resource. Requires Kubernetes 1.24+ and Helm 3.x.

Add the Helm repository

helm repo add dpndncy https://charts.dpndncy.dev
helm repo update

Install with minimal configuration

helm install dpndncy dpndncy/dpndncy-platform \
  --namespace security \
  --create-namespace \
  --set auth.jwtSecret="your-secret-here" \
  --set admin.email="admin@yourcompany.com" \
  --set admin.password="initial-password"

Production values file

replicaCount: 2

image:
  repository: dpndncy/platform
  tag: "2.9.0"
  pullPolicy: IfNotPresent

auth:
  jwtSecret: ""           # Set via --set or secretRef
  sessionDuration: "8h"

admin:
  email: "admin@yourcompany.com"
  password: ""           # Set via --set or secretRef

persistence:
  enabled: true
  storageClass: "standard"
  size: 20Gi

service:
  type: ClusterIP
  port: 3000

ingress:
  enabled: true
  className: "nginx"
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
  hosts:
    - host: sca.yourcompany.com
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: dpndncy-tls
      hosts:
        - sca.yourcompany.com

resources:
  requests:
    memory: "512Mi"
    cpu: "250m"
  limits:
    memory: "2Gi"
    cpu: "1000m"

github:
  token: ""            # GITHUB_TOKEN — set via secretRef

smtp:
  host: "smtp.yourcompany.com"
  port: 587
  user: ""
  pass: ""

sso:
  oidcIssuer: ""
  clientId: ""
  clientSecret: ""

helm install dpndncy dpndncy/dpndncy-platform \
  --namespace security \
  --create-namespace \
  -f values-prod.yaml \
  --set auth.jwtSecret="$(openssl rand -hex 32)" \
  --set admin.password="your-initial-password"

Secrets management

For production, store sensitive values as Kubernetes Secrets and reference them via the chart's existingSecret option rather than passing them as Helm values:

kubectl create secret generic dpndncy-secrets \
  --namespace security \
  --from-literal=jwtSecret="$(openssl rand -hex 32)" \
  --from-literal=adminPassword="your-password" \
  --from-literal=githubToken="ghp_xxxx"

# In values-prod.yaml:
existingSecret: dpndncy-secrets

Upgrade

helm repo update
helm upgrade dpndncy dpndncy/dpndncy-platform \
  --namespace security \
  -f values-prod.yaml \
  --set auth.jwtSecret="existing-secret"

Windows Installer

dpndncY is available as a signed Windows installer (.exe) for deployment on Windows Server 2019 or later. The installer handles all dependencies and installs dpndncY as a Windows Service that starts automatically with the OS.

Prerequisites

• Windows Server 2019, 2022, or Windows 10/11 (64-bit)
• 4 GB RAM minimum; 8 GB recommended
• Administrator privileges for installation
• Outbound HTTPS (port 443) to OSV.dev, NVD, and GHSA for vulnerability data
• No Node.js, Python, or other runtime required — all bundled in the installer

Installation steps

Managing the Windows Service

# View service status
sc query dpndncy

# Stop / Start / Restart
net stop dpndncy
net start dpndncy

# Or via Services MMC (services.msc) — look for "dpndncY Platform"

Post-install configuration

After installation, edit the configuration file at C:\ProgramData\dpndncY\config.env to add integration credentials (GitHub token, SMTP settings, OIDC, etc.), then restart the service.

# C:\ProgramData\dpndncY\config.env
GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx
SMTP_HOST=smtp.yourcompany.com
SMTP_PORT=587
SMTP_USER=dpndncy@yourcompany.com
SMTP_PASS=your-smtp-password
SLACK_WEBHOOK_URL=https://hooks.slack.com/services/xxx

Uninstallation

Use Control Panel → Programs → Uninstall a program → dpndncY. The uninstaller removes the service and binaries. The data directory (C:\ProgramData\dpndncY) is preserved — delete it manually if you want to remove all data.

Upgrade

Run the new version's installer over the existing installation. The installer detects the previous version, stops the service, updates the binaries, and restarts — your data and configuration are preserved.

System Requirements

Configuration Reference

Configuration is provided via environment variables. In Docker deployments, set them in docker-compose.yml or a .env file. In Kubernetes, use Helm values or a Secret. In the Windows installer, edit C:\ProgramData\dpndncY\config.env.

Core

Admin account

SAST engine tuning

Email (SMTP)

Integrations

First-Time Setup

Dependency Firewall

The Dependency Firewall is dpndncY's pre-install enforcement layer. It evaluates every {ecosystem, name, version} request against vulnerability data, exploitability signals, trust score, license policy, and tenant-specific rules — and returns an allow / block / review decision before the package ever lands in node_modules, site-packages, or your local Maven repository.

Why pre-install

Post-scan SCA tools (Snyk, Black Duck, Dependabot) tell you what's wrong after a vulnerable package is already in your tree. The firewall stops the install in the first place. The same multi-signal exploitability stack that powers dpndncY's prioritization — CISA KEV, EPSS, ExploitDB, JS/TS reachability, attack-path graphs, trust score, license obligations — is applied at install time, not after.

Decision evidence (signed)

Every decision the firewall makes carries a JSON Web Signature (JWS) attestation containing:

• The decision and rationale (Patch Now / Patch This Sprint / Monitor / Accept Risk / Block / Allow)
• Each signal value with its source: EPSS score and snapshot URL, CISA KEV catalog version, ExploitDB entry IDs, reachability proofs (file:line of vulnerable function calls), CVSS vector and score
• The trust score and trust delta vs. the previously approved version
• The policy ID and version that was applied
• Scan ID, project ID, tenant ID, and timestamp

Attestations are signed with the dpndncY licensing keypair. Any party with the public key can verify the bundle offline — auditors, CI pipelines storing build artifacts, downstream customers proving supply-chain hygiene.

Modes

• Enforce — block requests that violate policy. Bypass requires a signed waiver.
• Soak / monitor-only — log every decision without blocking, for a configurable rollout phase.
• Review — route ambiguous decisions to a human approver with full evidence attached.

Trust-delta gating

Beyond absolute thresholds, the firewall flags any package whose trust score has dropped relative to the previously approved version — catching typosquats, package takeovers, and maintainer rotations that absolute thresholds miss.

Bypass and audit

Bypassing the firewall always requires one of: a human approver, a policy waiver with an expiry date, or an emergency token. Every bypass attempt is itself audited and signed — even bypassed installs leave an evidence trail.

Engine

The firewall engine ships in src/firewall/: evaluator.js (decision logic), packageRequest.js (request normalization), policy.js (policy evaluation), safeVersions.js (allowed-version resolution). The registry-proxy layer for transparent enforcement at the package-manager level (npm, PyPI, Maven Central, NuGet, RubyGems, Crates.io, proxy.golang.org) is in active build-out.

SCA Scanning

Software Composition Analysis (SCA) scans dependency manifests, resolves the full dependency tree, and checks each package against multiple vulnerability databases. Results are enriched with real-world exploitability signals to help teams prioritize what actually matters.

How it works

1. dpndncY traverses the target directory for supported manifest and lock files
2. Dependency trees are parsed — direct and transitive dependencies at exact resolved versions
3. Package identifiers are queried against OSV, NVD, GHSA, CISA KEV, and EPSS
4. Findings are enriched with CVSS scores, EPSS probability, KEV status, and ExploitDB references
5. A composite risk score is computed per vulnerability combining all signals
6. Results are stored and surfaced in the UI with remediation guidance and upgrade paths

Supported Ecosystems (17)

17 dedicated ecosystem scanners plus a generic fallback. Both the Dependency Firewall and post-scan SCA share the same parser stack — one source of truth.

Vulnerability Sources

SAST Scanning

The dpndncY SAST engine performs static analysis on your source code using three parallel analyzers. 404 rules across 13+ languages. No external SAST tool installation is required — all analysis runs inside the container.

Starting a SAST scan via API

POST /api/sast/scan
Authorization: Bearer <token>
Content-Type: application/json

{
  "repoPath": "/mnt/repos/myapp",
  "branch": "feature/payment-refactor",
  "baseBranch": "main",
  "deltaOnly": true
}

Scans run asynchronously. Poll the run status:

GET /api/sast/runs/:runId
# status: "pending" | "running" | "completed" | "failed"

Supported Languages

Rule Engine

Each rule defines an id, severity (CRITICAL HIGH MEDIUM LOW), confidence (HIGH for taint-confirmed, MEDIUM for pattern-matched), associated CWEs, and remediation guidance.

CWE identifiers in SAST findings are correlated with CVEs in SCA results to compute Attack Path boosts — a SAST finding in the same package as a CVE with a matching CWE scores 1.3× higher.

Suppressing findings

POST /api/sast/runs/:runId/suppress
Authorization: Bearer <token>

{
  "findingId": "uuid",
  "reason": "False positive — input validated by middleware"
}

Suppressed findings remain in the audit log but are excluded from policy evaluation and dashboard counts.

Attack Path Graph

The Attack Path Graph maps how an attacker could move from a vulnerable dependency through your codebase to a reachable entry point. It combines SCA vulnerability data with SAST code findings and import resolution to produce scored, prioritized attack chains.

Path score formula

score = depRiskScore × reachabilityWeight × sinkWeight × aiAmplification × cweBoost

  depRiskScore      → CVSS + EPSS composite (0–10)
  reachabilityWeight → 1.0 imported / 1.3 called directly
  sinkWeight        → 1.5 SQL/exec, 1.3 path/SSRF, 1.0 log
  aiAmplification   → 1.0–1.2 based on AI risk context
  cweBoost          → 1.3× when SAST CWE matches CVE CWE

Range: [0, 2.0]

API

GET /api/scans/:id/attack-graph       # Full graph (nodes + edges)
GET /api/scans/:id/attack-path/:pathId # Path detail + narrative explanation

Container Image Scanning

dpndncY parses Docker-save tarballs and extracts the dependency manifest from each image layer across 9 ecosystems. Live registry pull (Docker Hub, ECR, GCR, Quay) is in active build-out.

Supported per-layer ecosystems

• OS packages: Debian (/var/lib/dpkg/status), Alpine (/lib/apk/db/installed), RPM (/var/lib/rpm/Packages)
• Application packages per layer: npm, PyPI, Go modules, RubyGems, PHP Composer, Rust Cargo, .NET
• Dockerfile linting: when present in the tarball
• Secrets scanning: optional secret scan across layer files using the same 731-rule scanner

API

POST /api/scan/container
Authorization: Bearer <token>
Content-Type: multipart/form-data

# Body:
#   image=<docker-save-tarball.tar>
#   imageRef=docker.io/library/nginx:1.27 (optional metadata)

Infrastructure-as-Code (IaC) Scanning

IaC scanning runs as part of the SAST workflow. Detects security misconfigurations across Terraform, CloudFormation (JSON + YAML), and Kubernetes manifests.

Non-IaC JSON (package.json, tsconfig.json, etc.) is excluded from CloudFormation rule matching.

Secrets Detection

731-rule scanner runs alongside SCA and SAST. Detects credentials and tokens across all source files and configuration formats.

• Cloud provider keys: AWS access keys, GCP service account JSON, Azure connection strings
• SCM tokens: GitHub PAT (github_pat_*, ghp_*), GitLab tokens, Bitbucket app passwords
• API keys: OpenAI (sk-*), Anthropic (sk-ant-*), Stripe, SendGrid, Mailgun, Twilio
• Cryptographic material: PEM private keys (RSA / EC / OpenSSH / PGP), JWT bearer tokens
• Database connection strings: PostgreSQL, MySQL, MongoDB, Redis URIs with embedded credentials
• Inline suppression: same comment markers as SAST

Decision Engine & Signed Evidence

Every vulnerability gets a prioritized decision and SLA. Every decision — firewall block, Patch-Now triage, Accept-Risk — produces a signed JWS attestation.

Decision matrix

Signed JWS attestation

Each decision produces a JSON Web Signature bundle containing:

{
  "decision": "Patch Now",
  "urgency": "critical",
  "slaHours": 48,
  "rationale": [
    "Listed in CISA Known Exploited Vulnerabilities catalog",
    "EPSS score 0.912 indicates very high exploitation probability",
    "Reachable: minimist.parse() used in src/server.js, src/config.js"
  ],
  "evidence": {
    "epss": { "value": 0.912, "source": "https://api.first.org/data/v1/epss?cve=CVE-XXXX-XXXX", "fetched_at": "2026-04-28T14:30:00Z" },
    "kev":  { "catalog_version": "2026-04-27", "listed_at": "2026-03-15" },
    "exploitDb": [{ "edb_id": "51234", "url": "https://www.exploit-db.com/exploits/51234" }],
    "reachability": [{ "function": "minimist.parse", "file": "src/server.js", "line": 42 }],
    "cvss": { "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "score": 9.8 }
  },
  "policy": { "id": "policy_pci_dss_default", "version": 7 },
  "trustDelta": -28,
  "scan_id": "...", "project_id": "...", "tenant_id": "...",
  "timestamp": "2026-04-28T14:30:42Z"
}

Signed with the dpndncY licensing keypair. Verify offline with the public key — auditors, downstream customers, CI pipelines storing build artifacts.

Trust Engine & Patch Guidance

Every package gets a 0–100 trust score derived from explainable factors. The score also drives the firewall's trust-delta gating — alerts when a version's score drops vs. the last approved version (catches typosquats, takeovers, and maintainer rotations).

Factors

• Maintainer count and historical activity
• Release cadence (stale packages flagged; flash-flood new packages flagged)
• Install-script presence and risk class
• License clarity (declared vs. inferred vs. unknown)
• Vulnerability history (count and recency)
• Anomaly index (e.g., new package + install scripts + no maintainer history)
• Coverage confidence (how much metadata was available to score against)

Patch guidance

For each package the trust engine emits a recommended target version with semver delta classification (patch / minor / major), the earliest non-vulnerable target, and tie-broken alternatives. This drives auto-fix PR generation.

Auto-Fix Pull Requests

Open pull requests on GitHub, GitLab, and self-hosted instances with version bumps, lockfile regeneration, and breaking-change analysis attached.

Coverage

Breaking-change analysis

Pre-flight diff between current and target version surfaces removed exports, signature changes, and major version bumps. The PR description includes the breaking-change summary so reviewers see the surface area before merging.

Platform support

• GitHub.com and self-hosted GitHub Enterprise Server
• GitLab.com and self-hosted GitLab CE/EE
• Bitbucket Cloud (early)

License Compliance & Obligations

Beyond allow/deny: surfaces the actual obligations triggered by each license — what your legal team needs to do, not just what's blocked.

• SPDX-aligned license normalization
• Obligation graph: attribution, source disclosure, copyleft scope (file / module / derivative work), patent grant, NOTICE file requirements, modifications statement
• Conflict detection: GPL + proprietary, AGPL + SaaS, copyleft + closed-source distribution
• License-cache for offline / air-gapped lookups
• Pre-install firewall enforcement: block GPL contamination before it lands in the tree

Dependency Health Scoring

Per-package health score independent of CVE status — future risk indicators, not just known vulnerabilities. Surfaces low-health packages before they get a CVE.

• Maintainer count, activity, response time
• Release cadence and last-release recency
• License clarity
• Anomaly signals (e.g., sudden ownership transfer, recent install-script addition)
• Historical vulnerability density

Notifications

Native formatting per platform — auto-detected by webhook hostname.

Triggers: new findings, policy failures, firewall blocks, scan completion, license violations, trust-delta drops.

Jira & Linear Ticketing

Native API integrations for Jira (cloud and self-hosted Data Center) and Linear. Auto-create tickets from findings or firewall events; round-trip status sync back to dpndncY.

• Per-tenant config: project key, issue type, default assignee, priority mapping
• Bulk-create tickets from a filtered finding view
• Ticket includes severity, evidence bundle link, remediation guidance, and the signed JWS attestation
• Two-way sync: closing the ticket marks the finding as remediated in dpndncY

Policy Engine

Define security policies to gate CI/CD pipelines. Policies evaluate findings against thresholds, blocked rules, and EPSS minimums. A failed policy returns a non-zero exit code that fails the build.

Policy configuration

{
  "thresholds": {
    "critical": 0,     // fail if any CRITICAL findings
    "high": 3,
    "medium": null,    // null = no limit
    "low": null
  },
  "blockedRules": [
    "JS-TAINT-SQL-001",
    "PY-EXEC-001"
  ],
  "deltaOnly": true,   // only evaluate findings in changed lines (PR gate)
  "minEpss": 0.4       // only count vulns with EPSS ≥ 0.4
}

Policy evaluation

POST /api/sast/policy/evaluate
{
  "runId": "uuid",
  "policy": { ... }
}

# Response:
{
  "passed": false,
  "violations": [
    { "rule": "critical threshold", "found": 2, "limit": 0 }
  ]
}

SBOM & Export

Scan History & Trends

Each completed scan saves a snapshot. The trend engine compares consecutive snapshots to compute a risk delta: new findings, resolved findings, and change in composite risk score. Trend data powers the dashboard timeline chart.

GET /api/scans/:id/history   # List historical snapshots for a project
GET /api/scans/:id/trend     # Risk delta between last 2 snapshots

AI Risk Detection

dpndncY flags AI/ML-specific security risks in addition to standard vulnerabilities:

• Model loading via insecure deserialization (pickle, unsafe torch.load)
• LLM prompt injection surface in AI framework integrations
• Model supply chain risks: packages that download models from unverified registries at runtime
• Training data exposure via logging, serialization, or external API calls

Authentication

Creating a PAT

Via UI: Profile → API Tokens → Create Token

POST /api/tokens
Authorization: Bearer <session-token>
{ "name": "GitHub Actions", "expiresIn": "365d" }

# Save the returned token value — shown only once

API Reference

Base URL: https://sca.yourcompany.com. All endpoints require Authorization: Bearer <token> unless noted.

Scans (SCA)

{ "repoPath": "/path/or/git-url", "branch": "main", "label": "optional" }

SAST

{ "repoPath": "/path", "branch": "feat/x", "baseBranch": "main", "deltaOnly": true }

Packages (VS Code / quick check)

{ "packages": [{ "name": "lodash", "version": "4.17.15", "ecosystem": "npm" }] }

Tokens

CI/CD Integration

Use a Personal API Token to add dpndncY security gates to your pipeline. The typical pattern: scan → poll until complete → evaluate policy → fail build on violation.

GitHub Actions

name: Security Gate

on: [push, pull_request]

jobs:
  dpndncy-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: SCA Scan
        id: sca
        run: |
          RESULT=$(curl -sf -X POST $DPNDNCY_URL/api/scans \
            -H "Authorization: Bearer ${{ secrets.DPNDNCY_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d '{"repoPath":"${{ github.workspace }}","branch":"${{ github.ref_name }}"}')
          echo "scan_id=$(echo $RESULT | jq -r .id)" >> $GITHUB_OUTPUT
        env:
          DPNDNCY_URL: ${{ secrets.DPNDNCY_URL }}

      - name: SAST Scan
        id: sast
        run: |
          RESULT=$(curl -sf -X POST $DPNDNCY_URL/api/sast/scan \
            -H "Authorization: Bearer ${{ secrets.DPNDNCY_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d '{"repoPath":"${{ github.workspace }}","branch":"${{ github.ref_name }}","baseBranch":"main","deltaOnly":true}')
          RUN_ID=$(echo $RESULT | jq -r .runId)
          # Poll until complete
          for i in $(seq 1 30); do
            STATUS=$(curl -sf $DPNDNCY_URL/api/sast/runs/$RUN_ID \
              -H "Authorization: Bearer ${{ secrets.DPNDNCY_TOKEN }}" | jq -r .status)
            [ "$STATUS" = "completed" ] && break
            sleep 10
          done
          echo "run_id=$RUN_ID" >> $GITHUB_OUTPUT
        env:
          DPNDNCY_URL: ${{ secrets.DPNDNCY_URL }}

      - name: Policy Gate
        run: |
          POLICY='{"thresholds":{"critical":0,"high":5},"deltaOnly":true}'
          RESULT=$(curl -sf -X POST $DPNDNCY_URL/api/sast/policy/evaluate \
            -H "Authorization: Bearer ${{ secrets.DPNDNCY_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d "{\"runId\":\"${{ steps.sast.outputs.run_id }}\",\"policy\":$POLICY}")
          echo $RESULT | jq .
          echo $RESULT | jq -e '.passed == true'
        env:
          DPNDNCY_URL: ${{ secrets.DPNDNCY_URL }}

GitLab CI

security-scan:
  stage: test
  image: curlimages/curl:latest
  script:
    - |
      SCAN=$(curl -sf -X POST $DPNDNCY_URL/api/scans \
        -H "Authorization: Bearer $DPNDNCY_TOKEN" \
        -H "Content-Type: application/json" \
        -d "{\"repoPath\":\"$CI_PROJECT_DIR\",\"branch\":\"$CI_COMMIT_REF_NAME\"}")
      SCAN_ID=$(echo $SCAN | grep -o '"id":"[^"]*"' | cut -d'"' -f4)

      SAST=$(curl -sf -X POST $DPNDNCY_URL/api/sast/scan \
        -H "Authorization: Bearer $DPNDNCY_TOKEN" \
        -H "Content-Type: application/json" \
        -d "{\"repoPath\":\"$CI_PROJECT_DIR\",\"branch\":\"$CI_COMMIT_REF_NAME\",\"deltaOnly\":true}")
      RUN_ID=$(echo $SAST | grep -o '"runId":"[^"]*"' | cut -d'"' -f4)

      for i in $(seq 1 30); do
        STATUS=$(curl -sf $DPNDNCY_URL/api/sast/runs/$RUN_ID \
          -H "Authorization: Bearer $DPNDNCY_TOKEN" | grep -o '"status":"[^"]*"' | cut -d'"' -f4)
        [ "$STATUS" = "completed" ] && break
        sleep 10
      done

      POLICY_RESULT=$(curl -sf -X POST $DPNDNCY_URL/api/sast/policy/evaluate \
        -H "Authorization: Bearer $DPNDNCY_TOKEN" \
        -H "Content-Type: application/json" \
        -d "{\"runId\":\"$RUN_ID\",\"policy\":{\"thresholds\":{\"critical\":0},\"deltaOnly\":true}}")
      echo $POLICY_RESULT | grep -q '"passed":true' || (echo "Security policy failed" && exit 1)
  variables:
    DPNDNCY_URL: https://sca.yourcompany.com

CLI Tool — Overview & Installation

The dpndncY CLI is a single standalone binary — no Node.js or runtime required on the machine running it. Download, configure once with your server URL and API token, then scan any local path, Git repo, zip archive, or container image from the terminal.

Windows setup

# 1. Download from GitHub Releases
#    https://github.com/dpndncy/cli/releases/latest

# 2. (Optional) Add to PATH so 'dpndncy' works from any directory
#    Copy dpndncy-win.exe to C:\Windows\System32\dpndncy.exe
#    or add the folder to your PATH environment variable

# 3. Configure your server
dpndncy login --server https://sca.yourcompany.com --token dpat_your_token_here

# 4. Verify connection
dpndncy status

Linux / macOS setup

# Download (Linux example)
curl -L https://github.com/dpndncy/cli/releases/latest/download/dpndncy-linux -o dpndncy
chmod +x dpndncy
sudo mv dpndncy /usr/local/bin/

# Configure
dpndncy login --server https://sca.yourcompany.com --token dpat_your_token_here

# Verify
dpndncy status

Credentials file

dpndncy login saves your server URL and token to ~/.dpndncy/config.json so you don't need to pass them on every scan. You can override them per-command with --server and --token.

Scan Command Reference

The main command. Run a security scan against a local path, repository, archive, or container image — all engines optional, all combinable.

dpndncy scan [path] [flags]

Scan engines

Scan targets

Output options

Exit codes

Examples

# SCA-only scan on current directory (default)
dpndncy scan .

# Full scan — all engines
dpndncy scan --all /path/to/project

# SCA + SAST + Secrets
dpndncy scan --sca --sast --secrets .

# Scan a zip archive
dpndncy scan --zip build/app.jar

# Scan a GitHub repo
dpndncy scan --repo https://github.com/org/repo --sca --sast

# Scan a container image from registry
dpndncy scan --image nginx:latest

# CI mode — fails build on policy violation
dpndncy scan --ci --sca . && echo "Build OK"

# Output JSON to file
dpndncy scan --sca --json --output results.json .

Login & Status Commands

dpndncy login

Save your server URL and API token. Stored in ~/.dpndncy/config.json. Only needs to be run once per machine.

dpndncy login --server https://sca.yourcompany.com --token dpat_xxxxxxxxxxxxxxxx

Generate your token in the dpndncY web UI under Profile → API Tokens. Token format is dpat_ followed by a random string.

dpndncy status

Checks connectivity to your configured server and prints server version, auth status, and queue depth.

dpndncy status

# Or override the server for a one-off check
dpndncy status --server https://sca.yourcompany.com --token dpat_...

CI/CD with the CLI

The --ci flag enables minimal output mode and makes the CLI return exit code 1 on policy violations — perfect for pipeline gates. Store your server URL and token as CI secrets, then download the CLI binary in your pipeline.

GitHub Actions — using the CLI

name: Security Gate

on:
  push:
    branches: [main, develop]
  pull_request:

jobs:
  dpndncy-scan:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Download dpndncY CLI
        run: |
          curl -sSL https://github.com/dpndncy/cli/releases/latest/download/dpndncy-linux \
            -o /usr/local/bin/dpndncy
          chmod +x /usr/local/bin/dpndncy

      - name: Configure dpndncY
        run: dpndncy login --server ${{ secrets.DPNDNCY_URL }} --token ${{ secrets.DPNDNCY_TOKEN }}

      - name: Run security scan
        run: dpndncy scan --ci --sca --sast .
        # Exit 0 = passed, Exit 1 = policy fail (fails the build), Exit 2 = error

GitLab CI — using the CLI

security-scan:
  stage: test
  image: ubuntu:22.04
  before_script:
    - apt-get update -q && apt-get install -yq curl
    - curl -sSL https://github.com/dpndncy/cli/releases/latest/download/dpndncy-linux
        -o /usr/local/bin/dpndncy
    - chmod +x /usr/local/bin/dpndncy
    - dpndncy login --server $DPNDNCY_URL --token $DPNDNCY_TOKEN
  script:
    - dpndncy scan --ci --sca --sast $CI_PROJECT_DIR
  variables:
    DPNDNCY_URL: https://sca.yourcompany.com

Jenkins Pipeline — using the CLI

pipeline {
  agent any
  environment {
    DPNDNCY_URL   = credentials('dpndncy-url')
    DPNDNCY_TOKEN = credentials('dpndncy-token')
  }
  stages {
    stage('Security Scan') {
      steps {
        sh '''
          curl -sSL https://github.com/dpndncy/cli/releases/latest/download/dpndncy-linux \
            -o /tmp/dpndncy && chmod +x /tmp/dpndncy
          /tmp/dpndncy login --server $DPNDNCY_URL --token $DPNDNCY_TOKEN
          /tmp/dpndncy scan --ci --sca --sast .
        '''
      }
    }
  }
}

Windows CI (PowerShell / Azure DevOps)

- task: PowerShell@2
  displayName: 'dpndncY Security Scan'
  inputs:
    targetType: inline
    script: |
      $url = "https://github.com/dpndncy/cli/releases/latest/download/dpndncy-win.exe"
      Invoke-WebRequest -Uri $url -OutFile "dpndncy.exe"
      .\dpndncy.exe login --server $env:DPNDNCY_URL --token $env:DPNDNCY_TOKEN
      .\dpndncy.exe scan --ci --sca .
  env:
    DPNDNCY_URL: $(dpndncyUrl)
    DPNDNCY_TOKEN: $(dpndncyToken)

GitHub Integration

Connect dpndncY to GitHub to browse repositories and open automated remediation pull requests for vulnerable dependencies.

Setup

1. Create a GitHub Personal Access Token with repo scope (or a fine-grained token with read/write on contents and pull requests)
2. Set GITHUB_TOKEN in your configuration and restart the service
3. Verify the connection: Settings → Integrations → GitHub

Remediation PRs

From any scan result, select affected packages and click Open Remediation PR. dpndncY creates a branch, bumps the vulnerable dependency to the patched version in the manifest and lock file, and opens a PR with full CVE context in the description.

GitLab Integration

Same capabilities as GitHub: repository browsing and automated Merge Requests for vulnerability remediation.

Setup

1. Create a GitLab Personal Access Token with api scope
2. Set GITLAB_TOKEN (and GITLAB_URL for self-hosted instances) in configuration
3. Restart the service

VS Code Extension

The dpndncY VS Code extension shows vulnerability data inline in your manifest files. Vulnerable packages are underlined with severity indicators — hover for CVE detail, CVSS score, and recommended fix version.

Installation

1. Download dpndncy-security-*.vsix from your dpndncY instance: Settings → VS Code Extension
2. In VS Code: Extensions → ⋯ → Install from VSIX…

Settings

Notifications

SSO / OIDC

dpndncY supports OIDC-based SSO with Okta, Azure AD, Auth0, and any OIDC-compliant identity provider. Users are provisioned automatically on first login. Role assignment is controlled via OIDC group claims.

OIDC_ISSUER=https://yourorg.okta.com/oauth2/default
OIDC_CLIENT_ID=0oa1b2c3d4e5
OIDC_CLIENT_SECRET=your-client-secret
OIDC_CALLBACK_URL=https://sca.yourcompany.com/auth/oidc/callback

When configured, a Sign in with SSO button appears on the login page. Password-based login for local accounts can be disabled from Settings → Authentication.

User Management

Manage users at Settings → Users or via API:

POST /api/admin/users
Authorization: Bearer <admin-token>
{ "email": "engineer@yourcompany.com", "role": "viewer" }

API Tokens (PAT)

• Tokens are scoped to the permissions of the creating user
• The token value is shown once only — store it immediately in your secrets manager
• Create separate tokens per integration (CI, VS Code, monitoring) for independent revocation
• Revocation is instant — use Profile → API Tokens or DELETE /api/tokens/:id
• Audit token usage from Settings → Audit Log

Backup & Restore

All persistent state is in the SQLite database and the scan snapshot directory. Both live on the data volume.

Docker backup

# Backup the data volume to a tar archive
docker run --rm \
  -v dpndncy_data:/data \
  -v $(pwd)/backups:/backups \
  alpine tar czf /backups/dpndncy-$(date +%Y%m%d).tar.gz /data

# Restore
docker run --rm \
  -v dpndncy_data:/data \
  -v $(pwd)/backups:/backups \
  alpine tar xzf /backups/dpndncy-20260309.tar.gz -C /

Kubernetes backup

Backup the PVC using your cluster's volume snapshot mechanism (e.g., Velero, CSI snapshots):

velero backup create dpndncy-backup \
  --include-namespaces security \
  --wait

Windows backup

Stop the service, copy C:\ProgramData\dpndncY\ to a backup location, then restart:

net stop dpndncy
robocopy "C:\ProgramData\dpndncY" "D:\Backups\dpndncy-%date%" /E /COPYALL
net start dpndncy

Upgrades

dpndncY applies database migrations automatically on startup. Always back up your data before upgrading.

Docker

# Pull the new image and recreate the container (data volume is preserved)
docker compose pull
docker compose up -d

Kubernetes

helm repo update
helm upgrade dpndncy dpndncy/dpndncy-platform \
  --namespace security \
  -f values-prod.yaml

Windows

Run the new version's .exe installer over the existing installation. The installer handles the service stop/start and data migration automatically.

Troubleshooting

Container won't start

• Check that JWT_SECRET is set and non-empty
• Verify the data volume is mounted and writable by the container process
• Check logs: docker compose logs dpndncy

Scans return no findings

• Verify the target path is mounted into the container and accessible
• Check that a supported manifest file exists in the target directory
• Ensure outbound HTTPS to api.osv.dev and services.nvd.nist.gov is allowed by your firewall/proxy

SAST scan times out

• Increase SAST_MAX_RUNTIME_SEC (e.g. 600 for large monorepos)
• Use deltaOnly: true to limit analysis to changed files
• Ensure the container has sufficient CPU — SAST is CPU-bound

SSO / OIDC login fails

• Verify OIDC_CALLBACK_URL matches exactly what's registered in your IdP (including trailing slash if any)
• Check that the dpndncY instance is reachable at the callback URL from the browser, not just from the server
• Review the server log for the OIDC error response detail

Windows Service won't start

• Check the Windows Event Viewer: Application → dpndncY
• Verify the service account has read/write access to C:\ProgramData\dpndncY
• Check that the configured port is not in use by another process: netstat -ano | findstr :3000

Viewing logs

# Docker
docker compose logs -f dpndncy

# Kubernetes
kubectl logs -n security -l app=dpndncy -f

# Windows
Get-EventLog -LogName Application -Source dpndncY -Newest 100