This is not a bug, it is a feature.
As Anthony Wong says, when you install a DKMS package you are compiling the package yourself, thus, Canonical cannot sign the module for you.
However, you can definitely use Secure Boot, however this is exactly the use case where Secure Boot is trying to protect you from yourself because it cannot know whether you trust a module or don't.
By default, there is a Platform Key (PK) on your UEFI machine, which is the ultimately trusted Certificate Authority for loading code in your processor.
GRUB, or shim, or other boot mechanisms can be digitally signed by a KEK which is trusted by the root CA (PK), and thus your computer can, without any configuration, boot software like Ubuntu Live USB/DVDs.
On Ubuntu 16.04 the kernel is built with CONFIG_MODULE_SIG_FORCE=1, which means that the kernel will enforce modules to be signed by a trusted key in the platform.
Take into consideration that the UEFI platform by default contains a PK that you do not have any control over, and thus you cannot sign binaries with a key recognized by your own machine.
Some people bash and rant against that, but there is really no better way (from a security standpoint) than it being yourself who enrolls the new key you want.
If your boot system uses shim, you can use something called a Machine Owner's Key database, and enroll your key as a MOK (You can do that with mokutil). If you don't, you can also enroll your key in the UEFI database as a signing key.
After you enroll your key, you can sign your DKMS-built package with your MOK (there should be a perl script at /usr/src/kernels/$(uname -r)/scripts/sign-file), and after it is signed, you can load it into the kernel.
Granted, someone should make more visual instructions on this, and probably even make a wizard or a better DKMS standard to allow keys to be taken into consideration, but this is what we have as of now.
You can refer to this explanation on how to sign your own kernel modules: https://askubuntu.com/a/768310/12049
I believe your understanding is correct, except that shimx64.efi is delivered in binary form via a package, not generated locally via grub-install. (grub-install is likely to install shimx64.efi to the ESP, though.) Oh, and it's MokManager, not MoakManager.
Before you file a bug report, you should retrace your steps and be 100% sure that you're booting via your locally-compiled GRUB. It's easy to accidentally put a binary in the wrong location or neglect to run efibootmgr to adjust the boot order, for instance. (You haven't described how you're installing your custom grubx64.efi -- are you overwriting the standard Ubuntu binary or putting your new one elsewhere and registering it [and a copy of Shim] via efibootmgr?) You might want to run sudo efibootmgr -v to see your boot details. Pay attention to the BootOrder and BootCurrent lines -- the former tells you the order in which boot options will be tried and the latter shows the option that was used to boot the computer. You'll need to cross-reference the numbers with the various Boot#### lines that describe each boot option. If you installed your own GRUB separate from Ubuntu's GRUB, it's conceivable that the firmware silently bypassed it because of a Secure Boot error and then fell back on the stock Ubuntu Shim/GRUB, which would explain what you're seeing.
Another possibility is that Secure Boot is not actually enabled on your computer. You can check this possibility as follows:
$ hexdump /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
0000000 0016 0000 0001
0000005
In this example, the first line of output (0000000 0016 0000 0001) ends in a 1. This indicates that Secure Boot is active. If it ends in a 0, then Secure Boot is disabled on your computer.
One other possibility is that you might have somehow installed your local key in the firmware's own db list. This is a difficult task, though, so it's unlikely you've done it accidentally and without realizing it. (See my page on the subject for details on how to set this up.) I mention this possibility mainly for the sake of completeness; it doesn't strike me as likely at all unless you're omitting mention of a previous attempt at mastering Secure Boot in this way.
If you are seeing a bug, it could be in either Shim or in your firmware.
One more caveat is that I'm only passingly familiar with GRUB-specific tools such as grub-mkstandalone. As I maintain rEFInd, I prefer to use it, so my knowledge of GRUB tools isn't as in-depth as it might be. Thus, I might be missing some critical detail because it's GRUB-specific.
Best Answer
Only the software involved in the boot process is checked by secure boot.
The bootloader (Ubuntu uses
grubin UEFI mode) and the kernel are checked; they should match a signature. I think also kernel drivers are checked, and unsigned drivers will be blacklisted, which might exclude some proprietary drivers for graphics and wifi.Other software is not checked by the secure boot feature. This includes regular application programs, both command line (text mode) programs and graphics mode (GUI) programs , but also drivers for software, that are not kernel drivers and other help programs that can run in the background.
Secure boot is not enough to keep you safe. You must use other methods to avoid malware. Install programs from the Ubuntu repositories and maybe from well-known PPAs, but avoid programs from any random website (unless you have the source code and understand it). Remember that also websites and document files can be infected by malware.