给Veracode传代码包这件事，并不是把项目的文件夹随手一压，然后上传就能行的，针对不同的开发语言，还有不同类型的扫描，平台对你要传什么东西上去，那个要求也是不一样的，Veracode的静态分析，通常是在分析那种已经编译好的，像二进制文件或者字节码，这一类的打包产物，而那种“上传并扫描”的模式，它也可以把静态分析和开源组件的分析，给结合到一起去，用它们来综合地评估一个应用的风险，所以，在动手准备这个要上传的代码包之前，要先去看一眼，你的项目到底是个什么类型，然后再来决定，到底是应该把源代码给传上去、还是传构建出来的产物、又或者是源代码，再加上一份依赖的清单。

　　一、源码包要怎么准备

　　在准备要上传的包的时候，最核心的一件事，就是得让Veracode那边，能够清清楚楚地认出来，你这个应用的边界在哪里、它是用什么语言写的、都依赖了哪些东西，还有，哪些文件是它可以拿来分析的，包里的内容要是太少太单薄了，那扫描就跑不全；可要是里面塞的东西太杂太乱了，又很容易会导致解析失败，或者是扫出来的结果，看着乱七八糟的。

　　1、先要弄明白，这次到底是要扫什么东西

　　在动手打包以前，要先想清楚，这一次，是要只做静态分析、只做软件组成分析，还是这两样，都要一块儿做了，要是像Java、C#这一类的项目，那通常，就应该是优先去准备好，构建完了以后生成出来的，那种jar、war、ear、dll、exe之类的产物；可要是碰到的是脚本语言，或者是专门要去做开源组件的分析，那除了源码的文件，还得把依赖的描述清单，还有那种锁定了版本的依赖文件，也给一起留着，千万不要把“源码包”这三个字，就给简单地理解成了，是把开发用的那个目录，原封不动地给传上去。

　　2、把那些关键的工程文件给留下来

　　在要传的源码包里头，像pom.xml、build.gradle、package.json、package-lock.json、requirements.txt、go.mod、csproj、sln这些，用来管工程和管依赖的文件，是一定得留着的，Veracode那边，它会根据不同的语言，还有文件的结构，去认出来你项目里的东西，要是缺了这些文件，那它去做组件的识别、依赖的分析，还有源码的关联，这些操作，就全都会受到影响。

　　3、把那些跟分析没关系的目录都给清理掉

　　在打包之前，比较建议的做法是，先去把像.git、.idea、.vscode、node_modules、target、dist，还有构建时候留下的缓存、临时的日志文件、以前备份过的历史包，以及本地测试跑出来的那些输出，全给删干净了，真正需要传上去的东西，是那些可以被分析的内容，而不是你整个开发的环境，目录越是干净，上传的过程就越是稳当，到了后面，去看扫描出来的结果，解释起来，也会容易得多。

　　4、去用平台支持的那种压缩格式

　　Veracode是支持上传像ZIP、TAR、TAR.GZ、TGZ这几种归档格式的，平台它会自己去把那个归档文件给解开，然后把它里面能认出来的、那种可以被执行的文件，给列成一个清单，在公司内部，要是有那种统一的流水线，那就可以让大家都固定地去用zip这种格式，这么做，就能避免因为不同的人，手工去打包，结果最后搞出来的目录结构，都长得不一样。

　　二、包的结构不合规要怎么检查

　　当源码包的结构不合规的时候，比较常见的几种表现是，上传倒是成功了，可模块被认出来的不对、扫描覆盖的范围好像少了什么东西、依赖关系压根儿就没被识别出来、扫出来的结果是空的，又或者是，平台直接提示说，里面没有能被分析的文件，在检查的时候，要顺着目录的层级、文件的类型，还有构建出来的产物，这么三个方向，挨个去看。

　　1、去检查一下，根目录是不是套得太深了

　　在把那个压缩包给解开以后，它最外面的那一层，最好是能直接就看见，项目的主目录，或者是那几个最核心的工程文件，可不要出现那种，一层套一层，里面塞着日期、备份、什么正式版、源码，然后再是项目名，这样子好几层的嵌套结构，当层级被搞得太多的时候，人倒是能一层一层地翻进去，把文件给找出来，可平台那边，就没有办法按照你预想的那样，去把工程的入口给识别出来了。

　　2、去检查一下，是不是缺了入口的文件

