简介Fortify SCA 是一款广泛应用的静态代码安全分析工具本 PDF 手册面向需要部署、配置并使用该工具的研发、测试及安全运维人员提供从安装到故障排查的全流程参考。手册按产品说明、安装说明、使用说明、故障修复四个模块展开覆盖 Windows、Linux、Unix 等多平台部署方式还包含 Eclipse 插件安装、扫描指南、扫描结果分析方法并针对 C/C 构建转换失败等常见问题给出具体的配置修改建议适合作为团队内部培训或安全测试项目实施的标准化范本。资源包为单个 PDF 文件大小约 1.63MB内容紧凑、目录结构清晰便于按章节快速定位所需信息。目前已有 69 人学习浏览适合正在引入 Fortify SCA 平台或需要规范代码安全审计流程的读者下载参考。1. 一份 Fortify-SCA 安装使用手册范本解决的不只是“装得上”当一份名为 Fortify-SCA-安装使用手册范本.pdf 的文件被丢进项目群通常意味着安全测试阶段要开始或者甲方审计要求交一份代码安全扫描报告。Fortify SCAStatic Code Analyzer是业界常用的静态应用安全测试工具这份 PDF 讲的是从安装到出报告的一整套可复现动作。它真正值钱的地方不在“能装”而在把 JDK 版本、许可证、扫描命令、报告口径全部定下来让新人和老手都能照做。适合等保测评、SDLC 安全门禁、代码审计场景照着它改造成自己的 SOP是这份范本的正确用法。2. 看懂这本手册范本之前Fortify SCA 的组件关系与角色定位Fortify SCA 并不是“双击安装然后点扫描”的单机工具它在文档里出现的名字其实是一套产品族。手册范本如果上来就写安装命令读者很容易在后面上传报告时卡住所以先要弄清楚谁在干活、谁在存结果。最常见的一种误解是把 SCA 和 SSC 当成同一个东西导致在主机上只装了其中一部分然后整个流程走不通。2.1 SCA 与 SSC、ScanCentral 的区别手册里为什么先写安装再写扫描Fortify 的产品族按静态应用安全测试的流程可以拆成三段SCA 负责把源代码翻译成中间模型再执行分析规则产出 .fpr 结果文件SSCSoftware Security Center是 Web 服务接收 SCA 上传的结果、做漏洞生命周期管理和报告输出ScanCentral 是扫描调度入口适合多项目、多机器的统一扫描。单机场景下SCA 是绝对主角SSC 可以后装ScanCentral 甚至可以没有。手册范本从 SCA 单机安装讲起是因为后面的上传和审计都依赖这个 .fpr 文件。组件角色部署形态典型入口产出物SCA静态分析引擎单机命令行 / IDE 插件sourceanalyzer、Audit Workbench.fpr 结果文件SSC结果管理与报告Web 服务自带应用容器浏览器访问 /ssc审计记录、PDF 报告ScanCentral扫描调度与分发服务端 客户端scancentral 命令提交给 SSC 的扫描任务这张表我建议贴在安装手册的第一章目的是防止方向搞反。在这套关系里SSC 是可选后端SCA 是必装的前端。安装顺序上我会先保证 SCA 能独立扫描出 .fpr再决定要不要上 SSC这样即使后端没通扫描结果也不会丢至少本地有产物可以排查。2.2 安装前要收集的清单JDK 版本、操作系统、许可协议、扫描对象根据我的经验安装现场八成的失败都不是工具不行而是环境信息没有在动手前对齐。手册范本里通常会放一张“环境确认表”我也建议团队照抄一份内容包括四类关键信息。JDK 版本是最容易翻车的SCA 依赖 64 位 JDK不同大版本支持的 JDK 范围不一样实施前先找到随安装包发布的 release notes 确认不要一上来就装最新的 JDK 21。操作系统方面Windows Server 和 CentOS 7 这类常见服务器系统都能跑但要注意发行版和 CPU 架构x86_64 与 aarch64 的安装包不能混用。许可证要确认授权类型和有效期Fortify 的 license 文件一旦过期扫描命令会在最后阶段报错表面看起来像解析器坏了实际是授权失效。扫描对象则要看构建方式和语言Java 项目要确认是 Maven 还是 GradleC# 项目要确认 .NET 版本这决定后面翻译器用哪种参数。# Linux / macOS 下核对基础环境Windows 用 where java 替代 java -version # 确认是 64 位 JDK且版本在 release notes 支持范围内 uname -m # 查看 CPU 架构x86_64 与 aarch64 安装包不能混用 df -h /opt # 确认磁盘剩余空间扫描中间文件会吃掉几个 GB这里第一行命令把 JDK 位数和版本一次性打出来比在安装器里报错后再回头查省时间。uname -m是容易被忽略的一步尤其现在很多团队用 ARM 云主机装一个 x86 二进制下去会直接报cannot execute binary file。磁盘空间我建议留出代码体积的 5 到 10 倍大项目的翻译中间文件非常占地方。2.3 手册范本里的目录与文件装完 SCA 后哪些东西不该乱动SCA 安装完成之后目录里会有一批看起来很像“配置文件”的东西新手容易手痒去改。我踩过最明显的坑是往规则目录里塞了网上找来的规则文件导致下次更新规则时本地改动被覆盖扫描结果前后对不上。正确做法是规则包由更新工具统一管理临时加的测试规则放到独立目录用参数显式指定。安装目录里的 bin 和 lib 也不要动SCA 对自身组件完整性很敏感删除一个库文件换来的可能不是变快而是整条扫描链路报废。构建脚本和临时目录则建议放安装目录之外。把临时目录指到内存盘可以稍微提速但这属于优化项真正要注意的是扫描工作区是否预留了足够空间构建 ID 对应的翻译缓存会存在工作区里路径千万别用中文或带空格后面第五章会专门说。3. 按手册范本落地安装Windows 与 Linux 的最小可运行步骤这一章只解决一件事让 SCA 在一台从没装过 Fortify 的机器上跑起来并且能识别许可证。按“安装器执行前、执行中、执行后”的顺序写Windows 和 Linux 的命令分开说因为安装器的交互方式和路径分隔符都能让脚本在换平台后直接失效。3.1 解压与静默安装一次命令把 SCA 装到指定目录Fortify SCA 的安装包一般是一个带版本号的二进制文件Linux 下是.binWindows 下是.exe。不建议双击交互式安装原因很实际交互式安装容易手滑选错目录而且服务器上往往没有图形界面。我一般直接在 Linux 上用静默模式装命令长这样# 静默安装 Fortify SCA目录与许可证都通过参数固定 ./FortifySCA-版本.bin -i silent \ -f INSTALL_DIR/opt/fortify \ -f LICENSE_FILE/data/licenses/fortify.license \ -f INSTALLER_UIsilent这是通用安装器风格的静默参数-i silent让安装进程不弹任何界面INSTALL_DIR指定安装目录LICENSE_FILE把许可证文件路径直接传进去。注意版本号在安装包里别在脚本里写死否则下次升级时忘了改装完还是一个旧环境。Windows 下用同样的参数把.bin换成.exe路径分隔符改成反斜杠如果公司有软件分发平台可以把这条命令包成批处理由管理员统一执行。静默安装完成后检查安装目录下应该出现 bin、lib、Core 等目录。很多人会在这一步继续找“桌面快捷方式”但 SCA 的命令行工具才是后面扫描的主力图形界面的 Audit Workbench 也在同一套安装目录里通过命令启动。我建议从一开始就用命令行因为脚本化是这份手册范本的灵魂后面版本升级和灰度试点都靠它。3.2 许可证与规则包安装完先做这两件事再扫描安装完成后第一件事是确认许可证第二件事是更新规则包顺序别反。因为部分更新操作需要读 license 里的授权范围许可证不合法时更新规则也可能失败。验证许可证最快的是命令行# 查看许可证有效期与授权范围 sourceanalyzer -license如果安装时没传 LICENSE_FILE会看到提示找不到 license 的错误。常见的补救做法是把 license 文件复制到 SCA 安装目录对应的licenses文件夹下再重新执行命令也有团队用环境变量FORTIFY_LICENSE_FILE指定路径我建议把它写进运维脚本而不是依赖默认目录。规则包更新用 fortifyupdate 工具。能访问更新服务器的环境直接执行fortifyupdate -accept网络隔离的内网环境我一般这么处理先在能联网的机器上下载规则包 zip放到内网共享目录再手动执行更新工具指定来源。规则包不更新的后果很隐蔽扫描能跑通但新发布的漏洞模式识别不出来报告里长期看不见某类问题这才是最可怕的静默失效。3.3 验证安装用 sourceanalyzer -version 一条命令确认装完别急着扫大项目先做最小验证。一条命令能确认安装是否可执行# 验证 SCA 命令行本身可运行 sourceanalyzer -version # 查看可用参数顺便确认环境没有污染 sourceanalyzer -help-version输出正常说明二进制和动态库都加载成功-help能列出参数说明翻译器初始化完成。这个时候再用一个 50 行的小 Java 文件做冒烟扫描比直接拿生产代码来试更容易定位问题# 最小冒烟测试扫描一个临时目录产出 fpr 即通过 mkdir -p /tmp/fortify-smoke/src echo class Test { String q(String a) { return select * from users where id a; } } \ /tmp/fortify-smoke/src/Test.java sourceanalyzer -b smoke -source 1.8 -encoding UTF-8 -cp /tmp/fortify-smoke/src \ -scan -f /tmp/fortify-smoke/smoke.fpr ls -la /tmp/fortify-smoke/smoke.fpr这段代码把一段带字符串拼接 SQL 的 Java 类喂给 SCA如果.fpr文件生成了说明安装链路是通的。-b smoke是给这次翻译起个构建 ID-source 1.8告诉翻译器源码级别-cp传的是源码路径同时也是 classpath-encoding UTF-8避免中文注释乱码。冒烟用例通过后再进正式扫描流程就不会被最基本的安装问题绊住。4. 用 SCA 扫描一个真实项目从构建 ID 到审计报告安装只是手腕真正产生价值的是扫描命令和报告口径。这一章直接给一套能从源码跑到 PDF 报告的完整动作包括手动扫描、增量扫描、上传 SSC、生成报告再讨论为什么手册范本里的流程要固定成脚本。4.1 手动扫描与增量扫描sourceanalyzer 的常用参数sourceanalyzer 分两个阶段翻译和扫描。翻译是把源码变成中间表示扫描是应用规则两者可以分开执行。构建 ID-b是串联两者的关键同一个 ID 会在工作区缓存翻译结果下次再扫直接复用这就是增量扫描的基础。最直接的操作# 第一次扫描清理旧缓存、翻译、扫描三步分开执行 sourceanalyzer -b demo -clean sourceanalyzer -b demo -source 8 -encoding UTF-8 -cp ./lib/*:./src ./src sourceanalyzer -b demo -scan -f ./out/demo.fpr-clean清掉该构建 ID 的旧翻译缓存确保不是拿上一次的半成品在分析。中间那行把 classpath 直接展开-cp里可以写冒号分隔的多段路径。最后-scan -f把分析结果写进指定的.fpr文件。如果不执行-clean第二次扫描会复用首次翻译结果扫描速度能明显提升所以日常反复扫描时去掉-clean反而更合理只有正式发布或代码结构大改时才需要全量重来一遍。参数作用我常用建议值-b id构建 ID串起翻译与扫描与项目名一致如 erp-server-source n指定源码语言版本Java 项目写 1.8 或 11-cp pathclasspath 路径依赖 jar 加源码目录-encoding源码编码UTF-8兼容中文注释-scan -f file执行扫描输出 fpr输出到 out 目录-clean清空构建 ID 缓存正式发布才用如果项目是 Maven 构建最好不手写 classpath。常见做法是先让 Maven 导出依赖列表再喂给 SCAmvn dependency:build-classpath -Dmdep.outputFileclasspath.txt sourceanalyzer -b demo -source 8 -cp $(cat classpath.txt):./src ./src sourceanalyzer -b demo -scan -f ./out/demo.fpr这里第一行导出的是依赖 jar 的完整路径第二行把这些路径连同源码目录一起传给翻译器SCA 就能把第三方组件的调用链也分析到报告中会出现框架层的可疑调用不再是只看到自家代码里的裸拼 SQL。4.2 把扫描结果送进 SSC上传、审计、生成 PDF 报告如果团队只有一台命令行机器不装 SSC 也能用 Audit Workbench 打开.fpr看结果但一旦涉及多人和合规报告SSC 就绕不开。上传动作用 fortifyclient 完成# 上传 fpr 到 SSCauthtoken 从 SSC 个人菜单生成 fortifyclient -url http://ssc-host:8180/ssc \ -authtoken token \ -upload -f ./out/demo.fpr \ -application 进件系统 \ -version 1.0-url指向 SSC 的 /ssc 路径-authtoken换成个人令牌别用密码直接传-application和-version会在 SSC 上创建一个应用版本。上传成功后在 SSC 的“审计”界面里逐条确认漏洞状态是真实漏洞、误报还是要修复这些状态最终会反映在报告的统计口径里。生成 PDF 报告就在 SSC 的“报告”页选模板在线生成第一次用时先把模板名定下来后面每个迭代都点同一个模板报告口径才可对比。也有团队想全自动出报告会去查 REST API 来触发生成。这个方向可以做但我建议先把 UI 上的标准流程跑通因为接口要处理文件轮询和模板 ID初期收益不高。手册范本里最值钱的一条经验是把报告模板名、应用版本命名规则也写进去否则半年后翻历史报告根本对不上哪份是哪次扫描。4.3 手册范本里的“标准扫描流程”该写成什么样把上面的命令收拢成一个脚本就构成标准流程的骨架。我自己的习惯是让脚本只暴露三个变量新同事拿到后改三个值就能跑#!/usr/bin/env bash # 标准扫描把构建 ID、源码目录、输出目录做成最外层变量 set -euo pipefail BID${1:-erp-server} SRC_DIR${2:-./src} OUT_DIR${3:-./out} mkdir -p ${OUT_DIR} FPR${OUT_DIR}/${BID}.fpr sourceanalyzer -b ${BID} -clean sourceanalyzer -b ${BID} -source 8 -encoding UTF-8 -cp ${SRC_DIR} ${SRC_DIR} sourceanalyzer -b ${BID} -scan -f ${FPR} echo 扫描完成: ${FPR}这个脚本故意没把-cp里的依赖展开写死因为真实项目依赖路径总是变。更工程化的做法是先跑依赖导出再把导出的 classpath 文件读进来这里给出的就是最小骨架目的是说明标准流程应该长什么样参数前置、路径集中、状态清楚。手册范本如果能把这一页写透比贴二十页截图都管用。5. 手册范本使用中的踩坑记录安装与扫描最常见的 5 个问题这一章是从“能跑”到“一直能跑”的必经路。以下问题我都真实碰到过多数不是配置写错而是环境与预期不一致或者手册范本里的坑没写到。5.1 中文目录、项目名带空格导致翻译器找不到源文件现象扫描命令执行完日志显示 0 个文件被识别.fpr虽然生成但里面没有任何问题。原因-cp参数里的路径含中文或空格翻译器在按分隔符拆路径时把路径切断了源文件实际没被加载。Windows 环境下尤其常见因为用户名经常是中文。解决扫描前把项目复制到纯英文路径例如D:\scanjobs\erp-server命令行里用双引号包住路径能缓解空格但解决不了中文-encoding UTF-8只影响文件内容解析不影响文件系统路径识别别指望它能救路径。我会在手册范本第一页就写上“路径规范”让所有作业目录统一用英文小写加连字符。5.2 扫描结果全是 0 个问题但代码里明显有 SQL 注入现象报告里连一个 High 都没有但人眼扫代码就能看到字符串拼接 SQL。原因classpath 不完整。SCA 翻译时没有加载依赖 jar方法调用链断裂污点分析到项目内部就断了规则无法跟踪到危险的 sink。解决先确认翻译日志里“files translated”数量不少于find src -name *.java | wc -l的结果再用 Maven 导出 classpath 喂给-cp。如果第三方框架规则缺失还要检查规则包版本。本质是“扫描跑了但分析深度不够”判断标准不是命令有没有报错而是结果文件里有没有可信的发现。5.3 重新扫描时报告一直维持旧版本数据现象代码改了重新执行同一套扫描命令报告里的行号还是旧的。原因构建 ID 没变但也没加-clean翻译器复用了老的翻译缓存或者上一次扫描和本次扫描的构建 ID 不一致新结果被存到另一个 ID 下。解决同一项目固定一个构建 ID代码结构大改或正式发布前加-clean强制全量翻译输出.fpr文件名带时间戳或 commit 号防止旧文件被覆盖。检查时用sourceanalyzer -b id -info查看该构建 ID 的翻译信息能直接对上缓存时间。5.4 服务器装完一扫描就 OutOfMemory现象sourceanalyzer 跑到一半控制台抛 OutOfMemoryError之前专门加了-Xmx4G也没用。原因SCA 的翻译器是重内存进程-Xmx设置的是 JVM 堆但翻译缓存还在堆外占内存另外部分服务器默认的进程打开文件数和线程数限制太低大项目一批文件并发翻译时直接触发资源不足。解决把内存参数放大比如-Xmx8G同时确认操作系统对当前用户的文件句柄限制Linux 下看ulimit -n必要时调大。这个问题有些玄学同一份代码 Windows 能跑 Linux 崩多数不是规则问题而是宿主机的内存分配策略不一样。我会在手册范本里写“最少 8G 内存”避免部署到 4G 的测试机上才发现。5.5 手册范本里写死的安装路径换台机器就失效现象把手册命令复制到新环境提示sourceanalyzer: command not found排查了半天才发现是安装路径不同。原因手册没有约定 PATH 和环境变量每个人安装目录不同或者写死了一句PATH/opt/fortify/bin而实际部署在别的目录。解决统一约定安装基路径并把安装目录/bin加入 PATH在手册开头用一张环境信息表记录 JDK 路径、Fortify 安装目录、许可证文件位置每次安装完先跑sourceanalyzer -version确认环境。能让手册从“记事本”变成“SOP”的正是这一个动作把环境假设写到最前面。6. 把手册范本改造成团队 SOP三个验证动作与一个发布习惯手册范本最大的陷阱是“看起来完美没人验证过”。我接手过一份 PDF命令排版整齐结果按它装时少了 PATH 配置整个组花了半天排错。从那以后我要求团队对外发布的安装使用手册必须过三个验证动作。第一个是干净环境复测找一台从未装过 Fortify 的虚拟机完全照手册执行任何一步需要临场发挥都记下来补进手册。第二个是版本矩阵对照手册里必须写明 JDK 版本、操作系统版本、SCA 版本和上次验证日期三个版本对齐才能复现。第三个是冒烟用例库准备一个包含漏洞的小项目扫描后要能检出预设问题这个用例专门用来区分“环境坏了”还是“规则失效”。发布习惯上我坚持在每次升级版本或调整规则包后顺手在手册开头更新环境信息页同时用固定格式存一份变更记录。扫描命令可以写进 CI 流水线但不建议把 CI 配置作为唯一真相因为安全团队评审时更习惯打开 PDF 看流程保留一份人和机器都能执行的手册才能避免“口口相传的暗知识”。这个方向的投入回报很快一次把环境摸清后续每个迭代都能产出口径一致的 PDF 报告审计沟通成本明显下降。我自己现在写任何工具手册都会先在最后补一节“怎么证明这份手册管用”再回去补前面的章节。希望帮到你。本文还有配套的精品资源点击获取