The feature of code signing was introduced in Java to provide an alternative mechanism for granting elevated privileges to code depending on the security policy in effect. For example, Java applets that need to read system properties from a user's machine can escape the default sandbox restrictions by prompting the user with a security dialog, about whether the party that signed the code is considered trustworthy. This element of trusting the signature allows applets to escape the default security sandbox restrictions. On the other hand, in the presence of with applications that use a custom security policy, explicit permissions need to be granted to the particular codebase and optionally, the signer. This has the benefit of ensuring that only trusted signed code runs with the specified privileges.
...
In general, there is a misconception that signed code is safe to be executed. The problem manifests itself when a vulnerability is discovered in signed code. As many users choose the option of permanently trusting the organizations that they have full confidence in, they are not notified if an adversary offers them the vulnerable software with the intentions of exploiting it. Consider, for example, signed Java applets. Whenever a certificate is verified to be correct (as opposed to being self-signed or tampered), the user is confronted with a security dialog that has the check box option of "Always trusting trust the content from the publisher" turned on. Unfortunately, this setting overrides any future warning dialogs about potentially vulnerable software versions from the respective organization.
...