Security

Access to systems

• Two-factor sign-in is required for everyone with access to our code.
• We sign in to cloud accounts through single sign-on with short-lived credentials, not long-lived access keys.
• Automated deployments receive temporary AWS credentials issued for a specific repository and environment. Our build pipelines do not store cloud access keys.
• We administer servers through AWS Systems Manager where possible. Where direct SSH access is needed, it is limited to approved network addresses.

Code and changes

• Client and internal code is kept in private repositories. Main branches are protected against deletion and history rewrites.
• Every change passes automated tests before it is deployed.
• Production deployments run through a dedicated pipeline with its own restricted credentials. Where a system has a staging environment, releases are verified there first.
• Dependencies are locked to exact versions, and builds install only what the lockfile specifies. We are alerted to known vulnerabilities in our dependencies, and fixes are proposed automatically.

Data and recovery

• Systems run in AWS in the United States.
• Storage is private, blocks public access, accepts only encrypted connections, and is encrypted at rest.
• Backups are automated, and we test that they can be restored. Scheduled checks restore a recent backup into an isolated environment and confirm the data is usable.

Published software

Webstir, our open-source framework, audits its dependencies for known vulnerabilities whenever they change and every week. Its packages are published from automated builds with npm provenance, so anyone can verify where and how a release was built.

Reporting a security issue

If you believe you have found a vulnerability in something we built or run, email security@sqwarelogics.com. Include a description and the steps to reproduce it.