Radiator software security and dependency compliance

Radiator scans dependencies for known vulnerabilities before release. Radiator builds also produce reports that list open source components and scan results.

At a glance

Technology overview

Radiator Server is implemented in Rust and TypeScript. Rust prevents many memory corruption problems in safe Rust. These problems include buffer overflows, use-after-free errors, and data races.

Radiator UI is implemented in TypeScript and React. Radiator Server does not require or include Node.js at runtime.

Binary hardening

Linux release binaries for amd64 and arm64 are statically linked position-independent executables (PIE) with a non-executable stack and full read-only relocations (RELRO).

• Position-independent code lets the operating system load the program at a random address. This is address space layout randomization (ASLR).
• Static linking means the binary loads no shared libraries at run time. Library versions installed on the host do not change its behavior.
• A non-executable stack prevents code placed on the stack from running.
• Full RELRO makes the tables that the program uses to call functions read-only after start-up, so they cannot be overwritten to redirect calls.
• Each Linux release binary embeds the list of Rust dependencies it was built from. Vulnerability scanners that read this list can check a deployed binary without the source code.

The packaged systemd service runs Radiator Server as a dedicated system user, not as root. The only extra permission the service grants is listening on ports below 1024. See Linux systemd support for the service settings.

Vulnerability scanning

Continuous integration (CI) checks application dependencies against public vulnerability databases.

Rust dependencies are scanned with cargo deny against the RustSec Advisory Database. JavaScript and TypeScript dependencies are scanned with pnpm audit. A reported vulnerability or an incomplete scan fails the build.

Security testing

Radiator Server is tested regularly with an automated security assessment. The assessment runs the release binary with example configurations that Radiator Software provides. It covers these areas:

• Binary hardening properties
• TLS configuration of the RadSec, TACACS+ over TLS, and management HTTPS listeners, including client certificate validation for RadSec
• Malformed RADIUS packets, and the results of the nightly coverage-guided fuzzing of RADIUS, TACACS+, Diameter, and EAP message handling
• RADIUS Message-Authenticator handling (BlastRADIUS, CVE-2024-3596), also with the automated test of the mitigations, run against the release binary
• Radiator UI and management API: dynamic web application scanning, session handling, and authorization of each documented API operation for each management privilege
• Recovery from connection floods and slow clients
• Known vulnerabilities in the third-party components compiled into the binary, identified from the component list that the binary contains

The assessment is automated. It is not a third-party penetration test. Its results describe the tested build and configurations.

Important: The security of a deployment also depends on its own configuration. Radiator Server opens only the listeners that the configuration defines, and the configuration sets which clients can connect, which TLS and authentication settings apply, and who can use Radiator UI and the management API.

Build reports

Artifact and documentation builds create reports for their exact source revision:

• Open source compliance report lists third-party Rust and Radiator UI runtime dependencies. It includes each component's version, license expression, and source.
• Dependency vulnerability scan contains the vulnerability scan result and scanner output.

Dependency update policy

Dependencies are reviewed and updated regularly. If a Common Vulnerabilities and Exposures (CVE) entry affects Radiator, the dependency is updated and a fix is released. Advisories that do not affect Radiator's use are tracked until an upstream fix is available.

Build and release integrity

Dependency versions are pinned. Updates require a reviewed source change. Release artifacts are traceable to a source revision. CI applies code review, automated tests, lint checks, and vulnerability scans before release.

Maintenance scope

Standard service covers fixes in actively maintained release lines. Backporting fixes to older or end-of-life versions is available as a separate support engagement.