That's separate from the idea that the list might be maliciously crafted to exploit an overflow and gain root privileges (which presumably could bypass signing checks) -- if your threat model involves loss of control of FreeBSD's signing keys, pkg running as root is irrelevant. You can't ever trust anything outside the box, or update at all. No binary is trustable and even if you heavily audit the source you're in trusting-trust territory.

(also the only key that matters is the Security Officer's key for vuln disclosures -- not any random maintainer has signing authority)

The only possible defense is to turn off security updates entirely, and empirically, that is much higher risk. I can think of cases where signed and approved security updates have introduced regressions to valid use cases (e.g., LP #1058343 bit me badly at my previous job), not fixed a problem (e.g., the day after Shellshock came out), etc.... But I cannot think of a single case where a signed and approved security update, by an OS making even minimal attempts to have a decent process around updates (so, anyone better than Linux Mint), has been actively harmful.

Given that an operating system security update, by definition, is capable of changing the most privileged code on your system, there's no way to program it defensively. It needs to have the ability to make arbitrary changes your system (and thus the theoretical ability to trash your system) in order to be able to fix unforeseen bugs.