Security Whitepaper

GlueArrow Box OS — Broadcast Operations Platform Document version: 1.0 · Applies to Box OS 1.6.0+

---

1. Executive Summary

GlueArrow Box OS is the on-premises broadcast operations engine deployed by radio and television stations to run live playout, automation, proof-of-play logging, and revenue-bearing ad delivery. Because the platform captures station audio, publishes live streams, and produces financial records (proof-of-play underlies advertiser billing and royalty distribution), its security posture is a procurement gate, not a feature.

This whitepaper explains the design principles, controls, and operational disciplines that protect the platform, the station's content, and the station's money. It is written for IT security reviewers, compliance officers, and enterprise procurement teams.

Summary of the security posture:

• Offline-first by design. The box is authoritative for its own station. Cloud is a mirror, not a dependency. Loss of internet never halts broadcast or proof-of-play logging.
• Signed, verified software supply chain. Every update is SHA-256 verified and applied atomically with automatic rollback on failure.
• Hardened operating system. Systemd confinement, non-root service account, read-only system partitions, and A/B update partitions mean no single update can brick a box in the field.
• Encrypted storage for sensitive payloads. AES-256-CTR at rest for encrypted audio archives; SQLite state files protected by OS-level file permissions.
• Minimized cloud footprint. The cloud receives detection metadata and operational events — not continuous raw audio.
• Explicit vulnerability disclosure policy. A public contact point, a 90-day coordinated disclosure window, and a documented patch SLA.

---

2. Trust Boundaries

┌──────────────────────────────────────────────────────────────┐
│  TRUST BOUNDARY 1 — Station Premises                         │
│  ┌────────────────────────────────────────────────────────┐  │
│  │  TRUST BOUNDARY 2 — GlueArrow Box                      │  │
│  │  ┌──────────────────────────────────────────────────┐  │  │
│  │  │  TRUST BOUNDARY 3 — Engine process (non-root)    │  │  │
│  │  │  • api.py (Flask, systemd-confined)              │  │  │
│  │  │  • RTMP streamer subprocess                      │  │  │
│  │  │  • Local SQLite state                            │  │  │
│  │  └──────────────────────────────────────────────────┘  │  │
│  └────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────┘
                          │
                          │  Signed HTTPS (TLS 1.2+)
                          ▼
┌──────────────────────────────────────────────────────────────┐
│  TRUST BOUNDARY 4 — GlueArrow Cloud (us-central1)            │
│  • Cloud Run services, IAM-gated                             │
│  • Cloud SQL (Postgres), private IP                          │
│  • Cloud Storage, signed URLs only                           │
└──────────────────────────────────────────────────────────────┘

Each boundary is independent. Compromise of one tier does not automatically compromise the tier beneath it.

---

3. Data Classification and Handling

3.1 Data the platform processes

Data class	Examples	Storage	Transit
Broadcast metadata	Show schedule, ad assignments, rotation rules	Local SQLite + cloud mirror	TLS 1.2+
Proof-of-play records	Time-stamped detections of what played on air	Local SQLite (signed ledger) + cloud mirror	TLS 1.2+
Detection metadata	Compact, non-reversible representations of what was heard on air	Local SQLite + cloud mirror	TLS 1.2+
Account and billing data	Station owner name, email, phone, license key	Cloud only (Postgres)	TLS 1.2+
Staff authentication tokens	Short-lived session cookies issued by accounts.gluearrow.com	Browser session	TLS 1.2+
Raw station audio	Live mic and line-in signal	Local only — never transmitted	N/A
Archived audio snippets	Optional retained clips for dispute resolution	Local only, AES-256-CTR encrypted	N/A

3.2 What is never sent to the cloud

The platform is deliberately restrictive about what leaves the station:

• Continuous raw audio. The cloud receives detection metadata derived from the station's broadcast. It does not receive a rolling recording of the station.
• Personally identifying biometrics without explicit consent from the calibrated individual.
• Unencrypted audio archives. If audio retention is enabled for dispute resolution, the archive is AES-256-CTR encrypted at rest on the box.
• Customer phone call content (for stations that integrate phone-in lines — the signal is captured locally, not exfiltrated).

3.3 Data minimization

Cloud sync transmits only what is necessary for operational continuity and cross-station features:

• Schedule mirror — so producers can edit remotely
• Proof-of-play ledger — for advertiser billing and royalty calculation
• Station health beacon — for operational monitoring
• Ad campaign and media download requests — for ad delivery

