I came to this discussion while trying to validate kexts migrated from 10.13 to 10.15 which weren't loading. I seem to have found an explanation and a workaround.
The kexts were valid for 10.15 but hadn't been installed under 10.15, as they arrived with a system migration. I assume the same problem would occur with an OS upgrade. (It goes without saying that I'm deeply disappointed in Apple for not foreseeing this eventuality.)
I came across the following advice regarding installing SATSMART drivers in the FAQ on binaryfruit.com which has some relevance to the question:
How to rebuild macOS kernel extensions/driver cache
When the macOS boots – it saves all currently used kernel extensions (drivers) into a cache for faster booting next time – and if you move
things around in “/Library/Extensions/” and
“/System/Library/Extensions/” – you won’t see those changes reflected
until the caches are rebuilt. Also, due to bugs in some versions of
macOS – kext cache becomes outdated or corrupted, especially in the
case of system upgrades. Manual kext cache rebuild could fix many
troubles with drivers (kernel extensions).
Type in the terminal following commands:
sudo kextcache -i /
sudo kextcache -system-caches
The first command brings up a complete list of kexts that were not loading for a number of reasons - including (but not limited to) Kext rejected due to system policy meaning permission had not been granted in Security & Privacy - along with their locations.
In my experience, kexts blocked for reasons other than needing user approval show up here, even if they don't appear amongst Disabled Software.
Addressing the OPs original question more specifically regarding knowing who the kext developers are, since this may not directly correspond to the software branding, these can be parsed from package inspector apps such as Pacifist and then compared with the kext names output by the terminal command above.
My personal preference is to open an installer package in Suspicious Package, where the developer and their 10 character alphanumeric TeamID are easily readable. For kexts simply awaiting user approval this does, of course, correspond with the TeamID found in Disabled Software, as explained by the OP above. However, not only is this user friendly, it also exposes kexts that won't load for other reasons.
Once the TeamID is known, the kext can safely be approved in Security and Privacy when the blocked kext alert is next shown (eg when installing a different kext).
Not everybody wants to install a new kext in order to approve earlier ones and some sources (such as this MIT knowledge base) advise that a team ID can be granted kext approval via terminal commands in Recovery Mode, but I can't personally verify whether this works in a specific OS.