Secure Development Policy¶


Owner	Joshua Curci - CTO
Applies to	All engineers and contractors contributing to Trove's codebase
Last reviewed	April 2026
Review cycle	Annually

Purpose¶

This policy defines the secure development practices that apply to all code written for the Trove platform. It ensures that security is considered throughout the development lifecycle rather than treated as an afterthought, and that the platform is built and maintained in a way that protects the data of the brands and customers who use it.

Scope¶

This policy applies to all code and configuration changes made to:

The Trove API (NestJS + Fastify)
The Admin Portal and Customer Frontend (React + Vite)
The Worker Service (NestJS + SQS)
Shared libraries, database migrations, and seeders
Infrastructure configuration and CI/CD pipelines
Any third-party integration code

It applies to all engineers, including full-time staff and contractors (including the Arcanys development team).

Secure Coding Principles¶

All code written for Trove must follow these core principles:

Input validation - all user-supplied input must be validated and sanitised before use. This applies to API request bodies, query parameters, headers, file uploads, and any data received from external systems (Shopify webhooks, Stripe events, etc.). Do not trust input from any source.

Output encoding - data rendered in the frontend must be appropriately encoded to prevent cross-site scripting (XSS). Avoid using dangerouslySetInnerHTML or equivalent patterns unless absolutely necessary and explicitly reviewed.

Authentication and authorisation - all API endpoints must enforce authentication via Auth0 JWT validation unless explicitly designed to be public. Authorisation checks must verify that the authenticated user has the correct role and scope for the requested resource. Do not rely on the frontend to enforce access controls.

Parameterised queries - all database interactions must use MikroORM's query builder or repository methods. Raw SQL queries are not permitted unless reviewed and approved by the CTO. This prevents SQL injection.

Secrets management - credentials, API keys, tokens, and other secrets must never be hardcoded in source code. They must be stored as environment variables and, where appropriate, encrypted using AWS KMS. Secrets must never be committed to the repository.

Principle of least privilege - code should request and use only the permissions it needs. AWS IAM roles, API scopes, and database permissions should be scoped to the minimum required.

Error handling - error messages returned to clients must not expose internal implementation details, stack traces, or sensitive data. Errors should be logged internally via Sentry with full context, but responses to clients should be generic.

Rate limiting - the API enforces a rate limit of 30 requests per second per client. New endpoints must be covered by this limit. Consider additional endpoint-level rate limiting for sensitive operations such as authentication or payment initiation.

OWASP Top 10¶

All engineers are expected to be familiar with the OWASP Top 10 web application security risks. Code reviews should specifically consider:

Injection (SQL, command, LDAP)
Broken authentication
Sensitive data exposure
Security misconfiguration
Cross-site scripting (XSS)
Insecure deserialisation
Using components with known vulnerabilities
Insufficient logging and monitoring

Source Control and Branching¶

All code is managed in GitHub within the Trove monorepo. The following requirements apply:

All changes must be made on a feature or fix branch - direct commits to main are not permitted
Branch names should be descriptive and reference the relevant ticket or feature
Force pushing to main or shared branches is not permitted
Sensitive data (credentials, keys, PII) must never be committed to the repository - this includes .env files, test fixtures containing real data, and hardcoded credentials in any form
If sensitive data is accidentally committed, the CTO must be notified immediately and the commit must be purged from history

See the Git Branching and Deployment Workflow for the full branching strategy.

Code Review¶

All code changes must be submitted as a pull request and reviewed before merging. The following requirements apply:

Every pull request must be reviewed and approved by the CTO before merging to main
Reviewers should specifically check for security issues including those listed in the OWASP Top 10 section above
Pull requests that introduce new API endpoints, authentication changes, data access patterns, or third-party integrations require particular scrutiny
Automated checks (linting, tests, CI pipeline) must pass before a pull request is approved
Self-merging without review is not permitted except in explicitly approved emergency hotfix scenarios - see the Change Management SOP

Dependency Management¶

The platform uses pnpm for package management. The following requirements apply:

Dependencies must be kept up to date. Security patches for dependencies should be applied promptly in line with the patch management timelines in the Information Security Policy
New dependencies should be evaluated before introduction. Consider whether the package is actively maintained, widely used, and whether it introduces unnecessary risk
Avoid dependencies with known critical vulnerabilities. Use pnpm audit to check for known issues before and after adding dependencies
Lock files (pnpm-lock.yaml) must be committed and kept in sync

Environment Separation¶

Trove operates three environments:

Environment	Purpose
Local	Individual developer machines
Development (Staging)	Integration testing and pre-release validation
Production	Live platform serving real brands and customers

The following rules apply:

Production data must never be copied to local or development environments
Development environment credentials and keys must be separate from production credentials
Changes must be tested in the development environment before deployment to production
Access to the production environment is restricted - see the Access Control Policy

Secrets and Credential Management¶

All secrets must be stored as environment variables, not in code
Production secrets are managed through DuploCloud and AWS
AWS KMS is used for encryption of particularly sensitive values (e.g. SMTP passwords, OAuth tokens)
Developers must use separate credentials for local development - production credentials must never be used locally
If a secret is suspected to have been compromised, it must be rotated immediately and the CTO notified

Third-Party Integrations¶

Trove integrates with several external services (Shopify, Stripe, Auth0, Xero, Sentry, etc.). The following requirements apply when building or modifying integrations:

Webhook payloads from external services must be validated using the signature or verification mechanism provided by the service before processing
OAuth tokens and API keys for third-party services must be stored securely and never exposed to the frontend
Third-party SDKs and libraries must be reviewed for security before use and kept up to date
Errors from third-party services must be handled gracefully and logged without exposing sensitive details to end users

Security Testing¶

Automated testing is in place via the CI/CD pipeline. The following security-relevant testing requirements apply:

Unit and integration tests must cover authentication and authorisation logic
Tests must not use real production credentials or data
End-to-end tests must validate that protected endpoints reject unauthenticated and unauthorised requests

Penetration testing is planned as part of the compliance roadmap and will be conducted by an external provider. When implemented, findings will be tracked and remediated based on severity.

Logging and Monitoring¶

Runtime errors and exceptions are captured automatically via Sentry
AWS CloudWatch is used for infrastructure-level monitoring
Logs must not contain sensitive data such as passwords, full payment card numbers, or unmasked PII
Suspicious activity detected in logs should be escalated to the CTO

Deployment¶

All deployments to production must follow the Deployment Windows and Release Policy and the Change Management SOP.

Deployments are managed through GitHub Actions CI/CD pipelines. Manual deployments to production outside of the automated pipeline require CTO approval.

Non-Compliance¶

Engineers who do not follow this policy may have their access to production systems suspended pending review. Serious or repeated violations may result in termination of contract or employment. Where a policy breach contributes to a security incident, it may also trigger the Breach Response Plan.