Stackurity

Stackurity

Open-source, self-hosted software inventory and upgrade intelligence. Stackurity discovers software across hosts, repositories, containers and SBOMs, keeps one inventory with evidence for every component, and shows clearly what was not checked.

Status: an early release under active development; see the latest release and the changelog. Inventory, intelligence, alerts and team workflow, stack packs, Kubernetes, Jira and workspaces are in Community; see the known limitations below and editions for what Pro and Enterprise add.

What it does today

• Hosts: a read-only, unprivileged agent for Linux (dpkg, rpm and apk) and Windows (registry). On Linux it also finds runtimes and servers installed outside the package manager (Node.js from nvm, downloaded database binaries) and flags hosts that need a reboot to run patched code. It can also read the libraries deployed applications actually have installed (node_modules, Python virtualenvs, Composer vendor, and front-end libraries loaded from a CDN or copied into a site), so each application appears with its host, web server, runtime and repository in one stack view. With --docker (opt-in) it also reads the images of the host's running Docker containers, locally built ones included, without running anything in them (details).
• Repositories: npm, yarn, pnpm, Composer, Poetry, Pipenv, pip (pinned), Go modules, Bundler, NuGet and Dart/Flutter pub, including direct and transitive dependencies. More technologies come as stack packs: signed, sandboxed WebAssembly readers an administrator installs when their estate needs them, such as Java (Maven and Gradle) and Rust (Cargo). Scans run server-side from Git or in CI, where they can fail the pipeline on a severity, priority or known exploitation threshold. Lockfiles are parsed as data and nothing is executed.
• Managed cloud services: AWS RDS, Aurora, ElastiCache, EKS, Lambda and OpenSearch versions through a read-only plugin, with lifecycle tracking.
• Kubernetes: connected with one command (a Helm chart or kubectl apply) that runs a small read-only reporter in the cluster, which pushes to Stackurity over HTTPS (or a plugin that pulls from the API server). It maps which workloads run which images (by the digest the node pulled), which workloads are exposed outside the cluster (LoadBalancer, NodePort, Ingress, host networking), and the control plane, kubelet, runtime and node OS versions for lifecycle. Running images are scanned with the bundled Syft, and exposure feeds risk scoring. Namespaces it cannot read and images it cannot pull show as not assessed. See docs/kubernetes.md.
• Leaked keys: keys, tokens and passwords written into files (private keys, AWS, GitHub, Stripe, OpenAI, Anthropic, SendGrid and other API keys, database passwords), found by the agent in deployed applications, by stackurity scan in CI and in repositories the server clones. The value never leaves the machine: a leak is reported by file, line, fingerprint and a masked preview. On servers, what decides urgency is exposure: a .env or config.php.bak the web server would send to anyone is critical, a password in its own configuration file is only listed. See docs/leaked-keys.md.
• Plugins: a public, language-agnostic plugin contract with a conformance checker. See docs/plugins.md.
• Container images: inventory from a registry reference through the bundled Syft. No Docker daemon is needed.
• SBOMs: CycloneDX and SPDX JSON import, CycloneDX 1.6 export.
• VEX: OpenVEX and CycloneDX VEX import (standalone, embedded in an SBOM, or as a signed attestation), matched to components by package URL, image digest or CPE; a not_affected statement hides a finding only after a security user approves it or a source pinned to a key or token applies it, and stops applying when the version or image changes. Decisions (false positives, mitigations, imported statements) export as OpenVEX or CycloneDX VEX. See docs/vex.md.
• Vulnerability intelligence: OSV data for npm, Packagist, PyPI, Go, Maven, RubyGems, crates.io, NuGet, Pub, Debian, Ubuntu, Alpine, Rocky, Alma, Red Hat Enterprise Linux, SUSE Linux Enterprise and openSUSE Leap, and Amazon's own advisories (ALAS) for Amazon Linux 2 and 2023. Versions are compared by each ecosystem's own rules, so distro backports are handled. CVSS v3 and v4 vectors are scored locally (v4 as the FIRST reference calculator does). Advisories are deduplicated across sources, CISA KEV flags known exploitation, FIRST EPSS predicts it, and refresh is hourly and incremental.
• Versions and lifecycle: latest stable releases from npm, Packagist, PyPI, Go modules, crates.io, RubyGems, NuGet, Maven Central and pub.dev (patch, minor or major, plus deprecated packages and yanked, retracted or unlisted versions), and end-of-life data from endoflife.date for operating systems, runtimes and frameworks.
• Upgrade recommendations: for each installed component with open findings, the minimum fixed version, the version to move to (the newest stable release in the same major line that fixes every open finding, or the distribution's fixed build for OS packages), whether it is a major upgrade, withdrawn versions and release-line support, with the reasons. Built only from stored data; missing data is reported as missing.
• One inventory: stable asset identities, conflict detection and merging, and relations between assets. Every component carries its source, timestamp, confidence and evidence.
• Global search: type a CVE or advisory id, a package with or without a version, a hostname, image digest or repository URL, a team, words from a finding's title or a workspace member, and land on the affected assets, components and findings.
• Coverage ledger: unsupported, skipped, failed, partial and stale areas are shown separately from healthy coverage. They are never treated as healthy.
• Risk-based alerting: configurable P1–P4 priority with explained factors (KEV, EPSS, exposure, production, criticality, fix availability, confidence), SOS rules that never rely on severity alone, and incidents that group findings so one CVE on fifty servers is one alert. docs/risk.md explains how priorities are decided, what happens when evidence is missing, and the scenarios and invariants the scoring is tested against.
• Team workflow: acknowledge, assign, risk acceptance (security role, with a reason, an expiry capped by policy, and the mitigation in place) and deadlines, with full history. Several teams with routing by team and escalation of overdue issues are part of Pro.
• Remediation outcomes: time to remedy by priority, SLA compliance against the risk policy, findings resolved by a fresh inventory versus by changed advisory data, findings that came back after being resolved, and remediation success, failures and rollbacks, always with the counts behind each rate.
• Evidence (Pro): a periodic patch-management report for audits and security questionnaires: coverage, open and overdue findings, time to resolve, active exceptions and replica drift.
• AI assistants: with STACKURITY_BASE_URL set to the server's public https:// address, paste https:// /mcp into Claude, ChatGPT or any assistant that supports remote MCP servers and sign in, nothing to install. Assistants can ask what is vulnerable, why it has its priority, which version to upgrade to, and whether a change fixed it, with cited ids and sources, and, if you allow changes, create projects, add servers, assign, snooze or ignore issues and check fixes again (docs/ai-assistants.md).
• Notifications: email, Slack, Microsoft Teams and signed webhooks: a few messages that bring people to the dashboard (urgent issues right away, grouped per asset and fix; a daily or weekly summary; a quiet "connected" message for a new server's first scan), with routing by priority, team and environment, quiet hours, hourly limits, retries and a delivery log. Feed, collector and coverage failures alert too.
• Jira: one issue per incident in Jira Cloud or Data Center, kept up to date as findings join and priority changes, commented on and optionally transitioned when the incident resolves, and linked from the dashboard.
• Controlled remediation (Pro): opt-in, policy-scoped upgrades with approval gates, maintenance windows, canary then staged rollout, verification against freshly collected inventory and health checks, and halt-on-failure with best-effort rollback where the package manager supports it. Hosts are enrolled one at a time with a bound token and a local allowlist. Repositories get Renovate pull requests, so code review stays in place. See docs/remediation.md.
• Workspaces: one installation can serve several organisations, kept apart by PostgreSQL row-level security as well as by the application.
• Dashboard, API and CLI: role-based access (viewer, engineer, security, admin, collector), API tokens, a full audit log and single sign-on (Pro).

Quick start

Stackurity is self-hosted: your inventory and findings stay on your own server, and your hosts and pipelines send data to it. Nothing needs inbound access to your machines.

If you would rather not run a server, Stackurity Cloud runs the same release for you at app.stackurity.dev: sign up for a 14-day free trial, no card needed, then choose a plan. Self-hosting the Community edition stays free, with no account and no asset limit; nothing below needs Stackurity Cloud.

There are two ways to run it. Both keep the session cookie Secure, as production does: Chrome, Edge and Firefox treat http://localhost as a secure origin, so a trial on your own machine needs no security setting changed.

Try it on your own machine

1. Run the server (Docker Compose):

git clone https://github.com/stackurity/stackurity.git

cd stackurity/deploy ./init-secrets.sh docker compose up -d # pulls the signed ghcr.io/stackurity/stackurity image; add --build to build from source docker compose logs stackurity | grep -A2 "one-time token"

Open http://localhost:8080 in Chrome, Edge or Firefox on the same machine and create the first administrator with the token from the log. Safari does not send Secure cookies to http://localhost, so sign-in does not stick there: use another browser, or, for local evaluation only and never in production, start with STACKURITY_PORT=127.0.0.1:8080 STACKURITY_COOKIE_SECURE=false STACKURITY_BASE_URL=http://localhost:8080 docker compose up -d, which also keeps the port off your network (why).

2. See it working in five minutes with a labelled demo estate: a server with outdated packages and an end-of-life runtime, an application deployed on it, and two repositories. Findings appear once the vulnerability feeds have synced:

docker compose exec stackurity stackurity admin load-demo        # --remove deletes it again

3. Connect your own estate:

• Servers: under Assets → Add server, create an install command and run it on each Linux host (or, in PowerShell, on each Windows host) or Mac. The agent is read-only and unprivileged, and it reports OS packages, runtimes and the libraries your deployed applications have installed (on Windows, the OS build and installed programs).
• Code: add repositories under Integrations, or run stackurity scan . --fail-on critical in CI to block vulnerable changes.
• Cloud: the AWS plugin reads managed service versions with a read-only role, and the Kubernetes reporter (in the cluster) or plugin reads a clus