At a minute past three in the morning a FreeBSD server runs its nightly checks, as /etc/crontab has told it to since the day it was installed. One of them is pkg audit -F. It fetches the current list of vulnerable package versions, compares it with everything installed, and puts the result in the morning mail to root. On most mornings that part of the mail says very little, which is rather the point.
The switch for it sits in the script itself, 410.pkg-audit, which ships with pkg: security_status_pkgaudit_enable:=YES, period daily. Nobody installed a scanner for it, and nobody wrote a cron job. It is simply what a FreeBSD machine does at night.
That nightly check is the last link of a chain, and the more interesting links were forged long before the package reached the server.
What the package went through
Every package in the official repository starts as a port, a Makefile with its patches, and next to it a file called distinfo, which records the SHA256 sum and the size of every source archive the port needs. The porter creates it with make makesum, and from then on any archive that does not match is refused before a single line of it is compiled.
The project's build machines then run Poudriere, and Poudriere builds every port in a fresh jail, cloned for that one build and thrown away afterwards. Its sample configuration explains the next part in its own plain words: "The jails normally only allow network access during the 'make fetch' phase. This is a security restriction to prevent random things ran during a build from accessing the network. Disabling this is not advised." So the sources come in, are checked against distinfo, and then the line goes dead. Configure scripts and compilers run in a room without a telephone, and by default they run there as the user nobody.
At the end Poudriere writes an ordinary pkg repository, and with one line in its configuration, PKG_REPO_SIGNING_KEY, it signs it. The upstream author's code has now run exactly once, on a build machine cut off from the network, and never on the server that installs the result.
The jail doing this work is not a recent addition either. It appeared in FreeBSD 4.0 in March 2000 and has been part of the base system ever since, so the wall around every build has twenty-six years of production behind it.
The same job, distribution by distribution
Linux distributions are separate organisations, and the reason is a respectable one: each archive has its own volunteers and its own history, and each team chooses the tooling that fits. The result is that the question "was this package built without network access?" has a different answer depending on whom you ask.
Debian answers it in its Policy, as a duty of the package: "required targets must not attempt network access to other hosts." Alpine answers it in its build tool, where abuild rootbld runs the build under bubblewrap with --unshare-net unless a package declares options="net". Arch, as it happens, does not answer it at all. Its clean-chroot builder, makechrootpkg, runs the build in a systemd-nspawn container, and when I read the script and its helper arch-nspawn this morning neither of them passes --private-network. The sources are downloaded first, then the build runs with the host's network still attached.
And then there is the AUR, which a fair bit of the Arch world uses every day. The wiki is commendably frank: "These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk." The recipe is written by whoever uploaded it, the checksums inside it were set by the same person, and makepkg then does what the wiki describes: "This will download the code, compile it, and package it", on the user's own machine and under the user's own account, network included.
Each of these answers was chosen for a reason, and together they show what a system assembled by many organisations looks like when the same question goes to each of them. The bill goes to the administrator, who has to know where a package came from, and which builder made it, before they know what its build was allowed to do.
Your own packages, same rules
The FreeBSD chain does not stop at the project's own builders, which tends to surprise people. Poudriere is in the ports tree like any other program, and an administrator who needs nginx with a different set of options, or a port the official repository does not carry, builds it with exactly the same tool: fresh jail, network only for fetching, distinfo checked, build as nobody, repository signed. Bog-standard Poudriere, with the defaults the project uses for itself, and a private repository that pkg treats like the official one.
On the Linux side the equivalent exists for those who assemble it from a builder and a separate repository tool, and the assembly differs from distribution to distribution. On FreeBSD it is one program and one configuration file, and the guarantees come with the defaults.
The case every administrator remembers
On 29 March 2024 Andres Freund told the oss-security list that the xz release tarballs 5.6.0 and 5.6.1 carried a backdoor. It hid in a telling place. One part sat "solely in the distributed tarballs", a line in m4/build-to-host.m4 that the upstream git repository never contained, and it switched itself on only under conditions Freund spelt out: an x86-64 Linux build, "running as part of a debian or RPM package build", recognised by the presence of debian/rules or of RPM_ARCH. The attack was aimed squarely at the moment a distribution builds its package with the upstream's own build scripts.
FreeBSD carries xz in its base system, and its security officer could write on the same day that FreeBSD was not affected. The supported releases predated the bad versions; the development branch did carry 5.6.0, but "the backdoor components were excluded from the vendor import", and FreeBSD "does not use the upstream's build tooling, which was a required part of the attack". The base system builds xz with its own Makefiles from its own tree, and the ports collection had no second copy to worry about.
The payload needed no network, so the network switch played no part in this one. The vendor import and FreeBSD's own Makefiles did the work, which is the older habit underneath the whole chain: take the upstream's source, and build it the project's own way.
The limit
A checksum proves which archive was built. distinfo guarantees that the source is the one the porter examined, and the nightly pkg audit covers what a checksum cannot: its vulnerability list is kept by the same port committers who update the packages, and the morning mail names an affected version as soon as the entry is in.
Install scripts exist, and they live in the ports tree. A package may run a script when it is installed, to create a user or a directory. Those scripts are written by the port maintainer, sit in the port's directory as part of a public commit, and pkg's Lua scripts are restricted to the root they install into.
Bit-for-bit reproducibility is a project on every system. FreeBSD's base system builds reproducibly by default, and the build options name the switch that turns it off. For ports, every rebuild starts from a fresh jail and the same checked sources, which is the groundwork reproducibility needs.
A jail is a boundary, and Poudriere does not lean on it alone. The build inside the jail runs as nobody and without network, in a copy that is discarded afterwards, so a build that misbehaves meets several walls before it meets anything that matters, and any flaw in the jail itself is fixed through a FreeBSD advisory like every other part of the base system.
The safest part of installing a FreeBSD package is the part that happened before you typed anything.