Security¶

Flex Video is designed for deployment on private and tactical networks where data integrity, confidentiality, and system resilience are critical. This page describes the security controls implemented in the product, known limitations, and the standards that guide our security posture.

No Third-Party Audit

Flex Video has not been independently audited by a third-party security firm. The security controls described on this page are based on internal security review conducted against industry standards (see Compliance Framework). While Blackwire is committed to meeting these standards, customers should perform their own security assessment before deploying Flex Video in environments handling sensitive or classified information.

Compliance Framework¶

Flex Video's security controls are designed to align with the following standards:

Standard	Level	Description
NIST SP 800-171	—	Protecting Controlled Unclassified Information (CUI) in nonfederal systems
CMMC	Level 2	Cybersecurity Maturity Model Certification for defense contractors
OWASP ASVS	Level 2	Application Security Verification Standard

These standards inform our security decisions but do not constitute a certification. See Disclaimer for details.

Authentication & Access Control¶

Password Authentication¶

Flex Video supports optional password-based authentication with session tokens.

Password requirements: Minimum 12 characters (enforced by the API)
Password storage: Bcrypt hashing with unique random salt per password
Session tokens: 256-bit cryptographically random tokens, valid for 24 hours
Token storage: Tokens are stored as SHA-256 hashes — the original token is never persisted

See Authentication for API details.

API Key Authentication¶

Internal service-to-service communication uses an API key generated during installation. API keys are compared using constant-time algorithms to prevent timing-based attacks.

Rate Limiting¶

Login attempts are rate-limited to 5 attempts per 15 minutes per IP address to protect against brute-force attacks. Rate-limited requests receive a 429 Too Many Requests response with a Retry-After header.

File deletion endpoints are also rate-limited to prevent abuse.

Encryption¶

Data in Transit¶

All client-facing communication uses HTTPS (TLS) by default:

The REST API (port 3539) serves HTTPS using a self-signed certificate generated during installation
The Web UI (port 8443) serves HTTPS using the same certificate and includes a reverse proxy to the API, eliminating cross-origin requests from the browser
The reverse proxy uses an auto-generated shared secret to authenticate forwarded requests, ensuring client IP addresses in audit logs are accurate
Certificates are stored at /opt/flex/certs/ and can be replaced with organization-signed certificates

Self-Signed Certificates

The installer generates a self-signed TLS certificate. For production deployments, you can replace this with a certificate from your organization's PKI by placing your certificate and key files in /opt/flex/certs/.

Data at Rest¶

Sensitive data stored on disk is encrypted using FIPS-approved algorithms:

Encryption: AES-256 for all encrypted stores
Password hashing: Bcrypt with unique random salt per password
Token hashing: SHA-256 for session token and license verification
Encryption keys: A unique 32-byte random key is generated per installation at first startup
Encrypted stores: Authentication credentials, pipeline configurations, and integration settings are stored in encrypted databases
Secrets management: Passwords, integration tokens, and certificates are never stored in plaintext

Write-Only Secrets¶

Secrets submitted through the API (integration tokens, TAK Server certificates) are write-only — they can be set or updated, but GET responses return only a boolean indicating whether the value is configured, never the value itself.

Container Security¶

Docker Hardened Images¶

All Flex Video containers are built on Docker Hardened Images (DHI) — minimal, secure, production-ready base images maintained by Docker. DHI images are published with near-zero known CVEs, signed provenance via Cosign, and a complete Software Bill of Materials (SBOM).

Property	Detail
Base	Docker Hardened Images for Debian (minimal, distroless runtime)
CIS compliance	Compliant with CIS Docker Benchmark v1.8.0 Section 4 (container images and Dockerfile configuration) by default
FIPS 140-3	FIPS variants with validated cryptographic modules are available for environments that require FIPS compliance. Contact licensing@blackwire-ts.com for FIPS-enabled builds.
Provenance	Images are signed with Cosign and include SBOM and VEX metadata for supply chain verification
CVE remediation	Base images are rebuilt regularly to include the latest security patches

Runtime Hardening¶

Each container runs with defense-in-depth controls:

Control	Description
Non-root execution	All containers run as non-root users
Read-only filesystem	Container filesystems are mounted read-only with tmpfs for temporary files
No shell access	Shell binaries (`/bin/sh`, `/bin/bash`) are removed — no interactive access possible
No package manager	`apt`, `dpkg`, and other package managers are removed, preventing software installation
Minimal capabilities	All Linux capabilities are dropped (`cap_drop: ALL`); only specific capabilities are added where required
No privilege escalation	The `no-new-privileges` security option prevents processes from gaining additional privileges
Device cgroup rules	Camera and audio device access is restricted to specific device classes rather than granting broad access

Device Access¶

Camera and audio device access is controlled through host-side permission rules (udev/mdev) and device cgroup rules rather than running containers in privileged mode. This ensures each container has the minimum access required for its function.

Input Validation¶

All user input is validated at system boundaries:

