Legal
Security overview
Last updated
Our approach
Farshore Labs runs entirely on Microsoft Azure with a defence-in-depth posture: private endpoints by default, customer-managed encryption at rest, managed identities for all inter-service auth, and least-privileged RBAC. We treat security as a build-time constraint, not a follow-up task.
Hosting and isolation
- All workloads run in Azure Container Apps with a dedicated managed environment per stage (dev, prod).
- Cosmos DB, Key Vault, and Azure Container Registry are connected via private endpoints; public network access is disabled in production.
- Front Door fronts the production web tier with TLS 1.2+ only and HSTS enabled. Internal service-to-service traffic stays on the Container Apps internal FQDN.
- Primary region
eastus2; disaster-recovery regionwestus3.
Encryption
- In transit: TLS 1.2+ everywhere, including internal traffic between services.
- At rest: Azure Storage, Cosmos DB, and Key Vault data is encrypted with customer-managed keys (CMK) in Azure Key Vault.
- Passwords: hashed with Argon2id (memory-hard, salted per user). Raw passwords are never logged or returned by any API.
- JWTs: HS256-signed with a 64-byte key stored in Key Vault. Sessions are bound to a server-side record so revocation is immediate.
Identity & access
- Customer accounts: email + password with optional TOTP MFA. Email verification is required before paid actions.
- Sessions: opaque session ID delivered in a
__Host-sessioncookie (HttpOnly, Secure, SameSite=Lax). CSRF defended by double-submit token. - API keys: the
fsl_live_prefix is recognised by GitHub secret-scanning. Keys are stored only as SHA-256 hashes; the raw value is shown once at creation. - Platform RBAC: each service runs under a dedicated managed identity with the minimum role assignments needed.
Secure development lifecycle
- Every change goes through pull request review and automated unit, integration, and end-to-end test suites in GitHub Actions.
- Infrastructure as Code is Bicep;
bicep build,what-if, and PSRule for Azure run in CI. - Container images are built and pushed via OIDC federation (no long-lived cloud credentials in CI).
- Dependencies are tracked via Dependabot; critical advisories are merged on a same-day SLO.
- Secrets are managed exclusively in Azure Key Vault. The repositories run secret-scanning and block pushes that contain recognised patterns.
Monitoring & incident response
- All services emit structured logs and metrics to Azure Application Insights and a central Log Analytics workspace.
- Alerts route to the on-call engineer; severity-1 incidents trigger immediate page.
- Incident response follows a documented runbook: contain → investigate → eradicate → recover → post-incident review.
- Backups: Cosmos DB continuous backup (PITR up to 30 days). Recovery procedures are tested at least annually.
Responsible disclosure
We welcome reports from security researchers. Please email security@farshorelabs.com with reproduction steps, affected URL/endpoint, and any proof of concept. We will:
- Acknowledge receipt within two (2) business days.
- Provide a preliminary triage within seven (7) calendar days, including a severity classification.
- Keep you informed during remediation and credit you on the advisory if you wish.
Please give us a reasonable opportunity to remediate before public disclosure. Do not access, modify, or exfiltrate data that does not belong to you, and do not run automated scans that degrade the platform for other customers.
Certifications and assurance
Farshore Labs leverages Microsoft Azure’s underlying certifications (ISO 27001, SOC 2 Type II, ISO 27018, EU Cloud Code of Conduct, and many regional frameworks). Farshore-level attestations are in progress; please contact security@farshorelabs.com for the current status and to request a security questionnaire.