SpotBugs可变对象引用暴露告警的该修复方式为何生效？

问题复现 #

最初实现返回内部Socket类型可变字段的getter方法时，采用直接返回字段引用的写法：

public Socket getSocket() {
 return socket;
}

对该代码执行SpotBugs静态扫描时，会触发恶意代码漏洞类告警，具体告警条目如下：

• 恶意代码漏洞
• 方法返回数组可能暴露内部表示
• 返回可变对象引用可能暴露内部表示
• getSocket()返回类内部socket字段存在风险

将方法调整为如下实现后，所有SpotBugs告警完全消失：

public Socket getSocket() {
 List<Socket> sockets = new ArrayList<>();
 sockets.add(socket);
 List<Socket> immutableSockets = Collections.unmodifiableList(sockets);
 return immutableSockets.get(0);
}

核心疑问 #

已知SpotBugs是基于字节码而非源代码开展静态分析，上述两种写法最终均返回同一个可变Socket对象的引用，逻辑上完全等价，按常理这类简单逻辑经编译器优化后字节码表现应一致，为何后者不会触发告警？

目前针对该现象有三种推测：

1. 对SpotBugs的检测逻辑认知有误，它并非仅分析字节码，也会识别源码结构，因此可被第二种写法绕过
2. 该现象属于SpotBugs的检测逻辑缺陷
3. 第二种写法实际并未返回原可变对象的引用，和第一种写法存在本质差异

补充说明：该规避方案对所有同类SpotBugs告警（包括“存储可变对象引用”类告警）均有效，示例中的Socket可替换为任意可变对象，两种写法本质都向外返回了内部可变对象的引用，检测结果却完全不同。

原因解释 #

这个现象的核心原因是第二条推测成立：这属于SpotBugs静态检测规则的固有局限，两种写法的运行逻辑和实际风险没有任何差异。

• SpotBugs对「可变内部引用外泄」类漏洞的检测是基于浅层字节码特征匹配+有限数据流分析实现的，不会做全链路的跨方法、跨容器引用追踪——全程序深度分析的性能开销极高，根本无法在常规开发流程的扫描场景落地。
• 第一种写法的字节码逻辑非常直白：加载当前类实例、读取socket成员字段、直接返回，完全命中SpotBugs预置的「getter直接返回可变成员字段」的漏洞特征，所以必然触发告警。
• 第二种写法的字节码里插入了大量中间操作：初始化ArrayList、调用add方法存入字段、调用Collections.unmodifiableList包装列表、调用get方法取元素返回。SpotBugs的默认规则不会深入跟踪这一串操作里的引用流向，只会判定最终返回值来自不可变列表的查询结果，不符合直接返回内部字段的特征，自然不会报出告警。
• 需要明确：第二种写法没有任何实际的安全防护作用，和直接返回字段引用的风险完全一致——调用方拿到Socket实例后依然可以随意修改对象状态、破坏类的内部封装，纯粹是靠绕开检测规则消掉了告警，绝对不能当成正式的漏洞修复方案。
• 这类问题的正确修复思路要结合业务场景选择：如果确实需要对外暴露内部可变对象，就返回对象的深拷贝副本；如果不需要调用方修改对象状态，就封装一层不可变的视图代理；如果方法只在内部可信范围调用，就收紧访问权限，不要暴露给不受信任的外部调用方。

内容的提问来源于stack exchange，提问作者rebit