Detection events contain no raw audio; they are compact, tamper-evident records.

3.4 Data residency

Primary cloud storage is located in Google Cloud us-central1 (Council Bluffs, Iowa, United States). Enterprise tier customers requiring EU, African, or Asian data residency may request region-specific deployment; this is handled contractually.

---

4. Identity and Access Management

4.1 Station operator authentication

Staff accessing the control panel authenticate through accounts.gluearrow.com. Supported methods:

• Email + one-time password (OTP) — default for all tiers
• Phone OTP via WhatsApp — default for all tiers
• SAML 2.0 single sign-on — enterprise tier, customer IdP (Okta, Azure AD, Google Workspace tested)
• Multi-factor authentication — required for administrator and owner roles

Session tokens are short-lived (24 hours typical), scoped to the station, and revocable instantly from the cloud admin console.

4.2 Role-based access control

The platform implements four roles, enforced at both the cloud API layer and in the control panel UI:

Role	Capabilities
Owner	Full administrative control, billing, user management, license key rotation
Station manager	Schedule, ad approval, proof-of-play review, staff invitation
Operator	Day-to-day production — live switching, playout, workspace usage
Viewer	Read-only access for compliance officers, auditors, regulators

Role boundaries are enforced at every endpoint. Admin-prefixed routes require both a valid session and an explicit admin claim; unauthorized access returns HTTP 403 and is logged.

4.3 Machine authentication

• Box → Cloud API: each box holds a unique machine credential bound to its license key. Credential rotation is supported without downtime.
• Cloud → Box: the cloud never initiates inbound connections to the box. All communication is box-initiated, outbound HTTPS.

4.4 API authentication

REST and WebSocket APIs require one of:

• Valid user session cookie (for browser-originated requests)
• Authorization: Bearer <token> header with a box machine credential
• Signed server-to-server JWT for partner integrations (enterprise tier)

Unauthenticated access is limited to /health and /metrics (when restricted to a monitoring subnet).

---

5. Device Security

5.1 Operating system hardening (appliance)

The GlueArrow Box Appliance ships on Korra OS, a custom Ubuntu 22.04 LTS derivative hardened for broadcast appliance use:

• A/B partition layout with RAUC atomic updates. Updates install to the inactive partition; a failed boot automatically falls back to the previous known-good partition.
• Read-only root filesystem via overlayroot. System binaries cannot be tampered with at runtime.
• Minimal package set. No SSH by default (enabled temporarily by physical long-press on the status LCD for 30 minutes only), no development toolchain, no user-serviceable shell.
• Dedicated non-root service account (gluearrow) for the engine. The root account is used only for OTA updates and is disabled for interactive login.

5.2 Process isolation (all modes)

The engine runs under systemd with the following confinements (Linux):

NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/gluearrow-box-os /opt/gluearrow-box-os/static/hls
LimitNOFILE=65536
MemoryMax=2G

These mean the engine cannot escalate privileges, cannot modify system binaries, cannot read other users' home directories, and is bounded in resource consumption.

5.3 Runtime watchdog

systemd's WatchdogSec=30 requires the engine to beacon its health every 30 seconds. A hang results in automatic restart, preventing silent failure during live broadcast.

5.4 Physical security considerations

Deployments in uncontrolled physical environments (small community stations, shared studios) should consider:

• Locking the Box in a rack or cabinet
• Tamper-evident seals on the chassis
• Disabling USB boot in firmware
• Setting a BIOS/UEFI password

The GlueArrow Box Appliance ships with USB boot disabled and a factory-set firmware password. Customer workstations retrofitted with Box OS (Mode C) must have these controls applied by the station's IT team.

---

6. Software Supply Chain

6.1 Build provenance

• Source is versioned in a private GitHub repository with mandatory pull request review and CODEOWNERS enforcement.
• Continuous integration runs unit and integration tests, static analysis, and dependency vulnerability scanning on every build.
• Release artifacts are produced by the cloudbuild.yaml pipeline running in Google Cloud Build with audit logging enabled.

6.2 Over-the-air update integrity

Every OTA update follows the same atomic pattern:

