Security Posture

Last updated: 2026-05-10

This page summarizes how FabWise protects customer data. It is written for customers, procurement teams, and security reviewers who need a clear public overview of our security practices.

Authentication (CC6.1, CC6.2)

FabWise uses authentication controls matched to each product surface:

• Administrative access uses password-based authentication with server-side session management.
• Workstation access supports passkeys for individual users.
• Shared-device and mobile workflows use controls appropriate to their operating environment.

Authentication endpoints are rate-limited. Authentication attempts and session events are logged separately from operational audit logs.

Authorization (CC6.1, CC6.3)

FabWise uses role-based access controls to limit access to product areas and administrative actions. Server-side authorization checks protect customer data and operational workflows; user interfaces are also scoped so people see controls appropriate to their responsibilities.

Authorization behavior is covered by automated tests and reviewed as part of the product development process.

Customer Data Separation (CC6.1)

FabWise is designed to keep each customer's data logically separated from other customer accounts. Access to customer records is scoped server-side, reinforced by authorization checks, and covered by automated tests.

Encryption (CC6.7)

• In transit — TLS enforced for all interfaces. Render handles TLS termination at the platform layer; HTTPS is the only protocol customer requests reach FabWise on.
• At rest — production databases and backups are encrypted at rest by our infrastructure providers.
• Application secrets — production secrets are encrypted or stored in managed environment configuration, not committed to source code.
• Internal communication — application infrastructure is designed so database traffic is not publicly exposed.

Audit Logging (CC7.1)

Sensitive operations are recorded to an audit_logs table:

• Audit entries capture who acted, what changed, when it happened, and relevant request context.
• Authentication events are logged separately from operational audit logs.
• Audit log access is limited to authorized administrative users.

Content Security Policy (CC6.1)

Browser-side injection prevention is configured via Content Security Policy headers:

• restrictive default source rules
• script controls with nonce support
• framing restrictions to help prevent clickjacking
• plugin/object restrictions for legacy browser attack surfaces

Infrastructure Security (CC6.6)

• Hosting — FabWise runs on managed application and database infrastructure. See our Subprocessor List for provider details.
• Backups — production database backups are encrypted and retained on a defined schedule.
• Email infrastructure — transactional and operational email is delivered through managed email infrastructure listed in our subprocessors.
• Secrets management — production secrets are managed outside source control.

Secure Development (CC8.1)

FabWise is built with continuous verification baked into the development pipeline:

• Branch protection — production code on the main branch is protected; all changes flow through pull requests with required CI passes before merge.
• Automated verification — code changes run through Ruby and ERB linting, security checks, dependency vulnerability scans, schema verification, and automated tests.
• Human review — customer-facing changes are reviewed in pull requests and, where appropriate, preview environments before release.
• Deliberate deployment — production deploys are intentional release events from reviewed code.

Incident Response (CC7.3)

FabWise maintains an internal incident response plan covering severity classification, escalation paths, customer notification, and post-incident review.

For security-specific concerns, customers and security researchers can email security@fabwise.app. We respond to security reports within 2 business days and acknowledge responsible disclosure.

Vendor Management (CC9.2)

FabWise tracks third-party services that process customer data. The customer-data-touching subset is published as our public Subprocessor List.

Subprocessor changes are communicated to subscribed customers at least 30 days before they take effect, where feasible. Subscribe via privacy@fabwise.app.

Change Management (CC8.1)

• Code changes — every change is a pull request with required CI passes; production deploys require an explicit calendar-version tag (YYYY.MM.DD).
• Infrastructure changes — infrastructure configuration changes go through the same pull-request review process as application code.
• Database schema changes — migrations are reviewed and tested before deployment.

Reporting a security issue

Found a security vulnerability in FabWise? We want to know.

1. Email security@fabwise.app with a description of the issue.
2. We respond within 2 business days to acknowledge receipt.
3. We work with you to confirm and resolve the issue. Public disclosure is coordinated with you; we acknowledge responsible disclosure on this page.

We appreciate good-faith security research and will work with you on coordinated disclosure.