views:

163

answers:

4

I would like to incorporate scanning for viruses into a Java/Maven/Hudson build process. Unfortunately, i could not find any resources on dedicated tools for this kind of build step. My build environment is Linux-based.

My question is: How can antivirus scanning be incorporated into a Maven and Hudson based build process?

What are the best-practices?

  • Should the scanning step be separate of the normal build, e.g. a pre-build step or even a separate build job?
  • Should the scanning occur at a later stage of packaging, after all the artefacts have been packaged to jar files or early in the process?
  • Should each released artefact include a scanner log file which determines the antivirus tool being used, version and date of virus definition files?

Which anti-virus software to use is out of scope of this question. (E.g. i'd like to use a commercial vendor in favor of free tools like ClamAV)

+1  A: 

Where can the virus come from?

I've yet to see a virus which can modify source code, so the source is probably safe (well, unless you can't trust your developers).

So the virus can hide in one of the build tools and try to modify the JAR. The tool at hand here is tripwire: It will create checksums for all the files and the build tools should not change (unless you install a new version; then you have to run tripwire again).

If the build tools are safe, you just need a AV tool which protects the OS (so functions like opening and writing files are safe). Use the standard AV of your company for this.

To make the whole process really tight, you can build the last release again before you build the new release. The checksums of the old release shouldn't change (beware of timestamps in the files, though).

Aaron Digulla
Nice idea with the checksums. However, the build tools are not of my concern, rather external libraries which are incorporated into the released artifact.
mhaller
Same approach: Check them with your virus tool once, create a checksum and verify it during or after the build.
Aaron Digulla
+1  A: 

Best practice is to run your builds on a platform (i.e. operating system) that is infrequently targeted by viruses.

Best practice is to run the an anti-virus scanner at the OS level on the build platform.

Best practice is to keep up to date with your OS patches, lock down your firewall, and don't mount USB keys that might have been infected on your home network, etc.

I've never heard of viruses that "infect" source code, .class files or JAR files. I suppose they are possible, but there's a good chance that a commercial AV product won't notice them because they are unusual. Certainly, an AV product won't help is the virus is specifically targeted against you / your company.

But assuming that you do have an AV product that you think will work, you could just do an AV scan just before you spin a "release build". I'm not aware of anything plugins that will do the job automatically, but it shouldn't be hard to get Maven to run "some batch file" that happens to invoke the virus checker via its command line.

Stephen C
A: 

You need a scriptable anti-virus program.

When you have that, it should be easy to add a "scan what I just built" step.

I believe McAfee has a Linux version which might be just what you need.

Thorbjørn Ravn Andersen
A: 

How can antivirus scanning be incorporated into a Maven and Hudson based build process?

If really this is a concern, I think your security team should force you (and maven) to go through a proxy running some kind of antivirus. This would be the right way to do things.

But, in my opinion, the probability to get malicious code from repositories is close to zero, especially with widely used libraries (there are so many users, I doubt no one would notice a problem before you get that code) and I bet that the probability to get infected by (web)mail, USB key, downloaded software is much more higher. I know that's not an answer but seriously, security policies are sometimes ridiculous.

Pascal Thivent
1) Of course AV tools (incl. proxy) are already in place. However, since we provide commercial software to our customers, i'd like to think about adding a log to show that we have checked everything in there to be clean. For example, CNet is doing the same for all the downloads they offer. It's a service, and imho, a good one. It makes me feel better. (http://www.cnet.com/1991-13403_1-6722508-4.html?tag=contentMain;contentAux) 2) I have no idea how probable it is that public repos get infected. But there are checksum errors and it takes time to find and fix them (see MEV-636 at codehaus.org)
mhaller
CNET is distributing executable binaries, I don't think it's really comparable. And if you already have an AV running at the proxy level, you won't find anything more during the build. Just generate an dumb text file in that case, it has the same value and, at least, it won't slow down your build.
Pascal Thivent