Security

Running polign_db means running a closed-source binary inside your VPC with credentials to your bucket. This page is the checklist a security review will ask for: what the binary does on the network, how to verify a download, how access control works, what the license says, and where to report a vulnerability.

What the binary does on the network

There is no telemetry. The binaries don't report usage, don't send crash dumps, don't check licenses, and don't check for updates. The server's outbound traffic goes to the object store you configured with -store (S3, GCS, Azure, or any S3-compatible endpoint), plus AWS STS when cross-account role assumption is on. The polign CLI and polign-apikey connect to whatever server address you give them, localhost by default. That's the complete list.

The easiest way to check this claim is to enforce it: an egress policy that allows only your object store and STS breaks nothing. Air-gapped deployments work for the same reason, against an internal S3-compatible store or a plain fs: directory.

Verify a download

Each release attaches a checksums.txt with the SHA-256 of every archive. The install script already checks it before unpacking. Downloading by hand, the same check is:

V=$(curl -fsSL https://dl.polign.com/latest/version)
OS=$(uname -s | tr '[:upper:]' '[:lower:]')
ARCH=$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/')
curl -fsSLO "https://dl.polign.com/$V/polign_db_${OS}_${ARCH}.tar.gz"
curl -fsSLO "https://dl.polign.com/$V/checksums.txt"
grep "polign_db_${OS}_${ARCH}.tar.gz" checksums.txt | shasum -a 256 -c -

Archives aren't signed yet; the checksums and archives are published together on GitHub releases and fetched over TLS, and signed releases are on the roadmap. Every archive carries its LICENSE and CHANGELOG, so you can tell later exactly what a host is running.

How access control works

polign_db is single-tenant: one deployment serves one application, and isolation between customers means one instance per customer, not anything in-process. The data plane (put, get, search, list, delete) carries no credential on purpose, so anything that can reach the data listeners can read and write every vector. Reachability is the access control. The server binds 127.0.0.1 unless you tell it otherwise, and anything wider belongs behind your gateway, mesh, or VPN, which is also where per-caller auth and rate limiting live.

API keys guard the surfaces that act with the server's own cloud credentials: the collection API, the management API at /v1/admin, and the admin UI's storage probe. A key is plgn_<key_id>_<secret> with a 256-bit random secret. Only the secret's SHA-256 is ever stored, so a leaked bucket listing yields no usable credential; verification is a constant-time compare, and every auth failure returns the same opaque error. The plgn_ prefix is there so secret scanners recognise a leaked key.

When a collection is bound to your own bucket, the server never holds long-lived credentials for it. Access goes through IAM role assumption with a server-minted ExternalId as the confused-deputy guard, and the wiring is verified against the bucket before the collection activates. The server's own -store bucket is reached as the ambient identity (the instance or task role), so a normal deployment has no static keys anywhere. The hardening details live in Operate in production.

Known limitations

Written down here so they're chosen, not discovered:

License

polign_db is proprietary and the source isn't public. The binaries are licensed, not sold, and free to self-host while polign_db is in v0.x early access, with no license key and no feature gates (Pricing has the details). The full text ships in every release archive as LICENSE; it's a conventional proprietary grant: run it for your own internal purposes, no redistribution, no derivative works, no reverse engineering.

Reporting a vulnerability

Email security@polign.com with a description and a reproduction if you have one. Please don't open a public issue for anything you believe is exploitable. You'll get an acknowledgement within a few days, and fixes ship in the next patch release with credit unless you ask otherwise. Only the latest release gets security fixes, so upgrading is the patch channel.