开发人员收到漏洞工单后，按记录打开文件，却发现对应行已经变成注释，或者代码根本不在当前分支。遇到这种情况，先别急着改工单行号。扫描结果对应的是某次提交的代码，后续新增方法、移动文件都会改变位置。关联工单时保留扫描依据，发生偏差后再对齐代码版本，才能确认双方讨论的是同一个问题。

　　一、Checkmarx如何将漏洞结果关联到开发工单

　　Checkmarx One通过Feedback App连接Jira，再用Feedback Profile指定适用项目。只完成Jira连接测试，还不足以让项目自动生成工单。

　　1、配置Jira连接和建单条件

　　①打开【Integrations】→【Feedback Apps】，进入【Apps】，点击【Create App】，选择【Jira】后点击【Next】。

　　②填写应用名称，在【Severity】、【State】和【Scan Engines】中设置需要建单的严重程度、结果状态及扫描引擎。

　　③进入凭据配置，选择对应认证方式，填写Jira地址、账号及令牌，点击【Test Connection】。

　　④连接成功后选择【Project Key】，继续设置【Issue Type】、开启与关闭工单的状态，并补齐工作流要求的字段。

　　⑤完成严重程度与Jira优先级的映射，点击【Save】。

　　首次配置可以先选少量待处理的SAST结果验证。若连接成功却无法建单，还需检查Jira账号的项目权限、问题类型必填字段，以及该类型是否保留Labels系统字段。

　　2、将集成分配给扫描项目

　　①打开【Integrations】→【Profiles】→【Create Profile】，填写名称和说明，点击【Next】。

　　②在【Feedback Apps】面板选中刚创建的Jira应用，继续进入【Assign Projects】。

　　③勾选需要关联的Checkmarx项目，点击【Save】，随后对符合触发条件的分支运行扫描。

　　④扫描结束后进入Jira，核对工单所属项目、漏洞信息及结果入口，并补充代码提交号和负责人。

　　仓库自动集成项目还需检查受保护分支范围；流水线扫描等场景则应核对Primary分支设置。部分匹配漏洞会被聚合为工单，因此工单数量与漏洞数量未必一一对应，不能只用数量是否相等判断关联成功。

　　二、Checkmarx缺陷记录与代码位置不匹配如何校正

　　位置不匹配通常涉及三处：工单保存的历史记录、Checkmarx所选扫描，以及开发人员当前打开的代码。先把这三者对齐，再处理路径或行号。

　　1、核对扫描批次与代码提交

　　①从工单进入关联结果，记录项目、分支和Scan ID，不要直接用另一批最新扫描替代。

　　②打开项目的【Scan History】，找到该扫描，再结合流水线构建记录确认实际扫描的提交号。

　　③在代码仓库中打开这个提交对应的文件，比较函数名、关键语句及上下文。

　　如果历史提交中的位置正确，而当前分支行号不同，说明代码已经移动。此时应在工单评论中补充当前提交及新位置，同时保留原扫描依据。若流水线扫描的是合并后的临时提交，还要核对该版本，不能只看开发分支最新提交。

　　2、区分输入、输出和建议修复位置

　　①在SAST结果表中查看【Source File】和【Sink File】，确认记录指向的是输入源文件还是危险操作所在文件。

　　②勾选对应结果，点击【View Code】，检查攻击路径中的节点及其代码。

　　③查看【Best Fix Location】，将工单描述与实际需要修改的语句对照，再补充说明。

　　输入源、危险操作和建议修复位置可能分布在不同文件。工单写着请求参数所在行，开发人员却在查数据库执行语句，两者可能属于同一条数据流。校正时应标明各位置的作用，避免把整条路径压缩成一个没有说明的行号。

　　3、检查IDE是否加载了另一批结果

　　①在VS Code的Checkmarx面板中，分别点击【Project】、【Branch】和【Scan】旁的编辑图标，选取与工单一致的项目、分支及扫描。

　　②也可以从网页【Scan History】复制Scan ID，在插件【Scan】旁点击搜索图标，粘贴后加载结果。

　　③选择路径节点，检查编辑器打开的文件，并核对本地工作区的代码版本和仓库根目录。

　　插件加载的是历史扫描，本地打开的却是更新后的文件，也会出现定位偏移。多模块工程还应检查同名文件和目录层级；上传压缩包的项目，则要对照压缩包内路径，不能直接套用流水线机器的绝对路径。

　　三、代码位置校正后如何重新核对工单

　　工单里的行号改过之后，还要回到扫描结果中确认一次。文件移动了，漏洞可能仍在；新扫描里找不到原记录，也可能是这次没有扫到对应目录。复核时需要把这两种情况分开。

　　1、对照新旧扫描确认问题去向

　　①对修复后的提交重新扫描，记录提交号和Scan ID，检查扫描是否成功完成，原文件是否仍在扫描范围内。

　　②打开旧结果，记录漏洞类型、输入源、危险操作和所在函数，再到新结果中查找对应路径。

　　③若文件已经改名或移动，对照代码变更记录找到新文件，检查相关语句及调用关系，不要只按旧文件名搜索。

　　④在原工单评论中补充核对结果，注明漏洞仍然存在、路径发生变化，或修复后未再检出，并附上对应扫描信息。

　　例如，原记录指向第80行，新增方法后相关语句移到了第110行，只要输入源和危险操作仍能对应，就应继续跟踪原问题。若新结果只是名称相同，实际属于另一处调用，则需要单独判断，不能直接沿用旧工单的修复结论。

　　2、检查记录是否能让接手人员继续定位

　　①从工单中的结果入口重新打开Checkmarx，确认项目、分支和扫描批次正确，并检查接收工单的开发人员是否有访问权限。

　　②在结果中点击【View Code】，核对工单描述中的函数和路径；通过【Add Note】补充工单编号，点击【Save】。

　　③查看Jira工单历史，确认状态变化是否来自修复复扫。若关闭时间与集成配置调整一致，继续检查触发条件是否被移除。

　　④复核无误后，在工单评论中写明验收依据；证据不足的，保留待核查状态并注明缺少哪项信息。

　　总结

　　漏洞任务经常跨迭代处理，最初负责的人也未必一直参与。几周后重新打开工单，接手人员能否找到当时的代码、看懂已经做过的修改，会直接影响后续处理时间。一条写清版本和核对结论的评论，往往比反复补截图更方便交接，也能减少把旧问题重新分派一遍的情况。希望这些操作能帮助大家把漏洞记录整理得更便于查找和复核。如果有Checkmarx工单关联、扫描结果排查等方面的需求，欢迎联系我们交流咨询。