Skip to content

Security: rajumb502/ferrata

Security

SECURITY.md

Security Policy

Supported versions

Version Supported
0.1.x (current) ✅ Yes

Reporting a vulnerability

Please do not report security vulnerabilities through public GitHub issues.

Use GitHub's private vulnerability reporting instead — click the "Report a vulnerability" button on the Security tab of this repository. Only you and the maintainers can see the report.

Include:

  • A description of the vulnerability
  • Steps to reproduce it
  • The potential impact
  • Any suggested fix if you have one

This is a solo-maintained project. We will do our best to acknowledge reports promptly and address critical issues as quickly as possible, but cannot commit to fixed response timelines.

We will keep you informed throughout the process and credit you in the release notes unless you prefer to remain anonymous.

Scope

The following are in scope for security reports:

  • Tenant isolation bypass — any way for one tenant to access another tenant's tools or data
  • AuditRecord tampering — any way to forge or modify audit records without detection
  • Permission bypass — any way to execute a tool that should have been denied by PermissionChecker or ExecutionSandbox
  • Redaction bypass — any way for unredacted data to reach an external system (WAL or OTel) when a RedactionPolicy is configured
  • WAL integrity — any way to execute a tool without a WAL record being written when AuditLogger is configured
  • Injection vulnerabilities — any injection vector in Ferrata's own code (not in user-supplied tool functions)

The following are out of scope:

  • Vulnerabilities in user-supplied tool functions — these are the application developer's responsibility
  • Vulnerabilities in third-party backends (Redis, Postgres, DynamoDB, etc.) — report these to their respective maintainers
  • Issues that require an attacker to already have full control of the gateway configuration

Security design notes

Ferrata is a governance framework. Several security properties are by design and worth understanding:

Permission denial reasons are never returned to callers. PermissionChecker denial reasons are logged internally and written to the audit record, but the caller receives only a generic "permission denied" message. This prevents exposing the permission structure to potential attackers.

Unknown tenants and tenants with no tools are indistinguishable. Both return an empty tool set. This prevents tenant enumeration via the gateway API.

Redaction is unconditional. RedactionPolicy.redact() always runs before any external write. If redaction fails, the call is blocked entirely. There is no code path where an unredacted record reaches an external system.

WAL write failures block tool execution. If AuditWAL.write() fails, the tool does not execute. This is intentional — we cannot execute a tool we cannot audit.

There aren't any published security advisories