Common causes for Similar matches / Component-Similar policy violations

Application Components that are similar, but not identical to known/catalogued components can produce "similar" matches in an Application Report, which usually result in a "Component-Similar" policy violation. Such policy violations are caused by a component with a "Similar Match". Unexplained similar matches should be treated as a serious problem by the development team, because it could mean the application is using a maliciously altered copy of a component.

Checksum Sanity-check:

If the reason for a similar match is not immediately obvious, start by manually downloading the component in question, and then comparing the sha1 hash of the manually downloaded file to that of the similar-matched component file. The "Occurrences" tab in the CIP will help you locate the similar matched file in your build. If the checksums are different, the component is indeed different from the "official" version. The challenge now is to explain why they differ.

Common causes:

  1. New component version / Missing component version - One indicator that a Similar match is due to a "new component version" is the version graph in the CIP shows no (or very few) version(s) newer than the detected similar version. Typically the new version of a component is very similar to previously cataloged versions, but is not identical to any version we've cataloged before. New component versions are automatically identified, but it is possible some could get missed. Reporting such an issue to product support is the best way to ensure it is corrected.
  2. Repackaging / Signing of the component - If your build is repackaging (e.g. unpack, tweak stuff, repack) the component, this would result in a similar match because the end component is different. Jar signing is an example of such an alteration. The solution here could be to evaluate your application before such alterations are made. It is also possible your build has downloaded an already altered component from someplace else. If so, the source of the component should be verified, and possibly changed to use an "official"/"unmodified" component.

Similar match components can also affect policy violation notifications. Policy Violation notifications are only sent when "new" violations occur. Since "similar" matches are different from the official component, they are treated as "new" components, and as such will trigger new policy violations. This can be confusing if a build alters a component every time the build is run, resulting in a new policy violation notification that looks identical to prior notices. The policy violated column in the email list of violations (the first column) will likely show the "Component-Similar" policy.


Have more questions? Submit a request


Article is closed for comments.
Powered by Zendesk