Security Capabilities — Xferity File Transfer Security Features

Security Capabilities

This page is the explicit, structured reference for Xferity’s security capabilities.

Transport trust verification

Xferity supports the following enterprise file transfer protocols:

AS2 with MDN receipts (sync and async), inbound and outbound
SFTP with SSH host key verification
FTPS with explicit TLS and fingerprint pinning
S3-compatible storage (AWS S3, MinIO, Cloudflare R2)
OpenPGP encryption and signing (native gopenpgp and GnuPG)

SFTP trust

SSH host key verification is required — no silent accept-all
Verification modes: known_hosts file or host_key_fingerprint (SHA-256 prefix)
Explicit allow_insecure_host_key: true override required to bypass (not for production)
Hardened mode rejects insecure host key override

FTPS trust

Explicit TLS mode (FTPES) only
Passive mode
Standard TLS verification against system CA pool
Optional SHA-256 server certificate fingerprint pinning for environments that need beyond-CA trust
Hardened mode rejects insecure TLS skip_verify partner settings

AS2 trust

Certificate-based and role-specific trust model
Separate certificate roles per partner:
- signing — signing outbound messages
- verification — verifying inbound message signatures
- encryption — encrypting outbound messages
- decryption — decrypting inbound messages
- HTTPS transport — client or server certificate for HTTPS trust
Certificate inventory managed per partner in the UI and API
Expiry tracking with posture findings for approaching expiry

S3 trust

TLS to the API endpoint
Credential options: IAM role or static key with secret references
Bucket and prefix scoping

Payload protection

OpenPGP encryption and decryption

Native Go provider (gopenpgp) — no external binary dependency
GnuPG provider (gnupg) — full GnuPG pipeline for enterprise key compatibility
Auto mode (auto) — tries native first, falls back to GnuPG for named compatibility cases only (compat_enterprise_key_structure)
Fallback is not a general retry — it only triggers for classified compatibility failures

OpenPGP signing and verification

Outbound signing: sign payload before upload
Inbound verification: verify partner signature after download
Detached and inline signature support
Signature verification failure is a permanent failure — not retried

Isolated GnuPG execution

Each crypto operation gets a dedicated temporary GnuPG home
No shared keyring between flows
No GPG agent side effects between jobs
No host user-profile dependency
Cleanup failure surfaces via structured log fields, not silently ignored

AS2 message crypto

Per-partner certificate roles for message signing and encryption
Inbound message decryption and signature verification
MDN signing for receipts

Secrets management

Xferity resolves credentials from 7 providers at runtime — no hardcoded passwords required:

Provider	Reference format
Environment variable	`env:MY_VAR`
File	`file:/run/secrets/password`
Local vault (AES-256)	`local-vault:key-name`
HashiCorp Vault KV v2	`vault:secret/data/path#field`
AWS Secrets Manager	`aws-sm:secret-id#field`
Azure Key Vault	`azure-kv:secret-name`
Literal (testing only)	`literal:value`

Secret references work across all config layers: global, partner, flow, auth
Local vault secrets are stored AES-256 encrypted in the Postgres backend
Local vault secrets are managed via UI without plaintext ever being echoed back
Bootstrap values require bootstrap-safe sources (env or file)

Hardened mode

security.hardened_mode: true causes startup refusal if any security rule is violated.

Hardened mode enforces:

Plaintext secret values in sensitive fields → startup failure
sslmode: disable for PostgreSQL → startup failure
Insecure TLS skip_verify on partner settings → startup failure
Missing UI authentication configuration → startup failure
Missing UI TLS configuration (when applicable) → startup failure
Insecure GnuPG or Vault TLS settings → startup failure

This turns security best practices into a hard gate, not advisory recommendations.

See Hardened Mode.

Security posture engine

Xferity continuously evaluates security posture across 6 domains:

Domain	What it evaluates
Crypto	Certificate expiry, PGP key bindings, AS2 cert roles present
Secrets	Plaintext credentials in config, missing secret references
Transport	SFTP host key status, FTPS TLS settings, AS2 TLS settings
Auth	UI authentication enforcement, rate limiting enabled
Flow drift	Scheduled flows with no recent execution
Platform	Runtime health, required backend features available

Scopes evaluated:

Platform scope
Partner scope (per partner)
Flow scope (per flow)

Posture outputs

Active Findings — current security issues
Suppressed Findings — acknowledged findings (still tracked, not erased)
Hourly posture snapshots (Postgres-backed only)
Posture trend charts over time
Regression detection — alert when security state worsens
Regression alerts delivered to: Email, Slack, Webhook, Ntfy, Gotify, Pushover

Audit logging

Structured JSONL — one JSON event per line per file operation
SHA-256 hash chain — chain_seq, prev_hash, event_hash on every event
Tamper-evident — any modification, insertion, or deletion breaks the chain
Verifiable with standard jq/awk tooling — no proprietary tool needed
Sidecar index for fast file lifecycle lookups without scanning full log
xferity trace <filename> — shows every audit event for a given file
Strict redaction mode — strips PII, bearer tokens, private key blocks, file paths from events
Configurable retention — prune events older than N days

Authentication and access control

Local auth — username + password with bcrypt hashing, session cookies, CSRF protection
OIDC — OpenID Connect login for browser sessions (any OIDC-compatible IdP)
Rate limiting — configurable per-IP rate limits on UI and API endpoints
Session-backed access in Postgres-backed deployments
Role-aware access control in UI and API handlers

Configuration security

Strict YAML parsing — unknown fields fail at startup (not silently ignored)
No silent misconfiguration — misspelled config keys cause startup failure
Configuration under version control with reviewable partner and flow YAML files

Air-gap readiness

No mandatory outbound connections during normal operation
License validation is local by default
All external providers (Vault, AWS SM, Azure KV) are optional
Deployable in fully isolated networks with only permitted partner endpoints

Capability summary

Xferity security capabilities include:

SSH host key verification for SFTP (required, not optional)
FTPS explicit TLS with SHA-256 certificate fingerprint pinning
AS2 certificate roles per partner (sign, verify, encrypt, decrypt, HTTPS trust)
OpenPGP encryption and decryption (native gopenpgp + GnuPG with isolated homes)
OpenPGP signing and verification
7 secret providers with no plaintext credential requirement
AES-256 local vault for secrets (Postgres-backed)
Hardened-mode startup enforcement for security rules
6-domain continuously evaluated security posture engine
Posture trend snapshots and regression alerting
Finding suppression (tracked, not erased)
JSONL audit log with SHA-256 hash-chain tamper evidence
Local auth (bcrypt) and OIDC authentication
CSRF protection and per-IP rate limiting
Strict YAML parsing — no silent misconfiguration
Air-gap ready — no mandatory outbound connections