No. The keys does not need to be transmitted securely, but of course you must transmit them in a such way so they can't be replaced or tampered with, if you want to protect against someone distributing malicious data.
So lets say you are hosting a software repository. Even if you sign a software with your key, if a hacker gains access to the repository, he could upload malicious software AND also replace the "correct" signing keys with her own public keys, so if a end user validates the software, it will come out as valid. That is what the OP is asking.
In the same way, a attacker could replace keys during transmission (MITM attack), so if a user does http://www.example.org/signing_key.asc the MITM can replace the response with his own public key.
So simple signing of software and publishing the key on the software vendor's site, is more aimed to protect against mirrors getting hacked and starting to distribute malicious data.
Thats why some vendors just publish the SHA/MD5 hash of the software, thus the vendor does not need to completely rely on the security of the third-party mirror's.
Thats why its a good idea to transmit the keys using SSL, or have the key signed by a reputable origin (then it becomes a certificate, could be either a x509 one or a PGP one) if you also want to protect against malicious public key replacement.
Another way to protect against this, is that the end user does download and save the key during first interaction. Thus, if the repository later become compromised, the end user will have a saved "correct key", thus it does not matter if the key later become replaced, either during a MITM or hack attack.