经常困扰很多软件QA人员的一个问题是，由于对软件技术了解不足，很难与研发人员进行平等的沟通，同时也不能有效地识别软件中的风险。
主要因为QA是通过过程保证来确保结果质量，所以过程审计是最常用的方法。但审计提出的不符合项是风险，如果无法解释对结果的具体影响，往往会被研发视为纯粹的吹毛求疵而忽略。另外，由于该过程是应对最坏情况，很多风险可能不会发生，因此软件QA工作的价值无法体现。
通过对一起震惊中外的质量事故的分析，宋老师思考如何在过程中运用大模型来防范软件质量问题。
一、中国工商银行美国子公司勒索病毒事件概述
中国工商银行金融服务部遭受勒索软件攻击。
背景：中国工商银行（ICBC）是中国最大的商业银行之一，总部位于北京，业务遍布全球，对国内外经济发展具有重大影响。2023年11月8日，工行美国子公司工银金融服务部遭受勒索病毒攻击，导致部分金融服务系统中断，不得不采取非正常手段完成交易。
活动流程：
事件分析：Lockbit使用的勒索病毒为LockBit3.0，入侵方式可能与CVE-2023-4966漏洞有关，该漏洞存在于Citrix NetScaler设备中，攻击者利用未打补丁的设备进行入侵。漏洞原理是对snprintf函数返回值处理不当导致缓冲区溢出，从而泄露敏感信息。Lockbit3.0采用双重勒索方式，先窃取文件再加密，增加勒索成功的可能性。
CVE-2023-4966是Citrix的一个缓冲区溢出漏洞，由于Citrix开发人员对snprintf函数返回值的理解错误，导致缓冲区越界读取，从而造成敏感信息（会话cookie）的泄露。
该漏洞位于/netscaler/nsppe二进制文件中。nsppe是NetScaler的数据包处理引擎，其中包含完整的TCP/IP网络堆栈和多个HTTP服务。在13.1-49.15和13.1-48.47中nsppe的对比中可以发现ns_aaa_oauth_send_openid_config和ns_aaa_oauthrp_send_openid_config进行了额外的边界检查。这两个函数分别可以通过/oauth/idp/.well-known/openid-configuration和/oauth/rp/.well-known/openid-configuration以非认证方式访问。
该漏洞的C语言代码如下：
iVar3 = snprintf(print_temp_rule,0x20000, "{\"issuer\": \"https://%.*s\", \"authorization_endpoint\": \"https://%.*s/oauth/ idp/login\", \"token_endpoint\": \"https://%.*s/oauth/idp/token\", \"jwks_uri\": \"https://%.*s/oauth/idp/certs\", \"response_types_supported\": [\"code\", \"toke n\", \"id_token\"], \"id_token_signing_alg_values_supported\": [\"RS256\"], \"end _session_endpoint\": \"https://%.*s/oauth/idp/logout\", \"frontchannel_logout_sup ported\": true, \"scopes_supported\": [\"openid\", \"ctxs_cc\"], \"claims_support ed\": [\"sub\", \"iss\", \"aud\", \"exp\", \"iat\", \"auth_time\", \"acr\", \"amr \", \"email\", \"given_name\", \"family_name\", \"nickname\"], \"userinfo_endpoin t\": \"https://%.*s/oauth/idp/userinfo\", \"subject_types_supported\": [\"public\"]}" ,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8);authv2_json_resp = 1;iVar3 = ns_vpn_send_response(param_1,0x100040,print_temp_rule,iVar3);br
这段代码的漏洞在于，snprintf 函数的返回值被用作 ns_vpn_send_response 函数返回给客户端的字节数。编写这段代码的人可能以为 snprintf 函数返回的数据大小会在 0 到第二个参数之间，比如这里的 0~0x20000。然而，snprintf 的返回值并不是写入 print_temp_rule 的长度，而是格式化字符串拼接后的实际长度。
综上所述，该事件的根本原因是软件代码存在BUG，导致缓冲区溢出一起吧软件怎么样，黑客利用该漏洞对银行进行勒索。
2.软件开发过程回顾
软件开发过程通常经过以下步骤：需求-设计-开发-测试。
从事件描述中，我们可以初步判断该缺陷是在代码编写阶段引入的。
为什么不在需求和设计阶段就解决呢？因为从设计的粒度上来说，一般不可能细化到一行代码，而且修复代码片段就可以避免问题，而且避免缓冲区溢出是软件开发人员的常识性问题，通常不会在设计中特别强调。既然设计问题被排除，需求出现的可能性就更小了。
另外，代码写完之后，一般都会经过代码评审、静态检查、单元测试、集成测试、系统测试等一系列质量管控手段，杜绝缺陷。为什么还是会泄露呢？这个问题确实值得分析。
这个缺陷应该在代码审查阶段就被发现。但为什么没有被发现呢？
在软件开发的世界里，代码审查扮演着“质量卫士”的角色。通过同行评审，旨在发现并修复代码中的错误，提高代码的整体质量。然而，即使在最严格的审查过程中，仍然会有漏洞“漏网”，主要原因如下：
1. 审阅者的专业知识和经验 2. 代码复杂性和可读性 3. 审阅流程和工具限制 4. 审阅者的认知偏差 5. 人为因素 6. 代码变更范围和频率 7. 测试和审阅之间的联系总结
虽然代码审查是提高代码质量的有效手段，但由于上述因素，它并不能保证发现所有错误。有效的代码审查需要专业知识、严格的流程、合适的工具、清晰的意识和良好的测试策略的结合。为了最大限度地减少遗漏的 Bug一起吧软件怎么样，团队应该不断提高代码审查的质量，并积极采用自动化工具来辅助审查过程。
3. 大模型如何赋能软件开发过程
这个问题很明显是团队代码审查质量的问题，但是如果通过自动化工具辅助是可以弥补的，大模型刚好可以发现这个问题，国内开源大模型就可以达到这个效果。
我使用了清华大学的大模型“智浦清研”，大模型对出现问题的代码片段进行了分析，也找到了本次出现的问题。
具体问询流程如下：
开源模式不仅可以识别潜在的问题，还可以提供修复代码的建议。
大型模型的扫描时间几乎以秒为单位，加上修复时间，估计一个小问题30分钟就能修复，给市场造成的损失估计至少在几百万甚至几千万。
此次事故也充分证明，缺陷修复越早，成本越低。
4. 对软件质量保证的影响
新技术的出现显然可以帮助软件QA更好地管控软件流程，在大模型工具出现之前，也有自动化的代码审查工具，很多公司在应用时，通常会制定代码审查检查规则，然后导入到代码审查工具中。
但最大的问题是，如果软件 QA 不懂软件编程技术，他们只能看到自动化工具扫描的结果，然后让研发根据控制基线对扫描发现的风险代码进行修复。但由于规则本身比较抽象，不懂软件技术的人很难理解。另外，由于代码语义的复杂性，基于规则的工具经常存在误报，即使发现问题，工具也无法提供具体的代码级修复方案，这让软件 QA 很难确认修改的正确性和完整性。
但大模型的出现显然可以帮助我们进一步优化流程。
大致流程是：开发编写代码——代码审查——发现问题并修复代码
现在你可以：开发编写代码-大模型插件检测-修复代码-进入codeview，这样有几个好处
1.这使得缺陷可以在早期阶段被发现并纳入编码过程;
2、代码检测与修复让软件QA更加可见、可控、可观察，即使不懂软件技术，也可以更好地监督问题的发现和解决；
当然，大模型也可以融入到软件开发流程中，帮助软件QA更好的预防缺陷，后面宋老师会一步步给大家介绍。
我们已经步入了全新的AI时代，在这一波技术革命中，AI技术无疑将为现有的软件流程带来前所未有的推动力和革新。请记住，这并不是说AI会取代我们，而是懂得使用AI的人会超越那些对AI技术视而不见的人。
所以，亲爱的QA同学们，现在是时候让我们积极拥抱AI，不断学习，不断进步，用智慧和勇气抓住这个时代的机遇了。在这个充满无限可能的AI时代，只有敢于领先和探索的人，才能成为真正的领导者和赢家。
