Ah, the military. I guess if the policy is written to not permit you to use non-Flash USB boot devices you're out of options (the GBW will format an external USB hard disk to be bootable just as well as it does a memory stick, for what it's worth).
> Is there no way to cut the number of drivers loaded to, say, 4?
You can cut it down a fair bit, but a lot of the drivers are preinstalled in PE with their files added to Windows\System32\drivers already, and so to get them out you need to unpack the WIM and then go through the INFs by hand to identify the files to chop out of Windows\System32\drivers. There's quite a bit more of the OS you can cut out too if you don't need it (for instance the WinPE-256 build in the WIM doesn't have WMI or some other parts of the OS).
Unfortunately it's tedious work and it requires a lot of manual testing as you cut things out to make sure you haven't damaged things, so it's a delicate balancing act. The WinPE-256Mb build we include in our WIM has already had some of this done to it to get it able to boot Vista on 256Mb machines from a RAMdrive, but the problem we faced in doing that is that for almost everything we cut out we'd have a customer who would end up complaining about the fact that their process required component X and why wasn't it working. So, our WinPE build tends to include lots of the standard Windows utilities just because we have to strike that balance.
It may be that the best process if you aren't using the management console and really want to squeeze things down a LOT is to work with vLite on a standard WinPE build to cut it down to the bone and then merge in the Ghost components to get a replacement for the standard WIM; no matter what you do there's a lot of tedium involved. Other than the fact there are two versions of WinPE inside the one WIM, the most important thing about the pre-built WIM included with GSS is that the Windows Firewall is completely turned off (whereas in the WAIK versions of PE it's on by default).
> Unless LiveUpdate can be done manually
We've generally always supported users on military and commercial secure networks by having LiveUpdate download our own install package which can be copied to other machines, rather than have LU just apply the updates directly as it does with AV. Normal LiveUpdate uses a digital signature system for the packages it downloads to ensure the download integrity, and for Ghost LiveUpdates we package either the installers or patches inside a single executable which we then digitally sign with the same code-signing keys we use on the main product.
For anyone with GSS installs off the main internet, just install a GSS management server instance on a machine which does have access to the public internet (you don't need to license it) and launch LiveUpdate from the console's Help menu. That will run LU in a context in which it should download the update package to the desktop, so you can save it and transport it elsewhere, and since it's easy to verify the package digital publisher signature that can be used to create a process to verify it's genuine as part of moving it to the secure environment.
[ Incidentally, although this works really well it can sometimes come unstuck on machines with Symantec Endpoint Protection installed - SEP turns out to configure LiveUpdate quite oddly and so on machines with SEP installed, if one of the SEP services trigger the update before it's done manually through the GSS console what happens is that the SEP-triggered LU downloads the GSS update package to an invisible user's desktop, and it doesn't get applied. However, LiveUpdate thinks it has downloaded and run the package so if you manually trigger LU, it tells you everything is up-to-date. ]