在Checkmarx里，“项目”通常对应一个源码仓库或其中一个可独立交付的组件，项目创建做对了，后续扫描范围、权限隔离、基线与趋势才会稳定；做错了，最常见的就是权限混乱、结果串项目、流水线变量到处写死。下面按创建项目的落地步骤，再讲如何把项目结构与命名规则统一到团队可执行的口径。

　　一、Checkmarx怎么创建项目

　　创建项目时先确认你用的是Checkmarx One还是CxSAST本地部署版本，两者入口不同，但要点一致：项目名受字符限制、项目要绑定团队或应用域、扫描源要能被稳定定位。

　　1、在Checkmarx One用手工方式新建项目

　　登录后进入Applications and Projects首页，点击【New】→【New Project-Manual Scan】，在弹窗里填写项目名称与必要字段后保存，创建完成后再把该项目与后续的扫描方式绑定起来，例如手工上传或流水线触发。

　　2、在CxSAST创建SAST项目并设置基础属性

　　进入【Project&Scans】→【Create New Project】，在General里填写Project Name并选择Preset等基础属性；注意CxSAST对项目名有字符限制，不能包含冒号、问号、感叹号、斜杠、星号、引号、小于号、大于号、竖线、分号、与号、井号、美元符号、插入符号等字符，先按这个规则定命名规范能减少后续迁移返工。

　　3、把项目分配到团队实现权限隔离

　　不管是创建时还是创建后补配，都要把项目分配到对应Team，避免默认“All users”导致全员可见；CxSAST的Teams是层级结构，上级团队能访问下级团队的项目但反向不行，所以团队树一旦定下来，项目归属就能长期稳定。

　　4、把扫描对象位置与来源配置到项目里

　　CxSAST项目通常需要配置源码位置与扫描行为，典型做法是在项目配置里把代码来源指向Git地址或上传包，再按需要配置调度与通知；项目的意义是让同一个仓库的多次扫描都沉淀到同一个项目里，形成趋势与基线。

　　5、需要流水线自动建项时先统一项目路径口径

　　如果你用Jenkins等插件自动触发扫描，很多集成会要求提供项目的“完整路径名”，包含服务器根团队到子团队的层级路径，例如以CxServer开头的团队路径形式；这类口径一旦在CI里固定，项目结构就更不建议频繁调整。

　　二、Checkmarx项目结构与命名规则怎么统一

　　要统一结构与命名，先统一“一个项目对应什么”，再统一“项目名怎么拼”，最后统一“团队路径怎么挂”。这样你不但能在平台里快速检索定位，也能让流水线变量与权限规则一次写好长期复用。

　　1、先定项目粒度口径并写成硬规则

　　建议优先采用“一仓库一项目”或“一可独立发布组件一项目”的口径，不要把完全无关的仓库塞进同一项目里；SCA侧官方也强调Project是跟某个源码仓库对应的逻辑实体，目的是持续跟踪同一仓库的风险变化。

　　2、把团队树当作项目结构的主骨架

　　先按组织维度建Team层级，例如事业部到产品线到团队，项目只能挂在正确Team下；因为Teams是层级访问控制模型，上级可下钻、下级不可上卷，这个特性适合用来定义谁能看什么项目。

　　3、统一项目命名的三段式并避免把环境写进项目名

　　建议项目名采用“产品线-仓库或组件-用途”三段式，例如支付-merchant-api-sast，工具或库类再加一段，例如支付-common-lib-sast；环境与分支不要写进项目名，环境用流水线参数解决，分支用平台分支与扫描配置解决，否则项目数会爆炸且趋势不可比。

　　4、把命名约束前置到创建阶段避免后续改名牵连

　　CxSAST项目名有明确的非法字符清单，命名规范里直接禁止这些字符，并要求全员按统一大小写与分隔符执行，能避免创建时失败或后期因改名导致CI变量、报表订阅、权限映射一起改。

　　5、单仓多模块的结构用“应用分组加子项目”而不是堆一个大项目

　　如果是单仓多服务，建议用应用或产品线分组管理，再按可独立交付模块建立多个项目，扫描范围用包含与排除规则限制到对应目录，避免一个项目里同时扫到多条技术栈导致规则集、误报口径、整改责任无法落到人。

　　6、把CI里的项目名与团队路径参数化并集中维护

　　对Jenkins或其他CI集成，把项目全路径与Team路径做成统一变量模板，集中在流水线库或共享配置里维护，避免每条流水线各写一份导致路径不一致；需要全路径时按集成要求提供包含团队层级的完整名。

　　三、Checkmarx项目基线与变更怎么控住

　　项目创建与命名统一以后，真正决定你们治理成本的是基线与变更控制：谁能改项目配置，改了如何追溯，扫描结果如何保持可比。

　　1、把Preset与策略作为项目级基线固定下来

　　CxSAST创建项目时就会选择Preset，后续不要随意改动，确需调整时走评审并记录变更原因，否则同一项目不同时间段扫描口径不同，趋势图与复评会失真。

　　2、把权限变更与项目归属变更走同一条审批链

　　项目从一个Team迁到另一个Team，会直接改变可见范围；建议把Team调整纳入配置管理或变更单流程，避免临时挪动造成审计期证据断链。

　　3、用同一项目承载持续扫描，避免重复建项导致基线丢失

　　项目的价值在于同一仓库多次扫描都沉淀在同一实体下，形成趋势与对比；重复建项目会把历史结果切断，复评时很难解释为什么同一仓库出现两套不一致的风险曲线。

　　4、给每个项目固定一个归档包模板

　　建议每次发布归档至少包含项目名与Team路径、扫描触发方式与分支口径、Preset或策略版本、当次扫描时间点、导出的结果报表与整改工单链接；这样复评抽样时可以按项目一键对齐证据口径。

　　总结

　　创建Checkmarx项目时，先按平台类型走正确入口创建，再把项目分配到Team并按规则配置扫描对象；要统一项目结构与命名，就用团队树做骨架、用统一粒度口径控制项目数量、用命名约束与CI变量模板固化路径；最后用Checkmarx的项目配置基线与权限变更控制，把趋势可比与审计可追溯这两件事钉死，复评与日常整改成本会明显下降。