一、小白剧场

小白：大东，我刚看完一部关于AI编程的纪录片，真是太震撼了！

大东：哦？说说看，什么让你这么激动？

小白：他们展示了AI如何自动生成代码，甚至有人声称AI可以完全取代程序员。

大东：这听起来确实令人兴奋，但你知道吗，最近有一篇文章揭示了AI编程中的一些安全隐患。

小白：真的吗？AI不是应该让编程更安全吗？

大东：理论上是这样，但实际情况可能更复杂。

小白：那我们来聊聊这个话题吧，我很好奇。

二、话说事件

小白：大东，你说AI编程生成的代码不安全，这话有点吓人。

大东：别光听热闹，这事儿得追溯到一次代码审查大行动。

小白：是哪个行动啊？有具体背景吗？

大东：是一位名叫Alex Birsan的安全研究员做的实验，他把57.6万行AI生成的代码撕开来分析。

小白：哇，这么多代码？是哪个模型写的？

大东：主流的AI编程工具，像GitHub Copilot、CodeWhisperer，都有份参与。

小白：它们不是很智能吗？还能帮我自动补全代码呢。

大东：对，它们很方便，但也很“懒”，很多时候不加验证就引入包。

小白：不加验证？什么意思？

大东：就是说，只要看到某个功能缺失，它就直接引入一个看似相关的依赖包。

小白：可那不是好事吗？能帮我省不少事。

大东：问题就在这，“幽灵包”也能被它们引进来。

小白：你又提到“幽灵包”了，这到底是什么？

大东：是指那些名字正宗、功能模糊、但没人维护的包，或者干脆就是恶意包。

小白：那这些包具体藏在哪儿？是npm那种库吗？

大东：对，npm、PyPI、甚至RubyGems，都有。AI生成的代码很多会调用这些。

小白：那如果包是假的，我一运行代码岂不是中招？

大东：是的。比如有个叫requests3的包，就模仿了Python里正经的requests库。

小白：哎呀，我还真用过那个假包一次，当时就感觉不太对。

大东：你看你也差点中招。现在AI生成代码默认就引用这些，你敢用？

小白：那我们怎么知道哪些是幽灵包？

大东：这个问题难在“伪装”。Birsan发现，20%的包是“幽灵”，但名字都看不出问题。

小白：那是不是有人故意注册这种名字？

大东：没错，这种行为叫做“包投毒”。攻击者专门抢注那些大公司常用的依赖名。

小白：抢注包？就像抢注商标一样？

大东：一模一样。比如苹果在内网里用internal-core，结果外网没人注册，攻击者抢先了。

小白：天哪，那代码跑起来不就自动连上了恶意地址？

大东：是的。Birsan用这个方法让苹果、微软、PayPal等几十家公司“自动上线”。

小白：上线？你是说他们的系统自己把恶意包拉下来了？

大东：是的，AI生成的代码再加上一点CI/CD自动部署。

小白：这也太离谱了，那AI不就成了攻击者的“物流员”？

大东：哈哈，说得好。AI自己都不知道它在搬运炸弹。

小白：那这些AI工具的开发者不担心吗？

大东：他们也焦虑，所以现在一些平台开始加黑名单机制，比如过滤已知恶意包。

小白：那有没有白名单？

大东：白名单更难做，因为好包也会变坏。一个包五年前正常，现在可能被黑了。

小白：所以还是得靠人肉审核？

大东：对，AI可以给建议，但关键地方不能让它全权决定。

小白：那我们怎么才能“干净地”用AI生成代码？

大东：第一是手动审查引入的包。第二是配置锁定版本。第三是用内部仓库镜像。

小白：听起来像DevSecOps的活儿。

大东：说得对，安全早就不是事后处理了，而是写代码那一刻就该开始。

小白：那AI生成的代码，开发完是不是还要跑扫描？

大东：必须的。静态扫描、依赖漏洞检查、SAST、DAST，一个都不能少。

小白：真是“生成容易、清洗艰难”啊。

大东：你说得太对了，AI让开发变快了，也让出问题变快了。

小白：那用户能不能一键识别这些幽灵包？

大东：现在有些开源工具能部分识别，比如OSV-Scanner和npm audit。

小白：那我能不能写个工具，结合AI做实时过滤？

