Last updated: 2025-10-20

Security at Forgeon

Security isn’t a feature—it’s table stakes. Forgeon is designed as a multi-tenant, event-driven PaaS with layered controls across people, process, and technology. Below is a practical overview of how we protect your data and keep the platform reliable.

---

1) Security Philosophy

• Least privilege by default. Access is granted narrowly and audited.
• Secure by design. Simpler surfaces, strong defaults, paved roads.
• Defense in depth. Multiple, overlapping controls—no single point of failure.
• Transparency. Clear status comms, changelogs, and incident updates.
• Continuous improvement. We ship, we measure, we harden.

---

2) Responsible Disclosure (Vulnerability Reporting)

If you believe you’ve found a security issue, please email security@forgeon.io (placeholder) with details and steps to reproduce. We’ll triage promptly and keep you updated.

• Please avoid accessing other users’ data.
• Don’t disrupt services or degrade availability.
• We’re happy to acknowledge meaningful reports (hall of fame coming soon).

You can also check /.well-known/security.txt (optional) and our status page at /status (placeholder).

---

3) Data Protection & Privacy

• Data roles. For your account and platform usage, Forgeon is a controller. For data processed through your apps hosted on Forgeon, we act as a processor/service provider. See our Privacy Policy for details.
• Isolation. Tenant-scoped isolation at the service and data layers; internal identities and policies gate cross-tenant access.
• Backups. Regular backups for core control-plane data; retention windows documented per service. See “Availability & Backups.”

---

4) Encryption

• In transit. TLS for external traffic and mTLS/internal TLS where relevant between services.
• At rest. Encrypted volumes or database-native encryption for core data stores; secrets are encrypted at rest.
• Key handling. Keys are rotated per provider recommendations; avoid long-lived credentials where possible.

---

5) Network & Platform Security

• Segmentation. Control plane and runtime/edge are separated across networks/hosts.
• Ingress. API gateway with WAF/rate limiting, IP allow-listing (where configured), and request ID tracing.
• Egress. Controlled outbound where appropriate; service roles with least privilege.
• Runtime. Container isolation with restricted capabilities; host ports allocated only when needed; internal DNS for inter-service calls.

---

6) Application Security

• Authn/Z. JWT (JWKS) verification at the gateway, audience/issuer checks, and role/permission mapping at services.
• Input hardening. Validations at handlers; structured error handling; safe defaults.
• Secrets. Centralized secret providers (Vault/env/manager), never commit to source. Rotations are supported.
• Supply chain. Pinned images/builders; SBOM and image scanning on our roadmap.

---

7) Logging, Monitoring & Detection

• Structured logs. Request IDs, tenant context (where applicable), trace propagation.
• Metrics & alerts. Health checks, saturation/error budgets, anomaly alerts.
• Audit trails. Sensitive actions and auth events are logged with timestamps and actor context.

---

8) Availability & Backups

• SLO mindset. We design for steady availability and rapid recovery.
• Backups. Periodic backups for core control-plane databases; integrity checks; restore drills planned.
• Runtime resilience. Retry/backoff for events and job orchestration; idempotent handlers.

---

9) Incident Response

• Playbooks. Defined severity levels, comms channels, and on-call escalation.
• Contain → Eradicate → Recover. We scope and isolate the issue, patch, and restore services.
• Communication. We’ll post updates on /status (placeholder) and, for material incidents, email impacted customers.

---

10) Customer Responsibilities

Security is shared:

• Control access to your Forgeon org, API keys, and tokens.
• Keep dependencies in your applications up to date.
• Validate untrusted input, sanitize logs, and follow secure coding practices.
• Configure CORS, auth, and environment variables in line with your app’s risk.

---

11) Compliance & Subprocessors

• Subprocessors. We use carefully selected sub-processors to run the platform (compute, storage, analytics, email). See Subprocessors (placeholder) for the current list and purposes.
• Data location. Services may be hosted in multiple regions/providers; we apply appropriate contractual and technical safeguards.
• Compliance roadmap. Formal certifications (e.g., SOC 2) are on our path; we already implement many of the required controls.

---

12) Penetration Testing & Scanning

• Periodic internal testing and dependency scanning.
• Third-party penetration tests are planned; summaries may be made available under NDA.

---

13) Change Management

• Peer-reviewed changes via PRs and CI checks.
• Infrastructure as code with auditable diffs.
• Staged rollouts and canaries where suitable.

---

14) Contact

• Security reports: security@forgeon.io (placeholder)
• General support: support@forgeon.io
• Press/partnerships: hello@forgeon.io (placeholder)