Security and data handling
The answers a security review asks for.
Facts about the product as built. The organisational answers (insurance, incident contacts, subprocessors) come with the full vendor questionnaire, available on request.
Architecture and data flow
- What does the product connect to?
- Four things, all initiated from your machine: AWS APIs, read-only, using your own AWS CLI profile (the permission list is published and contains only Describe, Get and List actions); the public certificate-transparency search, only during an attack-surface scan; hostnames under your own domain, only during an attack-surface scan; and webhook endpoints you configure. There is no telemetry, no crash reporting, no license server, no update check, and no vendor endpoint of any kind.
- Where is the data stored?
- In one directory on your machine: a SQLite database with scan history, findings, evaluation evidence, dispositions, schedules and webhook configuration, plus the license file. The database is not encrypted by the product; it relies on the operating system's disk encryption, which we recommend as a baseline for any machine that holds security findings.
- How are AWS credentials handled?
- The product never stores AWS credentials. It reads your existing AWS CLI configuration through the AWS SDK's standard credential chain, the same way the AWS CLI does. Organization scans assume a role in each member account through STS; the temporary credentials live in process memory for the duration of the scan.
- How are webhook secrets handled?
- The signing secret for a generic webhook is generated once, shown once, and stored in the local database; deliveries are signed with HMAC-SHA256 so the receiver can verify origin.
Application security
- Electron hardening
- Context isolation on, sandbox on, Node integration off, a strict content-security policy, navigation and window-open locked down. The interface talks to the main process only through a typed bridge with explicit channels.
- Process isolation
- Scans run in a separate worker process; a crash in a collector cannot take down the application or its database.
- Dependencies
- The AWS SDK for JavaScript v3, Electron, React and a handful of build-time tools. A software bill of materials in CycloneDX format is produced from the exact locked dependency tree of each release; ask for it with the installer. Dependency audit runs in CI.
- Code signing
- Not yet in place; builds are currently unsigned and the installation guide documents the operating-system prompts. Apple notarization and Windows Authenticode signing are planned before general availability.
- Updates
- Manual only, by design: there is no auto-update channel. New versions are downloaded and verified by you.
- Licensing
- Offline. The license is an Ed25519-signed file verified against a public key compiled into the product; nothing is checked online. A clock-rollback detector prevents extending an expired license by changing the system date.
Development practices
- Type safety and tests
- TypeScript throughout with strict type checking in CI. The scanning engine (rules, scoring, compliance mapping, control matrix, diff) is pure and unit-tested; the suite runs on every push.
- Control numbers
- Never written from memory: CIS numbers are verified against AWS Security Hub's published mapping and the benchmark files, AWS FSBP against the Security Hub controls reference, and the other frameworks are generated from Prowler's Apache-licensed mapping files with the source commit recorded.
- Inspectability
- The packaged application ships unobfuscated so what runs can be audited. Source is available for inspection under the license agreement.