在企业把SAST扫描接入自动化流水线之后，经常会碰到一个让人头疼的问题，那就是用Fortify ScanCentral提交的扫描任务，不是一直卡在排队的状态里，就是半天都跑不起来。要说清楚Fortify ScanCentral的扫描任务到底该怎么提交，以及任务一直排队又该怎样处理，需要先了解这套系统的基本运转方式：通常是由Client端把任务发出去，Controller这边负责接收请求，然后再把任务分给那些处在空闲状态下的Sensor去实际执行扫描。想要顺利地提交一个任务，事前得准备好Controller的地址、client_auth_token、SSC CI Token、应用的名称、版本的名称，还有要扫描的源码包，这些前置条件在官方的说明里也是被明确写出来的，它要求我们必须有SSC的URL、ScanCentral Controller的URL、客户端认证用的Token、SSC CI Token，以及已经在SSC里面建好的Application和Version。
一、Fortify ScanCentral怎么提交扫描任务
在用ScanCentral提交任务以前，要先确保本地的Client能够正常连上Controller，项目本身可以顺利地构建起来，而且SSC里面也已经把对应的应用版本给建好了；不要一上来啥都不管，就急着把源码目录压缩一下然后传上去，要知道很多排队或者失败的问题，根子其实就出在提交时用的参数不够完整上面。
1、确认客户端配置
我们需要在ScanCentral Client的配置文件中，把Controller的地址和client_auth_token这两项给填好，在一些平台托管或者集中部署的环境里面，这个client_auth_token通常是由Fortify平台或者管理员统一发放的，按照官方的说法，这个值需要被写进Fortify ScanCentral Client目录下Coreconfigclient.properties这个文件里面去；在配置完了以后，可以先试着执行一下查看版本或者测试连接这类简单的命令，以此来确认客户端是不是已经可以正常地访问到Controller了。
2、使用命令提交扫描
比较常见的提交方式，就是在项目的根目录下面去执行scancentral这个命令；在没有集成构建工具的时候，可以采用类似【scancentral-url
3、保留任务Token和日志
在任务被成功提交上去之后，一定要把系统返回的那个job token给保存下来，因为后面再去查询状态、排查失败的原因，或者下载日志的时候，全都要用到它；在提交命令的后面，还可以加上-log、-slog、-block还有-f这一些参数，官方在Start command的说明里面也提到过，-block可以一直等待任务执行完毕，然后从Controller把扫描结果下载下来，-f能够指定一个本地的FPR输出文件，而-log和-slog则分别用来保存客户端或者Sensor上的日志。
二、Fortify ScanCentral任务一直排队怎么处理
当任务一直处在排队状态时，首先要做的就是去确认它到底是PENDING，还是QUEUED，按照官方的状态说明，PENDING代表Controller是已经接收到了这个扫描任务，而QUEUED才意味着任务已经被分配给了某个Sensor，只有到了RUNNING这一步才表示扫描正在真正地执行；这几个状态各自的含义不同，后续排查起来的方向也完全不一样。
1、先查任务状态
可以执行【scancentral-url
2、检查Sensor是否在线
通过登录Controller的管理页面，或者直接去查看Sensor服务的运行状态，要确认它到底在不在线、有没有空闲下来、软件的版本和Controller是否匹配，以及磁盘空间是不是还充足；如果Sensor离线了、服务没有被启动起来、工作目录缺少权限，或者临时目录的空间已经不够用了，都有可能导致任务长时间没办法真正开始执行；在使用了Sensor Pool的情况下，要是提交命令里面还额外指定了-pool这个参数，那就还得再确认一下这个池子里面到底有没有可以用的Sensor，官方在Start command里也说明了，-pool可以把扫描的请求提交到某一个指定的Sensor Pool里面去。
3、检查并发和资源占用
如果有大量的任务在同一个时间段内被集中提交了上来，那排在后面的那些任务就只能等着前面的任务先处理完；这时候管理员就需要去查看一下当前正在RUNNING的任务数量、每台Sensor上面CPU和内存的占用情况、扫描的超时时间设置，还有队列的长度；大项目的扫描往往需要很长的时间，这样一来那些小项目的任务也会被堵在后面，暂时可以考虑去临时的增加Sensor，或者把大项目、普通项目，还有比较紧急的项目分到不同的队列或不同的Sensor Pool里面去跑。
4、检查任务是否重复提交
要是同一个应用版本已经有排队的任务存在了，再重新提交一个新任务上去，就很可能会触发那种重复任务的处理逻辑，官方在Start command的说明里有提到，可以通过某个选项来防止因为重复的扫描请求而把已经在排队的任务给替换掉；在流水线里面，如果每次提交都使用了相同的应用版本和差不多的参数，那就得去查一下是不是因为什么原因，导致扫描被反复触发了许多次。
三、Fortify ScanCentral排队问题怎么减少
排队的问题被临时处理掉以后，最好是把提交的规则和资源分配的策略都固定下来，要是不这么做的话，下回再碰上集中的扫描，通道还是一样会被堵住。
1、把扫描任务分级
主干合并的扫描、发布分支的扫描，还有普通开发分支的扫描，不能让它们全都走同一条优先级的通道；发布之前的扫描可以继续保留完整的规则，而日常开发分支上的扫描，则可以按照模块或者增量的策略去控制它的触发频率，用这样的办法来避免那些不太必要的任务把Sensor都给占满了。
2、规范提交参数
在流水线的脚本里面，要把Controller的地址、应用版本的命名规则、构建的工具、排除的目录，还有日志的输出路径都给固定下来；ScanCentral的start命令是支持-exclude、-include、-bt、-bc这一些参数的，官方文档也说明了-bt用来指定构建工具，-exclude和-include用来控制分析文件的范围，等到这些参数都稳定下来以后，再去排查排队的问题就会变得容易不少。
3、保留排查证据
每次碰到排队异常的时候，都要把job token、当时提交的命令、Controller的日志、Sensor的日志、应用的版本、提交操作的时间，还有流水线的编号这些信息给保存起来；不要只是简单地截一张显示着“Queued”的图片就完事了，因为管理员那边是需要这些信息的支持，才能准确地判断出到底是资源出现了不足、Sensor本身发生了异常、权限出了问题，还是任务参数上设置有误。
总结
综合来看，对于Fortify ScanCentral怎么提交扫描任务，以及任务一直排队又该怎么处理，整个操作的顺序就是先把Client和Token配置好，再用scancentral start命令把任务提交上去，同时一定要把返回的job token给保存下来；在面对排队的情况时，先用status命令去区分清楚PENDING、QUEUED和RUNNING这几种状态，之后再去检查Sensor的在线情况、Sensor Pool的配置、并发使用的资源、有没有重复提交，以及相关的日志；只要我们把提交参数、任务分级，还有日志留存这些做法都固定下来，ScanCentral的排队问题才不会每一次都需要靠临时靠人工去排查。