1. Discover — the box queries storage.googleapis.com/gluearrow-box-os-releases/latest.json. The manifest is signed at release time.
2. Download — the box fetches the new sidecar or full image over HTTPS.
3. Verify — the box computes SHA-256 of the downloaded artifact and compares against the value in the manifest. Mismatch → reject and retain current version.
4. Stage — the new artifact is staged on disk without replacing the running binary.
5. Atomic swap — on next launch (Windows) or next reboot (appliance), the new version takes over.
6. Rollback — if the new version fails to start (fails health check within 60 seconds), the system automatically reverts to the previous version.

A malicious payload intercepted between storage.googleapis.com and the box cannot be installed unless the attacker also controls the release manifest's signing key.

6.3 Third-party dependencies

The engine uses approximately 45 direct Python dependencies. Each build produces a Software Bill of Materials (SBOM) enumerating name, version, license, and known CVEs. The SBOM for the current release is available on request from security@gluearrow.com and is published alongside each release on the downloads page.

Critical dependencies (Flask, Flask-SocketIO, gevent, psycopg2, FFmpeg) are tracked against upstream security advisories. The patch SLA for critical vulnerabilities in these dependencies is 14 days from public disclosure.

---

7. Monitoring, Logging, and Audit

7.1 What is logged

Event class	Location	Retention
Engine lifecycle (start, stop, crash, watchdog)	systemd journal (Linux) / Windows Event Log	Rotated per OS policy
Authentication events (logins, failed logins, role changes)	Local SQLite + cloud mirror	365 days in cloud
Admin actions (schedule edit, ad approval, user invitation)	Local SQLite + cloud mirror	7 years in cloud
Proof-of-play detections	Local SQLite (ledger) + cloud mirror	7 years in cloud
API access logs	Local file + optional SIEM forwarding	Configurable
RTMP stream start/stop	Local SQLite + cloud mirror	90 days

7.2 Proof-of-play integrity

Proof-of-play is the platform's most sensitive record — it determines advertiser billing and royalty payouts. Each ledger entry captures:

• NTP-synchronized wall-clock timestamp
• The detected item's identifier
• The source of the detection (broadcast audio fingerprint, ad slot trigger, DJ software cue)
• Station identifier and sync state

The ledger is append-only and mirrored to the cloud on the next sync cycle. The cloud retains a durable record independent of the box; reconciliation between the box-local ledger and the cloud mirror surfaces any missing, duplicated, or post-dated entries for investigation.

Roadmap — cryptographic chaining (target: 2026 Q3): a tamper-evident hash chain that links each ledger entry to its predecessor, so any local modification invalidates the chain for every subsequent entry. This is a disclosed roadmap item, not a current capability. Customers requiring cryptographic audit trails today should enable SIEM forwarding (§7.4) for an independent log of record.

7.3 Prometheus metrics

The engine exposes a Prometheus-compatible /metrics endpoint. Customers integrating with their own monitoring can scrape the engine directly. Metric categories:

• Engine health: memory, CPU, thread count, watchdog state
• Broadcast state: current source, RTMP state, HLS segment production rate
• Sync state: cloud reachability, queued items, last successful sync
• Business metrics: ads played, detections recorded, streams delivered

7.4 SIEM integration

Linux deployments can forward the systemd journal to any SIEM that accepts syslog or structured JSON (Splunk, Elastic, Datadog, Sumo Logic, Chronicle). Sample forwarding configurations are available from support on request.

---

8. Secrets Management

• Secrets (database passwords, API tokens, license keys) are stored in the environment file (.env on workstation deployments, /etc/gluearrow-box-os/environment on Linux, encrypted by Korra OS on the appliance).
• The environment file is owned by root, readable only by the gluearrow service account, and never committed to source control.
• Cloud-side secrets (database passwords, third-party API tokens for the cloud services) live in Google Secret Manager with IAM-controlled access and audit logging.
• Secret rotation is supported without service restart for non-database secrets; database credential rotation requires a 30-second reconnection window.

---

9. Business Continuity

9.1 Offline operation

The platform's most important security and availability property is that it continues to operate when isolated. The box serves its LAN, continues RTMP delivery to configured destinations, logs every play to the local ledger, and caches all cloud-bound events for replay on reconnection.

Tested failure modes:

• Cloud unreachable — station broadcast and local control continue indefinitely; cloud ledger receives a catch-up push on reconnection.
• Station internet unreachable — identical to the above, plus RTMP destinations unavailable until internet returns.
• Box local power loss — on restart, the engine resumes from the last persisted schedule and replays pending cloud events.
• OTA update failure — automatic rollback to the previous known-good version within 60 seconds; no operator intervention needed.