大东：这是个好主意，但前提是你得比AI更懂AI，别让它反客为主。

小白：明白了，得把AI当助手，不是当保姆。

大东：更不能当上帝，别让它“神化”。这就是57.6万行代码告诉我们的真相。

三、大话始末

小白：大东，这种“AI拉幽灵包”的事是不是第一次发生？
大东：当然不是，AI只是放大了问题，根源早就有了。
小白：那以前有啥类似事件？我得长点记性。
大东：第一个得提2017年left-pad事件。
小白：就是那个被删了的小函数？还引发了大瘫痪？
大东：对。作者一怒删库，成千上万项目编译失败。
小白：这不就是依赖太重、审核太少的锅？
大东：说白了，大家都懒得管小依赖，AI现在更懒。
小白：那后面还有啥事比这更严重吗？
大东：2021年，有人上传恶意PyPI包模拟urllib。
小白：那不就是钓鱼包？名字一模一样。
大东：对，叫做“typosquatting”，就是利用拼写错误。
小白：我还真写错过requesrs，要不是IDE提醒就中招了。
大东：现在AI帮你写代码，错得更自然。
小白：这听起来像是“自动化入坑”。
大东：你说得对。还有个更吓人的是2022年的ctx事件。
小白：我没听过，是啥？
大东：一个开发者发现没人维护，就偷偷把包接管了。
小白：结果呢？
大东：更新版本后在里面加了窃密代码，好多项目都中招。
小白：这跟GitHub Copilot不设限很像。
大东：AI只看代码功能，不看开发者信用，风险翻倍。
小白：那开源项目现在岂不是得步步惊心？
大东：还有2023年爆的Xz Utils事件，更惊心。
小白：不是那个压缩工具吗？我Linux里天天用。
大东：对啊，居然被潜伏两年，加入后门。
小白：是AI干的吗？
大东：不是，但AI可以学它的代码，继续传染。
小白：太阴了！这也太像“木马教师”了。
大东：你形容得不错，AI一旦吃进恶意样本，就有了“错觉经验”。
小白：那我们是不是要给AI喂点“清洁食谱”？
大东：说得好！安全训练数据，是AI时代的防毒面包。
小白：那像这种“依赖地雷”，AI平台能预防吗？
大东：目前还很弱，它们大多以功能优先，不查信誉。
小白：那企业该咋做？天天盯源码审计？
大东：首先，建立“依赖包准入机制”。
小白：啥意思？
大东：就是说，每个包都得过一遍认证、标签、签名检查。
小白：那不是像机场安检一样？
大东：对！别让AI变成没刷身份证的黑车司机。
小白：那是不是还得加“代码防火墙”？
大东：你真是学快了。SCA、SBOM、Runtime Guard，一个不能少。
小白：我看现在流行“最小依赖”原则，跟这事有关？
大东：当然。引入越少，风险越低。AI的“贪心”正好相反。
小白：那AI平台会不会以后被强制加安全插件？
大东：这趋势已经开始了，像Copilot加了安全过滤层。
小白：那像国内平台呢？
大东：华为、百度也在做“可信生成”，不过标准还没统一。
小白：那这场AI编程风暴最后会往哪儿走？
大东：要么变成安全沙箱，要么变成黑客天堂。
小白：听你这么说，我都不敢用AI写代码了。
大东：别怕，关键是要带着怀疑看结果，别盲信。
小白：那我们是不是得重新定义“安全AI编程”？
大东：应该叫“零信任AI开发”，让每一行代码都可追溯。
小白：听起来像AI时代的“数字指纹”？
大东：没错，代码来源、生成模型、依赖包都得打标识。
小白：那我们以后开发，是不是得像“做账”一样留痕？
大东：你终于明白了，AI时代，代码也是资产。

四、小白内心说

小白：今天和大东的对话让我深刻意识到，AI编程虽然带来了便利，但也隐藏着不少安全隐患。特别是那些看似无害的依赖包，可能成为攻击者的突破口。作为开发者，我们不能盲目依赖AI生成的代码，而应保持警惕，定期审查项目中的依赖项，确保每一行代码的安全性。只有这样，我们才能在享受技术进步的同时，保障系统的安全。

来源: CCF科普