Static scanning: Determine how to handle native code

[Col-E]

If a jar bundles native code, how do we treat it?

I'm inclined to automatically mark as max sus level and let manual review (by user) decide. We can print the sha256 hash of each native file so users can easily search for it on maven central / virus total to check for authenticity

[0xAda]

I'd agree with marking it as high severity, maybe we could support a string/pattern scan, but I feel like even that is heading towards scope creep.

[Semisol]

I think yara and SSDeep should be good enough if we want to push this a bit far.

[Col-E]

I'm *heavily against including non-JVM tooling in our Java scanning tool. It expands the scope of responsibilities and complicated requirements. For instance:

• Do we bundle yara?
  • What OS are they on if we bundle it? Do we make multiple releases for each OS/Platform combo? Do we make a one-for-all release?
• Do we not bundle yara?
  • Does the user have it on their path?
  • Is it something we'd automate installing?

Hence why I'm inclined to say "hey, here are the hashes, make of these what you will" rather than delve into relying on bundling native applications we don't manage ourselves.

Later down the line we may be able to use Native4J once it is out of private alpha. If we just want to look at the import table we can use JavaPeParser for windows files. Not yet looked around much for Linux ELF files.