9.2 Backup

• Local SQLite state files are snapshotted by the engine every 60 minutes. Snapshots are retained for 7 days locally.
• Enterprise tier customers receive nightly cloud-side backups of the ledger and configuration state, retained for 30 days.
• Full disaster recovery: a new box paired with the same license key recovers its configuration and ledger from the cloud mirror.

---

10. Vulnerability Disclosure and Incident Response

The full Vulnerability Disclosure Program (VDP) is published at https://gluearrow.com/security (document identifier GA-VDP-1.0). The summary below is consistent with that program; the canonical text governs in case of any discrepancy.

10.1 How to report a vulnerability

Email security@gluearrow.com with:

• A description of the issue
• Steps to reproduce
• Affected version
• Your contact information (PGP key available on request)

10.2 Our commitment

• We acknowledge all reports within 3 business days.
• We validate and triage within 10 business days.
• Critical vulnerabilities are patched in a coordinated release within 30 days of validation.
• High-severity vulnerabilities are patched within 60 days.
• Medium- and low-severity vulnerabilities are patched in the next regular release.

10.3 Coordinated disclosure

We support a 90-day coordinated disclosure window. Public disclosure follows the patch release. Researchers are credited in release notes unless anonymity is requested.

10.4 Safe harbor

Good-faith security research conducted in line with this policy will not result in legal action. Activities explicitly permitted:

• Testing against your own deployment
• Automated scanning at reasonable rates (no more than 100 requests/second per box)
• Responsible reverse engineering of binaries for research purposes

Activities explicitly prohibited:

• Testing against third-party production deployments without their permission
• Exfiltrating data beyond what is needed to demonstrate the issue
• Denial-of-service attacks against production infrastructure

---

11. Compliance Posture

11.1 Current state

• GDPR — the platform is designed for GDPR compliance. A Data Processing Agreement (DPA) is available for EU customers. Data minimization, right to erasure, and data portability are supported.
• CCPA / CPRA — similar posture; DPA available.
• PCI DSS — the platform does not process payment card data. Billing is handled by upstream payment processors out of scope for the platform.
• COPPA — the platform does not knowingly collect data from minors.

11.2 Roadmap

• SOC 2 Type I — target: 2026 Q4. Readiness assessment in progress.
• SOC 2 Type II — target: 2027 Q3, following 6+ months of Type I operation.
• ISO 27001 — target: 2027 Q4.
• Regional data residency (EU, Africa, Asia-Pacific) — available on request for enterprise tier in 2026 Q3.

Enterprise customers may request quarterly briefings on compliance progress.

---

12. Security Controls Summary Table

For procurement questionnaires, the following is a condensed control overview. Cross-referenced to industry frameworks where applicable.

Control domain	Implementation	Framework reference
Access control	SSO, MFA, RBAC (4 roles), short-lived sessions	ISO 27001 A.9, SOC 2 CC6
Authentication	OTP, SAML, MFA for privileged roles	NIST SP 800-63B AAL2
Encryption at rest	AES-256-CTR for encrypted audio archives; OS-level file permissions for state DBs	SOC 2 CC6.7
Encryption in transit	TLS 1.2 minimum, 1.3 preferred	SOC 2 CC6.7
Logging and monitoring	Structured logs, Prometheus metrics, SIEM forwarding	SOC 2 CC7.2, ISO 27001 A.12.4
Change management	Code review, CI/CD, signed releases	SOC 2 CC8
Incident response	Published VDP, 90-day disclosure, documented SLA	SOC 2 CC7.4, NIST SP 800-61r2
Software supply chain	Signed OTA, SHA-256 verification, SBOM per release	SLSA Level 2 (target: Level 3)
Business continuity	Offline-first architecture, A/B partitions, automatic rollback	SOC 2 A1
Data minimization	No continuous raw audio to cloud; detection metadata only	GDPR Art. 5(1)(c)

---

13. Requesting Further Information

• General security questions: security@gluearrow.com
• Procurement and enterprise contracts: enterprise@gluearrow.com
• Data Processing Agreement (DPA): available on request
• SBOM for the current release: available on request
• Penetration test summary: available under NDA for qualified enterprise prospects

---

GlueArrow Inc. — 1111B S Governors Ave # 50266, Dover, DE 19904, United States Document identifier: GA-SECWP-1.0 · Last reviewed: 2026-04-24 · Next scheduled review: 2026-07-24