从技术角度 以下不是漏洞来源的是
缓冲区溢出能拿到 shell，从技SQL 注入能拖库，术角XSS 能偷 cookie——这些是度下洞源漏洞。但很多被叫成“漏洞”的不漏东西，翻到代码层面一看，从技压根不是术角那么回事。
最典型的度下洞源是弱口令。admin/admin、不漏123456、从技root/root，术角登录就进去了。度下洞源渗透测试报告里会把它列为“高危漏洞”，不漏CVSS 打分能到 9.8。从技但从技术角度看，术角系统没有做错任何事。度下洞源身份认证模块的代码逻辑完全正确：用户名对、密码对，放行。密码是“admin”不是代码的缺陷，是人的选择。你可以在代码里强制密码复杂度、加登录失败锁定、上多因素认证，但这些是安全策略，不是补丁。弱口令的本质是配置问题和管理问题，不是代码层面的漏洞。把它叫漏洞，就像说“你家门没锁所以锁有漏洞”一样别扭。
默认配置也是同理。某台 Redis 没设密码，bind 0.0.0.0，端口暴露在公网，被人写了 SSH key。报告里写“Redis 未授权访问漏洞”。Redis 的代码有 bug 吗？没有。它按设计运行，默认就是无密码、监听所有网卡。这是默认配置的安全性问题，属于运维疏忽。Nginx 默认返回版本号、Tomcat 默认管理页面没删、Elasticsearch 默认开放 9200——全是同一类。软件厂商的默认值选得烂，这是产品设计问题，不是代码缺陷。
再比如信息泄露。错误页面把堆栈打出来了，目录列表没关，.git 目录能直接访问。这些确实该修，但它们和漏洞有本质区别。漏洞是利用代码逻辑缺陷实现非预期行为——你传一个畸形参数，程序执行了它不该执行的代码。信息泄露是“东西不该放在那里，但它就在那里”。没有绕过任何检查，没有触发任何异常路径，只是访问了一个公开可得的资源。把它归为漏洞，混淆了“暴露面”和“脆弱性”两个概念。
供应链问题同样容易被误归类。Log4j 那个事，严格说漏洞在 Log4j 的 JNDI 查找逻辑里，是实实在在的代码缺陷。但“用了带漏洞的组件”本身不是漏洞。你项目里引了一个有 CVE 的库，这个事实叫“风险暴露”，不叫“你有一个漏洞”。漏洞在那个库里，不在你的代码里。很多 SCA 工具扫出一堆红色告警，把依赖版本旧等同于漏洞，这是把风险面和漏洞混为一谈。版本旧可能只是缺功能，可能那个 CVE 根本不影响你的调用方式。
还有一种更隐蔽的：业务逻辑上的“设计如此”。某电商平台允许用户把优惠券叠加使用，导致 0 元购。这是漏洞吗？从攻击者视角看，是的，能薅羊毛。从代码视角看，优惠券模块严格按照规则计算——规则就是可以叠加。问题出在产品设计时没想到这种组合。这叫业务逻辑缺陷，和 SQL 注入那种代码级漏洞是两码事。前者要改需求，后者要改代码。
区分这些有什么实际意义？因为修复路径完全不同。代码漏洞要打补丁、改逻辑、加过滤。配置问题要改配置、加策略、上基线。供应链风险要升级依赖、做 SBOM、评估影响面。把什么都叫漏洞，结果就是开发团队收到一堆“漏洞”工单，分不清哪些要改代码、哪些改配置就行、哪些其实只要加个 WAF 规则。安全团队的报告看起来很长，但优先级排不出来。
我见过一个项目，安全扫描报了 200 多个“漏洞”，开发团队直接摆烂——修不过来。后来一个个过，真正需要改代码的不到 20 个，其余全是配置、版本、信息泄露。如果一开始就分清楚，沟通成本能降一大半。
漏洞这个词被用得太泛了。技术讨论里，精确比热闹重要。缓冲区溢出是漏洞，弱口令不是。反序列化是漏洞，默认密码不是。代码写错了是漏洞，配置选错了是另一回事。把这两类东西混在一起谈，除了制造焦虑，没什么别的用。