Platform security · attack surface, image integrity, patch cadence, what the data plane records

Infrastructure Brief · Platform Security

What is in the image, and how fast it changes.

A BNG sits between every subscriber and the internet, which makes it the most security-sensitive box in the access network and the one a vendor-security review will scrutinise hardest. This brief covers the three things such a review actually asks: how small the attack surface is, whether the running image can be trusted, and how quickly upstream vulnerabilities become a shipped fix.

The strongest security property of a carrier image is not what it defends against — it is what it does not contain.

Attack surface: hardened by omission

OrionOS is a purpose-built carrier image rather than a general-purpose distribution with a BNG installed on top. It ships the kernel, the XDP forwarding path, the BNG daemon and very little else. If a package, shell service or daemon is not required to run a BNG, it is not in the image.

That single decision removes most of the CVE surface a general-purpose distribution carries. A vulnerability in a package you never shipped is a vulnerability you never patch, never test and never explain to a customer.

Image integrity

Signed image, RAM root, known-good on every boot

Boots from a signed image into a RAM root
Every reboot returns the node to a known-good state
The data-plane binary comes only from the built boot image — there is no path for an ad-hoc local modification to survive

Reproducibility

One artefact, identical on every node

The whole platform is built from source into a single artefact and flashed
The same image, verifiably, on every node in the fleet
Configuration drift between nodes cannot alter what code is running

Why this matters more than it sounds. On a conventional platform, “what version is node 47 running?” is a question with an uncertain answer — packages drift, someone patched something by hand during an incident, a config-management run half-completed. With a single flashed artefact and a RAM root, the question has one answer and a reboot enforces it.

Patch cadence: the record, not the promise

Anyone can state a patching policy. The useful evidence is the shipping history. Three consecutive releases from recent weeks:

Release	Date	Notable content
6.53	4 Sep 2026	Kernel 7.2.3 · nftables 1.1.7 · libnftnl 1.3.2 · FRR 10.4.5 · curl 8.22.0 · nginx 1.31.5 · Python 3.14.7/20260901 · Redis 8.8.2 · expat 2.8.4 · libpcre2 10.48 · util-linux 2.42.3
6.47	19 Aug 2026	RADIUS Acct-Input/Acct-Output reported in the wrong direction · BNG drops a single session instead of the whole service when memory runs out
6.46	18 Aug 2026	Kernel 7.2.0 · expat 2.8.3 · procps-ng 4.0.7 · nano 9.2 · IPv6 pool add/remove on reload without restart · VLAN delete while still in use

Two observations a security reviewer can verify from that table. 6.46 and 6.47 shipped on consecutive days, 18 and 19 August. And the Python build dated 1 September shipped in a release on 4 September — a three-day turnaround on an upstream snapshot.

Patch on your schedule, not a hardware vendor’s. Because the data plane is software on commodity x86, a security fix is a software change you build and ship — not a line-card refresh, not a chassis maintenance window negotiated months ahead, and not a wait for a silicon vendor’s next release train.

What the data plane records

CGNAT creates a regulatory obligation before it creates a technical one: given a public IP, a port and a timestamp, an operator must be able to identify the subscriber behind them — and nothing else should be required to answer it.

Event	Contents	Purpose
Port-block allocation	Subscriber identity, public IP, port range, timestamp	Opens the attribution window
Port-block release	Same block, release timestamp	Closes the window
Per-flow translation	Private IP / session identity, public IP, port, protocol	Optional finer granularity
IPv4 & IPv6 flow events	Standard flow records	Dual-stack coverage

Export is over IPFIX/NetFlow and syslog — standard transports into whatever collector and retention system you already operate. Block-based allocation logging is deliberately chosen over per-flow-only logging because it answers the attribution question at a fraction of the storage volume.

What is yours and what is ours. We produce the records and export them over standard transports. Retention periods, storage location, access control, lawful-intercept handover format and the legal basis for processing are the operator’s responsibility and vary by jurisdiction. Nothing in this brief is legal advice, and it should not be treated as a compliance certification for any specific regime.

What we do not claim

A formal security certification	No	We hold no Common Criteria, FIPS or equivalent certification and do not imply one.
Compliance with a named regime	No	We produce the records a retention or intercept obligation needs. Mapping them to your legal regime is yours.
Zero CVEs	No	We ship a kernel and userspace. What we claim is a small surface and a short interval between upstream fix and shipped release.
A verifiable patch record	Yes	Release contents and dates are published and checkable against upstream release dates.
Reproducible images	Yes	Built from source into one artefact, flashed identically across the fleet.

Bring your vendor-security questionnaire

If your security team has a standard assessment, send it. Questions we cannot answer honestly we will say so about, rather than returning a form with every box ticked.

Release contents and dates are drawn from the BNGSOFT platform release record. Upstream version numbers are those shipped in the referenced releases and can be checked against the corresponding upstream projects’ own release dates. Logging behaviour describes BNGSOFT data-plane output; retention, storage, access control and regulatory mapping are the operator’s responsibility. This brief is not legal advice and is not a compliance certification.