...
First, users have no idea how to decide if a particular signer is trusted or not. Second, just because a component is signed doesn't mean that it is safe. Third, just because two components are individually signed does not mean that using them together is safe; lots of accidental harmful interactions can be exploited. Fourth, "safe" is not an all-or-nothing thing; there are degrees of safety. And fifth, the fact that the evidence of attack (the signature on the code) is stored on the computer under attack is mostly useless: The attacker could delete or modify the signature during the attack, or simply reformat the drive where the signature is stored."
Code signing is designed both to authenticate the origin of the code, as well as to verify the integrity of the code. It relies on a Certification Authority (CA) to confirm the identity of the principal signer. Naive users should not be expected to understand how certificates and the Public Key Infrastructure (PKI) work.
Users commonly associate digital signatures with safety of code execution, and so trust trusting the code to cause them no harm. The problem arises when a vulnerability is discovered in signed code. Because many systems are configured to permanently trust certain signing organizations, those systems fail to notify their users when downloading content signed by the trusted organization, even when that content contains vulnerabilities. An adversary may attacker can offer the users legitimately signed vulnerable content with the intention of exploiting that content.
Consider, for example, signed Java applets. When a certificate is verified, on widely used platforms, the user is presented with a security dialog in which the option "Always trust the content from the publisher" is selected by default. The dialog primarily asks whether the signed code should be executed or not. Unfortunately, if the user confirms the dialog with the check box selected, the "Always trust..." setting overrides any future warning dialogs. An adversary may attacker can take advantage of this mechanism by supplying vulnerable code signed by the trusted organization. In this case, the code will execute with the user's implied permission and may can be freely exploited.
An organization that signs its own code should not vouch for code acquired from a third party without carefully auditing the third party code. When signing privileged code, ensure that all of the signed code is confined to a single package (See as in guideline ENV01-J. Place all privileged code in a single package and seal the package for more information), and also that any code invoked from the privileged code is also contained in that package. Non-privileged code should be left unsigned, restricting it to the sandbox. Additionally, avoid signing any code that is incomprehensible or unaudited. (See guideline SEC17-J. Create and sign a SignedObject before creating a SealedObject.)
Signing unprivileged code is unnecessary; avoid doing so. See guideline SEC00-J. Avoid granting excess privileges. For instance, unsigned applets and JNLP applications are granted the minimum set of privileges and are restricted to the sandbox.
...
ENV00-EX1: An organization that has an internal PKI and uses code signing for internal development activities (such as to facilitate facilitating code-check-in and tracking of developer activity) may sign unprivileged code. This codebase should not be carried forward to the production environment. The keys used for internal signing must be distinct from those used to sign externally available code.
...
Signing unprivileged code violates the principle of least privilege as because it can circumvent security restrictions defined by the security policies of applets and Java Network Launch Protocol (JNLP) applications, for example.
...
Detecting code that should be considered privileged or sensitive requires programmer assistance. Given identified privileged code as a starting point, automated tools could compute the closure of all code that may can be invoked from that point. Such a tool could plausibly determine whether a body of signed code both includes that entire closure and also excludes all other code.
...