Security in Xferity — Transport Trust, OpenPGP Encryption, Secrets, Posture Engine, Hardened Mode
Security
Section titled “Security”Xferity is designed for file exchange environments where partner endpoints must be verified explicitly, credentials must be handled carefully, and transfer activity must remain traceable.
Its security model combines:
- protocol-specific trust verification
- payload protection where configured
- centralized secret resolution and redaction
- hardened-mode configuration enforcement
- audit logging and operational traceability
- posture evaluation and regression alerting
Xferity focuses on transfer workflow security and traceability. It does not replace network security controls, identity systems, infrastructure hardening, or external evidence retention.
Trust boundaries
Section titled “Trust boundaries”The main trust boundaries are:
- remote partner systems
- the Xferity runtime host
- local filesystems used for config, staging, logs, audit files, and temporary data
- the selected state backend
- secret providers used for runtime resolution
- the operator access plane exposed through the CLI, Web UI, and HTTP API
Many security properties depend on these boundaries. For example, audit integrity still depends on filesystem and database access control, and secret protection still depends on bootstrap handling.
Security domains
Section titled “Security domains”Xferity evaluates these security domains through its posture engine:
- crypto
- secrets
- transport
- auth
- flow drift
These are evaluated across:
- platform scope
- partner scope
- flow scope
Protocol trust verification
Section titled “Protocol trust verification”SFTP trust
Section titled “SFTP trust”SFTP uses SSH host verification. A connection fails if no known_hosts file, host fingerprint, or explicit insecure override is configured. Xferity does not silently accept unknown host keys. This is a deliberate difference from most SFTP scripts that use StrictHostKeyChecking=no.
FTPS trust
Section titled “FTPS trust”FTPS uses TLS certificate validation. Xferity supports explicit TLS mode and passive mode, with standard TLS verification and optional SHA-256 server certificate fingerprint pinning for environments where CA-chain trust alone is insufficient.
S3-compatible storage trust
Section titled “S3-compatible storage trust”S3-compatible storage trust depends on the API endpoint, TLS to that endpoint, credential source, and bucket or prefix scope. It does not use an SSH-style host key model. Credentials can be IAM-based or static key-based with secret references.
AS2 trust
Section titled “AS2 trust”AS2 trust is certificate-based and role-specific. The runtime uses separate certificate roles for signing outbound messages, verifying inbound message signatures, encrypting outbound messages, decrypting inbound messages, and HTTPS transport trust. Each role can use a different certificate, which is the correct model for production B2B AS2 deployments.
Payload protection
Section titled “Payload protection”Depending on the flow, Xferity can apply payload protection as part of transfer execution.
That includes:
- OpenPGP encryption and decryption in file flows
- OpenPGP signing and verification where configured
- AS2 signing, encryption, and verification using certificate material
This keeps payload handling in the workflow definition instead of relying on separate manual steps.
OpenPGP execution modes
Section titled “OpenPGP execution modes”For file flows, OpenPGP execution can use:
- the native Go provider (
gopenpgp) - GnuPG (
gnupg) - controlled fallback mode (
auto)
auto is not a general retry mechanism. It is a compatibility mechanism used only for named native-provider compatibility failures.
Temporary GnuPG execution model
Section titled “Temporary GnuPG execution model”When GnuPG is used, Xferity creates an isolated temporary GnuPG home for the operation instead of using a global keyring.
This reduces:
- cross-flow key contamination
- dependence on host user profiles
- agent and keyring side effects between jobs
If cleanup of that temporary workspace fails, the event is surfaced through structured observability fields rather than being silently ignored.
Secrets handling
Section titled “Secrets handling”Xferity supports a secret-reference model so operators do not need to embed routine credentials directly in configuration.
Supported providers include:
- environment references
- file references
- local encrypted secret storage in supported Postgres-backed deployments
- HashiCorp Vault
- AWS Secrets Manager
- Azure Key Vault
Some bootstrap values still must come from bootstrap-safe sources such as environment variables or files. Xferity makes that boundary explicit rather than hiding it.
For details, see Secrets Management.
Hardened mode
Section titled “Hardened mode”Hardened mode is a configuration enforcement mechanism for stricter deployments.
Hardened mode can reject:
- plaintext secret values in sensitive config fields
- insecure Vault TLS skip-verify settings
state.postgres.sslmode=disable- partner settings that use insecure TLS skip-verify
- UI startup without required authentication and TLS settings
Hardened mode reduces unsafe configuration drift. It does not eliminate the need for host hardening, access control, or infrastructure review.
See Hardened Mode.
Web UI and API security posture
Section titled “Web UI and API security posture”When enabled, the Web UI and HTTP API are authenticated operator surfaces.
Security controls include:
- UI auth token support
- OIDC login in supported deployments
- session-backed access in Postgres-backed mode
- role-aware access control in UI and API handlers
- HTTP and AS2-related rate limiting
- optional UI TLS
In hardened mode, missing UI authentication or UI TLS configuration can block startup.
Auditability
Section titled “Auditability”Security review in MFT systems depends on knowing what happened to a file. Xferity includes structured audit logging for that purpose.
Auditability features include:
- append-oriented JSON audit events
- file lifecycle lookup
- sidecar indexing for faster audit queries
- optional tamper-evidence hash chaining
This improves traceability, but it is not a substitute for immutable external evidence storage.
Security posture and suppressions
Section titled “Security posture and suppressions”Xferity includes a posture engine that produces:
- Posture Findings
- Active Findings
- Suppressed Findings
- aggregate counts
- health summaries
- posture trends when snapshot persistence is available
When the backend supports it, posture data also includes:
- hourly snapshots
- regression detection
- alerts on worsening security state
- operator suppressions for acknowledged findings
Suppressions do not erase findings. They change how findings contribute to active counts, trends, and alerts.
This matters for security teams because the product separates:
- what was detected
- what is still active
- what has been intentionally suppressed
Boundaries and limits
Section titled “Boundaries and limits”To keep this page precise:
- Xferity does not guarantee compliance by itself
- Xferity does not replace SIEM, network controls, backup policy, or identity governance
- audit tamper evidence is not the same as an external immutable trust anchor
- protocol verification does not remove the need to manage partner trust material correctly
- file-backed deployments do not provide the full posture and suppression feature set available in Postgres-backed deployments