Input	Validation
Pipeline IDs	Alphanumeric, dashes, and underscores only; maximum 64 characters
Request bodies	Size limits enforced per endpoint (1 KB–5 MB depending on endpoint)
Content-Type	Only `application/json` and `text/plain` are accepted on mutation endpoints; other types receive `415 Unsupported Media Type`
File names	Strict allowlist pattern; path traversal characters (`/`, `\`, `..`) are rejected
GStreamer pipelines	User-provided strings are escaped before inclusion in pipeline descriptions; no shell execution is used
Session tokens	Format and length validated before cryptographic operations

Audit Logging¶

Security-relevant events are logged with structured audit entries including timestamps, event types, source IP addresses, and outcomes:

Authentication events (login, logout, failed attempts, rate limiting)
Password changes
Settings modifications
Pipeline operations (create, delete, start, stop)
File deletions
Unauthorized access attempts

Audit events are always emitted regardless of the configured log level.

Log Persistence

Audit logs are written to the container's standard output. For persistent audit trails, configure your container runtime to forward logs to a centralized logging system (e.g., syslog, journald, or a log aggregation service).

Dependency Management¶

All direct dependencies are pinned to specific versions to prevent supply chain attacks
Git-sourced dependencies are pinned to exact commit hashes
Dependencies are reviewed for known vulnerabilities as part of the security review process

Network Security¶

Designed for Private Networks¶

Flex Video is designed for deployment on private, isolated, or tactical networks — not the public internet. The threat model assumes:

The network is physically or logically isolated from the internet
Network participants are authorized operators or systems
Physical access to the device is controlled

Some security controls that are critical for internet-facing applications (such as CSRF protection and Content Security Policy headers) are not implemented because they address threats that do not exist on isolated networks.

Server-Sent Events (SSE)¶

Real-time status updates are delivered via Server-Sent Events with Cache-Control: no-store, private headers to prevent intermediate caching of operational data.

Resource Conflict Prevention¶

The API prevents multiple pipelines from using the same exclusive resources (cameras, output ports), which could cause data corruption or system instability.

Known Limitations¶

The following items are known limitations that have been evaluated and accepted based on the private-network deployment model:

Limitation	Risk Assessment
CORS wildcard origin	`Access-Control-Allow-Origin: *` is set on all responses. On a private network without internet access, there are no untrusted web origins to exploit this.
Initial password setup	When no password is set, the first user to access the device can set one. On a private tactical network, this is the intended workflow — the first operator provisions the device.
HTTP fallback	If TLS certificates are unavailable, the API falls back to HTTP. This is an intentional design choice for physically-isolated networks where TLS infrastructure may not be available.
Browser security headers	Headers like `X-Frame-Options` and `Content-Security-Policy` are not set on the API. These protect against internet-based browser attacks that do not apply on isolated networks. `Strict-Transport-Security` (HSTS) is intentionally never set — it is incompatible with self-signed TLS certificates and would lock Chromium-based browsers (Chrome, Edge) out of the web UI.
In-memory sessions	Session tokens are stored in memory and cleared on container restart. This reduces exposure from physical device capture at the cost of requiring re-authentication after restarts.

Responsible Disclosure¶

If you discover a security vulnerability in Flex Video, please report it responsibly:

Email: security@blackwire-ts.com
Response time: We aim to acknowledge reports within 48 hours

Please include:

Description of the vulnerability
Steps to reproduce
Potential impact
Suggested remediation (if any)

Scope

Security reports should relate to the Flex Video software itself. Issues related to your specific network configuration, deployment environment, or third-party integrations should be directed to your organization's IT security team.

Disclaimer¶

THE SECURITY INFORMATION PROVIDED ON THIS PAGE IS FOR INFORMATIONAL PURPOSES ONLY. BLACKWIRE LLC MAKES NO WARRANTIES, EXPRESS OR IMPLIED, REGARDING THE SECURITY OF THE FLEX VIDEO SOFTWARE, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.

FLEX VIDEO HAS NOT BEEN INDEPENDENTLY AUDITED OR CERTIFIED BY ANY THIRD-PARTY SECURITY ORGANIZATION. REFERENCES TO NIST SP 800-171, CMMC, AND OWASP ASVS DESCRIBE THE STANDARDS USED TO GUIDE INTERNAL SECURITY REVIEW AND DO NOT CONSTITUTE CERTIFICATION, ACCREDITATION, OR COMPLIANCE ATTESTATION UNDER ANY FRAMEWORK.

CUSTOMERS ARE SOLELY RESPONSIBLE FOR EVALUATING WHETHER FLEX VIDEO MEETS THE SECURITY REQUIREMENTS OF THEIR SPECIFIC DEPLOYMENT ENVIRONMENT, INCLUDING ANY APPLICABLE REGULATORY, CONTRACTUAL, OR ORGANIZATIONAL SECURITY REQUIREMENTS. BLACKWIRE LLC RECOMMENDS THAT CUSTOMERS CONDUCT THEIR OWN INDEPENDENT SECURITY ASSESSMENT PRIOR TO DEPLOYING FLEX VIDEO IN ENVIRONMENTS THAT HANDLE CONTROLLED UNCLASSIFIED INFORMATION (CUI), PERSONALLY IDENTIFIABLE INFORMATION (PII), OR OTHER SENSITIVE DATA.

BLACKWIRE LLC RESERVES THE RIGHT TO MODIFY THE SECURITY CONTROLS DESCRIBED ON THIS PAGE AT ANY TIME WITHOUT NOTICE. THE INFORMATION ON THIS PAGE REFLECTS THE SECURITY POSTURE OF THE SOFTWARE AT THE TIME OF PUBLICATION AND MAY NOT REFLECT THE CURRENT STATE OF ANY SPECIFIC INSTALLED VERSION.

FOR QUESTIONS ABOUT FLEX VIDEO'S SECURITY POSTURE OR TO REQUEST ADDITIONAL SECURITY DOCUMENTATION, CONTACT security@blackwire-ts.com.