...
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 (as in guideline rule 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 rule SEC17-J. Create and sign a SignedObject before creating a SealedObject.)
Signing unprivileged code is unnecessary; avoid doing so. See guideline rule 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.
...
Search for vulnerabilities resulting from the violation of this guideline rule on the CERT website.
Bibliography
...