Security

General

• Responsibility, not restriction. Generally, everyone should be trusted to be sensible.
• Use a passphrase-based SSH key.
• Use total volume encryption (e.g. FileVault). This is strongly enforced when dealing with client data.
• Everything is shared and searchable (except for financial/legal).
• We trust Pixies - but everyone should behave responsibly with privileged company and client information.
• Always enable 2FA if it is available. Store the OTP in 1Password.
• Regularly (once a month) check permissions across key accounts e.g. Google, calendars, third-party applications (e.g. oAuth apps). Build up a list of accounts that you need to check this for. This is good practice for personal accounts (e.g. social media) too.

Passwords

• You must use 1Password for Pixie Labs-related credentials.
• Never reuse passwords.
• We strongly encourage (one step short of enforcing) using 1Password for personal passwords too, as personal accounts can be used as a vector to attack Pixie Labs.
• Pixie Labs will pay for you to have a 1Password Personal or Families account whilst you work for Pixie Labs if you do not want to use the company account for your personal passwords. Ask David!
• If you forget your master password or secret key, David, Pete or Philip can help you recover your account.

Backups

• Your machine should be backed up with Backblaze.
• Pixie Labs will not access your device backups without your permission.
• Add a private encryption key via the Backblaze preferences panel. Keep this safe (store it in 1Password), you’ll need it if you need to restore anything.

Device security

• Your company MacBook must be enrolled in our centralised device management. Speak to David to be pointed in the right direction.
• Details about our device management policies must not be public; this would be an information risk.
• Keep your apps and operating system up to date.
• If you use a personal device (e.g. your phone or a secondary machine) for anything related to Pixie Labs, that must also have total volume/device encryption enabled. If it doesn’t support that, don’t use it for Pixie Labs-related activities. It must also have a strong password/passcode, and a reasonably short screen lock timer (at most two minutes).

Code and data security

• There are very few situations where you should commit credentials to code. Use environment variables or Rails encrypted credentials.
• Never, except with prior approval, pull down a production database on to your own machine. If you do need to, and it’s approved, remove as much customer data as possible.
• Do not give third-party applications access to GitHub (e.g. via sign-in with GitHub, oAuth, API access etc) without checking it’s OK with someone else.
• Do not share client code with anyone who is not a member of Pixie Labs.
• You should not copy code from one client to another, or to any other project or codebase, whether Pixie Labs or not.

Personally Identifiable Information (PII)

PII includes names, email addresses, phone numbers, addresses, IP addresses, and any other data that can identify an individual.

Never commit PII to code

• PII must never be committed to code repositories. This includes test data, fixtures, seed files, example data in documentation, or hardcoded values.
• Use anonymized or synthetic data for testing and development.
• Review your commits before pushing to ensure no PII has been accidentally included.

If PII is committed

If PII is accidentally committed to a repository:

1. Stop immediately and notify the team.
2. Follow GitHub’s process to remove sensitive data from the repository history.
3. Consider rotating any credentials or notifying affected users if required.

Limit PII to production systems

• In general, PII should only exist in production systems.
• Development and staging environments should use anonymized or synthetic data.
• If you must work with real PII in non-production environments (with explicit approval), ensure it’s properly secured and deleted when no longer needed.

Minimize PII sharing between services

• Redact PII from logs. Never log sensitive user data like passwords, full credit card numbers, or other PII.
• Redact PII from error reporting tools (e.g. Sentry, Bugsnag). Configure scrubbing rules to remove PII before errors are sent.
• Only share PII between services when absolutely necessary for functionality.
• When PII must be shared, use secure transmission methods (encrypted connections, time-limited tokens, etc.).
• Consider using references (IDs) instead of passing actual PII between services where possible.