Skip to main content

Security & Engineering Principles

Core Philosophy​

We build secure systems that enable our team to move fast. Security is not a department - it's everyone's responsibility built into how we work.

The 10 Principles​

1. Automate Security, Don't Police It​

Principle: Security checks happen automatically in tools, not through manual review processes.

In Practice:

  • Pre-commit hooks catch secrets before they reach Git
  • CI/CD pipelines enforce security tests before deployment
  • Infrastructure policies are enforced by Terraform/Ansible validation
  • Branch protection prevents unsafe merges

Anti-Pattern: Requiring security team approval for every deployment

2. Default to Open, Protect What Matters​

Principle: Most things should be accessible to the team by default. Restrict access only to truly sensitive systems and data.

In Practice:

  • All engineers have read access to all code repositories
  • Development and staging environments are self-service
  • Production read access is self-service with logging
  • Production write access requires approval

Anti-Pattern: Requiring tickets to access non-production systems

3. Infrastructure as Code, No Exceptions​

Principle: If it's not in Git managed by Ansible, it doesn't exist. No manual server configuration.

In Practice:

  • All servers provisioned via Ansible playbooks
  • Configuration changes must go through Git PR workflow
  • Daily drift detection alerts on manual changes
  • Emergency manual fixes must be codified within 24 hours

Anti-Pattern: SSH-ing to prod and manually editing config files

4. Shift Security Left​

Principle: Find and fix security issues as early as possible - ideally before code is even committed.

In Practice:

  • IDE plugins catch issues while coding
  • Pre-commit hooks block obvious problems
  • CI runs security scans on every PR
  • Security review happens async, doesn't block shipping

Anti-Pattern: Discovering vulnerabilities in production

5. Trust but Verify​

Principle: Give teams autonomy to move fast, but log everything and audit regularly.

In Practice:

  • Engineers can deploy to production without approval
  • All production access and changes are logged
  • Automated alerts on anomalous behavior
  • Quarterly access reviews to verify appropriateness

Anti-Pattern: Requiring manual approval for routine deployments

6. Secrets Never Touch Git​

Principle: Credentials, API keys, passwords never belong in source code, even in private repos.

In Practice:

  • Use Ansible Vault for infrastructure secrets
  • Use GitHub Secrets for CI/CD
  • Use environment variables for application config
  • Automated secret scanning in pre-commit + CI

Anti-Pattern: .env files committed to repositories

7. Defense in Depth​

Principle: Multiple layers of security, so a single failure doesn't cause a breach.

In Practice:

  • Network segmentation via Netbird + VPCs
  • Application-level authentication + authorization
  • Database-level access controls
  • Encryption at rest and in transit
  • Regular backups with tested restore procedures

Anti-Pattern: Relying solely on firewall rules for security

8. Blameless Incident Response​

Principle: When things go wrong, we focus on fixing systems, not blaming people.

In Practice:

  • Post-incident reviews ask "what went wrong" not "who messed up"
  • Action items focus on preventing recurrence
  • Psychological safety to report security issues
  • Learn from mistakes and improve processes

Anti-Pattern: Punishing engineers for making mistakes

9. Document Decisions, Not Just Code​

Principle: Future team members (including future you) need to understand why decisions were made.

In Practice:

  • Architecture decisions recorded in docs
  • Config changes include PR descriptions explaining why
  • Incident postmortems published internally
  • Runbooks explain context, not just steps

Anti-Pattern: Undocumented tribal knowledge

10. Security Enables Business​

Principle: Security exists to protect and enable the business, not to say "no" to everything.

In Practice:

  • Security team helps find secure ways to say "yes"
  • Risk-based approach: not everything needs maximum security
  • Speed and security can coexist with the right tools
  • Business requirements drive security decisions

Anti-Pattern: Security as a blocker to innovation

Decision Framework​

When making security decisions, ask:

  1. What's the risk? (high/medium/low impact + likelihood)
  2. Can we automate controls? (guardrails vs manual process)
  3. Does it enable or block the team? (find ways to enable)
  4. Is it auditable? (log it if you can't prevent it)
  5. What's the business impact? (security serves the business)

Living Principles​

These principles evolve as our company grows and threats change. If a principle isn't working:

  1. Discuss in #engineering RocketChat channel
  2. Propose changes via PR to this document
  3. Get consensus from security + engineering leads
  4. Update and announce changes

Last updated: 2025-11-10