　　后端的项目，要去看它的构建配置，还有那个最主要的模块，是不是都老老实实地待在包里面；前端的项目，则要去看package.json、放源码的目录，还有那种锁定了依赖版本的文件，是不是全都齐了；.NET的项目，要去看sln、csproj，还有编译完了以后出来的那些东西，是不是都能对应得上，至于Go的项目，就要去留意一下，源码的目录，跟go.mod文件它俩的位置，是不是匹配的，因为Veracode在分析Go应用的时候，它是会去把归档文件给解开的，然后去扫描工作区目录里面，那些Go的文件。

　　3、去检查一下，是不是传错了东西上去

　　有些团队，会把前端的打包输出目录、后端一个空空的jar包、里头只放着接口文档的文件夹，或者是那种连依赖信息都没有的、临时拼凑的文件夹，给传了上去，那最后扫出来的结果，自然是不全的，所以，在上传之前，要自己先在本地，把那个压缩包给打开，去确认一下，看看里面到底装了些什么，要确保那里面装的，不是空壳的文件，也不是那种，只装着构建完的静态页面。

　　4、去检查一下，第三方库和自己写的代码，它们之间的边界在哪

　　要是所有从外面拿来的第三方库、自己人写的代码、用来做测试的代码，还有那些示例的代码，全都给混在了同一层的目录里面，那扫出来的结果，筛选起来，是会比较麻烦的，比较推荐的做法，是照着src、lib、config、docs这种最基本的结构，去把它们给整理开，至于测试代码和示例代码，要是它们并不参与这一次的评估，那就可以按照项目自己的规范去把它们给排除掉，免得到时候，扫描的结果里面，跑出来一大片不相关的问题。

　　三、在上传以前，要怎么做才能少一些返工

　　给Veracode上传包这件事，之所以会反反复复地返工，在多数时候，倒不是平台那边出了什么问题，而是本地在打包的时候，没有形成一个固定的规范，项目组，应该去把准备上传包的这一套规则，给写到构建的脚本里面去，而不是每一次，在快要扫描了，才急急忙忙地靠手工去整理。

　　1、用构建的脚本来统一地打包

　　可以在流水线里头，去专门加一个，用来给Veracode准备上传包的任务，在这一个任务里面，去固定地把目录给清理干净、把工程文件和构建出来的产物给复制好、最后再生成一个压缩包，这么做完了以后，每一次上传的包，它的结构都是稳稳当当、一模一样的，不管是后面想要去复现问题，还是去追踪版本，都会变得清楚很多。

　　2、把上传包的历史版本给记录下来

　　每一次上传的包，都要去把它是从哪一根代码分支来的、提交的编号是多少、是第几次构建、是在什么时间打的包、要传给哪个扫描应用，还有是放在哪个沙箱里面，这些信息都给记下来，这样，万一到了后面，发现扫描出来的结果，跟代码的版本对不上了，就可以顺着这些记录，很快地就查到了，当时上传的那个包里面，到底装了些什么东西。

　　3、上传完了以后，要去核对一下文件被识别出来的结果

　　在上传的动作完成了以后，先别急着就把那个页面给关掉，要去看一眼，平台那边列出来的，已经被识别到的文件清单、各个模块的名字，还有扫描它当前的状态，是怎么样的，要是发现平台那边，只勉勉强强认出了很少的几个文件，又或者是，压根儿就没有认出来，你最核心的那几个模块，那就要先把扫描给停下来，回到本地，去重新检查一下，这个包的结构到底对不对。

　　总结

　　关于给Veracode传的源码包，到底要怎么去准备，还有万一这个包的结构被判定为不合规，又要怎么去检查，这里面最关键的一点，就是要按照你用的语言，还有扫描的类型，去把正确的内容给准备好，在打包以前，先要弄明白这次到底是要扫什么，然后把工程的描述文件、依赖的清单，还有那些必须要有的构建产物，都给留下来，再把缓存、日志，还有本地的配置，这些用不着的东西给清理掉；到了上传之前，再回头去检查一遍，根目录的层级是不是太深了、入口的文件缺没缺、传上去的到底是不是对的产物，还有自己写的代码跟第三方库的边界清不清楚，只要把这些规则，全都给固化到了构建的脚本里面去，那么往后的每一次扫描，都会变得更加稳定，到了要去解释结果的时候，也会方便很多。