作者简介：宋荆汉，网安加学院院长，深圳创新方法研究会理事、深圳质量协会专家委员，网安加社区、质量实干派社区创始人。20年研发及管理经验，在中兴通讯、任子行网络，全志科技、汇金科技，担任研发管理高管，曾参与国家测试与安全类职业认证标准、国家软件安全开发相关标准的制定，对软件安全开发有比较深入的研究。曾为多家世界500强企业提供研发管理培训及咨询。
一、前言
近年来，人工智能技术的迅猛发展已将生成式AI(AIGC)推至软件开发的前沿阵地。诸如GitHub Copilot与ChatGPT等AIGC先锋，凭借深度学习模型的强大力量，正深刻改变着编程的方式。
它们不仅能深入剖析代码的语义逻辑，助力开发者迅速掌握遗留项目代码的维护，还能根据简短的提示，智能生成代码片段，极大地加速了开发效率的提升。
面对这一技术浪潮，主流的静态应用安全测试(SAST)厂商亦不甘落后，纷纷将AIGC大模型技术融入其产品中，力求在代码安全领域实现创新迭代。
不同于传统SAST工具仅止步于漏洞的发现，这些创新产品借助大模型的能力，不仅精准定位漏洞，更提供详尽的漏洞描述与针对性的修复建议。更令人瞩目的是，它们能直接生成修复后的代码，有效解决了“检测易，修复难”的痛点，让开发人员与安全团队之间的合作更加顺畅，彻底颠覆了“管杀不管埋”的旧有印象。
然而，正如任何技术革新都伴随着挑战与风险，AIGC在提升编程效率的同时，也悄然埋下了安全隐患。
本文旨在剖析AIGC生成代码所面临的主要安全风险，并探索一系列行之有效的应对措施，引导行业在享受技术红利的同时，也能稳健前行，确保软件系统的安全与可靠。
二、基于AIGC代码生成的安全风险
通过引入代码自动生成技术，工作效率显著提升，然而，这一进步也引发了对于生成代码安全性的深切关注。
据参考文献1中针对Copilot工具生成的代码进行的安全性研究报告揭示，研究团队精心设计了涵盖CWE(常见弱点枚举)中的18个大类下的54个具体场景，Copilot成功输出了1087个有效程序。
然而，在这些程序中，令人担忧的是，高达477个(占比43.88%)被发现含有CWE定义的漏洞。
进一步按编程语言细分，C语言的表现尤为堪忧：在25个测试场景中生成的516个程序中，竟有258个(占比高达50%)存在安全漏洞。
相比之下，Python虽然情况稍好，但在29个场景下的571个程序中，仍有219个(38.4%)存在安全隐患。
参考文献2的研究则为我们提供了另一维度的洞察。
该研究在452个代码片段中总共识别出了544个安全问题，下表详尽统计了不同编程语言文件中安全弱点的分布情况。
而且根据文献4的研究显示，通过AIGC生成的代码中，比较擅长规避语法类的CWE漏洞，如：
CWE 121 - Stack-based Buffer Overflow
CWE 787 -Out of bounds Write
CWE 79 -Cross Site Scripting
CWE 416 -Use After Free
CWE 125 -Out of Bounds Read
CWE 476 - NULL Pointer Dereference
CWE 119 -Improper Restriction of Operations
而在自动生成代码中发现漏洞通常是外部输入相关的，如：
CWE 20 -Improper Input Validation
CWE 502 -Deserialization of Untrusted Data
CWE 78 -OS Command Injection
CWE 22 -Path Traversal
CWE 434 -Unrestricted Upload of File with
Dangerous Type
CWE 522 -Insufficiently Protected Credentials
生成的代码之所以潜藏安全风险，根源在于AI训练所依赖的代码素材主要源自开源代码库。
然而，Synopsys新思科技发布的《开源安全和风险分析报告》(OSSRA)2024版揭示了一个严峻的现实：在这些开源代码中，有53%面临着许可证冲突的问题，31%则缺乏明确的许可证或采用自定义许可证，这直接触及了合规性风险。
更令人不安的是，高达84%的代码库含有漏洞，其中74%更是被归类为高风险漏洞，这无疑是对安全性的重大挑战。
根据上面漏洞类型分析，我们不难发现，开源软件在输入处理方面普遍存在疏漏，而相比之下，语法层面的错误却得到了相对较多的关注与修正。
这反映出，尽管开源社区在推动技术创新与共享方面功不可没，但在安全性与合规性方面的努力仍有待加强。
鉴于此，当AI模型从这样一个充满风险与合规挑战的开源代码库中学习时，其输出的代码自然难以摆脱这些固有问题的阴影。
因此，AI生成的代码不仅可能不安全，还同样面临着合规性的严峻考验。
OWASP(开放式Web应用安全项目)发布了针对大型语言模型(LLM)应用的Top 10潜在安全风险如下：
1. Prompt lnjection(提示注入)：通过精心制作的输入操纵LLM，绕过内容监管过滤，执行非法操作。
2. Insecure Output Handling(不安全的输出处理)：未验证LLM输出可能导致下游安全漏洞，如代码执行。
3. Training Data Poisoning(训练数据中毒)：被篡改的训练数据可能导致模型响应不当，影响安全、准确性。
4. Model Denial of Service(模型拒绝服务)：通过资源密集型操作过载LLM，导致服务中断。
5. Supply Chain Vulnerabilities(供应链漏洞)：依赖于被破坏的组件、服务或数据集，危及系统完整性。
6. Sensitive Information Disclosure(敏感信息泄露)：LLM在响应中意外泄露敏感数据。
7. Insecure Plugin Design(不安全的插件设计)：自动调用的插件可能存在输入不安全和缺乏访问控制的问题。
8. Excessive Agency(过度代理)：基于LLM的系统被赋予过多的功能、权限或自主权。
9. Overreliance(过度依赖)：在没有监督的情况下过度依赖LLM可能导致错误信息和安全漏洞。
10. Model Theft(模型盗窃)：未经授权的访问、复制或泄露LLM模型。
其中，2、3、5、9均与生成代码的安全性相关，也应证了上述的分析。
我们总结AIGC生成代码的安全风险主要在3个方面：
(1) 采用的底层技术导致的幻觉问题，使得生成的代码本身存在错误可能性；
(2) 训练样本污染，导致生成的代码存在安全漏洞；
(3) 同样会引入开源组件代码，带来难以排除的合规性风险。
三、风险的应对
在应对AIGC生成代码安全风险时，首先要对其有正确的认识，AIGC自动生成的代码与自己写的代码，包括引用的开源组件一样，都存在安全风险及合规性风险。
AIGC生成的代码，也需要经过严格的验证，高效的验证手段其实可以更好的推广AIGC生成代码的应用，现在的SAST/IAST/DAST/SCA等应用安全检测工具，对AIGC生成代码的安全性依然起着关键的作用。
针对LLM TOP10中与生成代码安全相关风险的应对措施：
▪︎ LLM02、Insecure Output Handling(不安全的输出处理)
首先要对生成的代码进行严格的安全验证，同时要改进代码训练与与提示，具体包括：
①代码审查。
②代码自动化扫描，使用AST工具扫描代码识别潜在安全漏洞。
③零信任原则，对LLM生成的任何代码持怀疑态度，进行彻底的安全验证后再集成到项目中。
④优化训练数据，提高代码样本质量，定期清理与审查有安全漏洞的样本。
⑤构建安全提示词，提供明确的安全提示，引导LLM生成更安全的代码。例如，在提示中包含输入验证和清理的代码片段。
▪︎ LLM03、Training Data Poisoning(训练数据中毒)
①训练数据样本供应链的验证，尽可能从可信、权威的渠道获取训练数据，减少数据被污染的风险。如果条件允许，可以尝试从多个独立的数据源获取相同或类似的数据，通过比对来识别潜在的数据中毒情况。
②优化训练数据。
▪︎ LLM05、Supply Chain Vulnerabilities(供应链漏洞)
①生成并维护生成代码的SBOM。
②开源组件的安全与合规性扫描。
③LLM应用开发供应链安全监控。
④引用可信组件库。
▪︎ LLM09、Overreliance(过度依赖)
①建立安全编码规范。
②提升开发人员应用LLM时的安全意识。
③实施代码审查。
④代码自动化扫描。
四、总结及展望
AIGC技术在显著提升编程效率的同时，也带来了新的安全风险，这一事实再次印证了软件工程领域不存在“银弹”。
面对这一挑战，我们必须采取多维度、综合性的策略来有效应对AIGC生成代码所带来的安全隐患。
加强代码审查与测试是基石，确保每一行代码都经过严格的质量与安全把关。
同时，提升数据保护措施，构建严密的信息安全网，是保障技术安全的另一重要环节。
此外，优化算法模型，通过模型对齐等先进技术，让AIGC生成的代码从源头上就具备安全性，这无疑是解决安全问题的根本之道。
在法规与行业标准的层面，完善相关法律法规，制定统一的行业标准，为AIGC技术的应用提供明确的指导和规范，也是不可或缺的。
同时，提高用户透明度和信任度，让用户对AIGC技术的运作原理和安全机制有更深入的了解，从而增强用户的信心和安全感同时也提升应用新技术时的安全风险意识。
未来，我们应持续关注AIGC技术的发展动态和安全风险变化趋势，以科学的方法论为指导，不断完善和优化安全管理体系和技术手段，确保AIGC技术在健康、安全的轨道上持续发展。
参考文献
[1]An Empirical Cybersecurity Evaluation of GitHub Copilot’s Code Contributions.https://arxiv.org/pdf/2108.09293v2.pdf
[2]Security Weaknesses of Copilot Generated Code in GitHub.arXiv:2310.02059v2 [cs.SE] 4 Apr 2024
[3]Is GitHub’s Copilot as Bad as Humans at Introducing Vulnerabilities in Code?.arXiv:2204.04741v5 [cs.SE] 6 Jan 2024
[4]Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions.2022 IEEE Symposium on Security and Privacy (SP) | 978-1-6654-1316-9/22/$31.00 ©2022 IEEE | DOI: 10.1109/SP46214.2022.9833571
