# Secure Development Lifecycle

How We Build Securely

## Security and Privacy by Design

Data protection is considered at the start of designing a system, not added afterward. We capture only the data a feature actually needs, and database schemas are designed around that principle of minimization rather than collecting everything by default.

No real customer data is ever used in development or testing. Engineers work against synthetic data on an isolated staging environment, so building and debugging the product never exposes live personal information.

## Defending Against Common Attacks

We build against the well-known classes of web vulnerability. Database access uses parameterized queries throughout, which removes SQL injection. User-facing output is encoded and sanitized to prevent cross-site scripting. All traffic runs over HTTPS, and sensitive data is encrypted in transit and at rest.

Authentication and session handling are designed so credentials and tokens cannot be reused to impersonate a user. Access control is enforced on every request and narrowed at the database layer too, so a flaw in one place does not hand an attacker broad access. The full set of controls lives on our Security page.

## Vetting Dependencies and Changes

Open-source libraries and frameworks are powerful but carry risk, so the components we depend on are vetted and continuously scanned for known vulnerabilities, with findings tracked to remediation on a defined clock.

Code changes are reviewed and run through automated checks before they ship, and every change is tested on isolated staging before it reaches production. How we score and remediate findings is documented on our Vulnerability Management page.

## Logging, Oversight, and Data Rights

Privileged actions write an audit-log entry tied to the responsible identity, and the platform is monitored so suspicious activity is caught and fed into incident response rather than going unnoticed.

The downstream privacy rights this design protects, consent, data access, erasure, and portability, are described on our GDPR and Privacy pages, which is where those obligations are formally documented.

## What this means for customers

- Security and privacy considered from the design phase, not bolted on
- OWASP-aligned defenses: parameterized queries, output encoding, enforced auth
- Least-privilege access at both the application and database layers
- Open-source dependencies vetted and continuously scanned
- No real customer data ever used in development or testing