构建过程中的病毒扫描
我想将病毒扫描合并到 Java/Maven/Hudson 构建过程中。不幸的是，我找不到任何有关此类构建步骤的专用工具的资源。我的构建环境是基于Linux的。
我的问题是： 如何将防病毒扫描合并到基于 Maven 和 Hudson 的构建过程中？
最佳实践是什么？
- 扫描步骤是否应该与正常构建分开，例如预构建步骤甚至单独的构建作业？
- 扫描应该在打包的后期阶段（所有工件都打包到 jar 文件之后）还是在该过程的早期进行？
- 每个发布的产品是否应该包含一个扫描仪日志文件，用于确定所使用的防病毒工具、病毒定义文件的版本和日期？
使用哪种防病毒软件超出了这个问题的范围。 （例如，我想使用商业供应商来支持像 ClamAV 这样的免费工具）
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)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
病毒从哪里来？
我还没有看到可以修改源代码的病毒，因此源代码可能是安全的（好吧，除非您不能信任您的开发人员）。
因此，病毒可以隐藏在构建工具之一中并尝试修改 JAR。这里手头的工具是 tripwire：它将为所有文件创建校验和，构建工具应该不会更改（除非您安装新版本；然后您必须再次运行 tripwire）。
如果构建工具是安全的，那么您只需要一个保护操作系统的反病毒工具（因此打开和写入文件等功能是安全的）。为此，请使用贵公司的标准 AV。
为了使整个过程真正紧凑，您可以在构建新版本之前再次构建上一个版本。旧版本的校验和不应更改（但要注意文件中的时间戳）。
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).
最佳实践是在很少受到病毒攻击的平台（即操作系统）上运行您的构建。
最佳实践是在构建平台上的操作系统级别运行防病毒扫描程序。
最佳做法是及时更新操作系统补丁、锁定防火墙、不要安装可能已被感染的家庭网络 USB 密钥等。
我从未听说过“感染”源代码的病毒、.class 文件或 JAR 文件。我认为它们是可能的，但商业 AV 产品很可能不会注意到它们，因为它们很不寻常。当然，反病毒产品无济于事，因为该病毒专门针对您/您的公司。
但假设您确实拥有您认为可行的 AV 产品，您可以在发布“发布版本”之前进行 AV 扫描。我不知道有什么插件可以自动完成这项工作，但是让 Maven 运行“某个批处理文件”应该不难，该文件恰好通过命令行调用病毒检查器。
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.
您需要一个可编写脚本的防病毒程序。
当你有了这个之后，应该很容易添加“扫描我刚刚构建的内容”步骤。
我相信迈克菲有一个 Linux 版本，它可能正是您所需要的。
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.
如果这真的是一个问题，我认为你的安全团队应该强迫你（和专家）通过运行某种防病毒软件的代理。这将是正确的做事方式。
但是，在我看来，从存储库获取恶意代码的可能性接近于零，特别是对于广泛使用的库（有如此多的用户，我怀疑在获取该代码之前没有人会注意到问题），并且我敢打赌通过（网络）邮件、USB 密钥、下载的软件感染的可能性要高得多。我知道这不是答案，但说实话，安全策略有时很荒谬。
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.