供应链破坏指攻击者通过篡改产品开发、分发或交付环节中的任意节点，在合法软件/硬件中植入恶意功能的行为。其利用供应链各参与方之间的信任关系，使受污染产品通过验证机制流向最终用户。传统防御主要依赖代码签名验证、哈希完整性校验及物理设备安全检查，通过检测异常文件特征或供应链异常事件进行防护。
为规避传统检测手段，攻击者发展出深度嵌入供应链流程的隐蔽攻击技术，通过污染可信分发渠道、劫持合法更新流程、预置固件级后门等手法，使恶意载荷获得数字签名认证与供应链各环节的形式合规性，实现攻击行为的"合法化"伪装。
现有供应链破坏匿迹技术的共性在于对信任传递机制的逆向利用与攻击链的多层嵌套。开源依赖投毒利用开源社区协作模式中的自动化信任，将恶意代码植入广泛使用的底层组件；软件更新劫持通过控制数字签名体系与分发网络，使攻击流量与正常维护行为完全同构；硬件固件预植入则突破软件安全边界，在硬件抽象层建立持久化控制通道。三类技术的核心策略是深度融入供应链业务流程，通过合法技术组件的异常组合使用（如签名证书与恶意代码的结合）、硬件信任基的隐蔽滥用（如固件未公开接口的恶意调用），构建出难以通过单点检测识别的复合型攻击面。
匿迹技术的演进使得传统基于特征匹配或单环节审计的防御体系面临失效风险，需构建覆盖全供应链的深度验证机制，包括多层级代码溯源、硬件指纹动态校验、构建环境完整性证明等技术，同时建立供应链参与方之间的威胁情报协同机制，实现攻击链的早期发现与联合遏制。
| 效应类型 | 是否存在 |
|---|---|
| 特征伪装 | ✅ |
| 行为透明 | ❌ |
| 数据遮蔽 | ✅ |
| 时空释痕 | ❌ |
攻击者通过数字签名伪造、合法协议滥用等手段，使恶意组件具备形式合规性。通过将恶意代码伪装成常规软件或更新的方式，将恶意行为掩藏在正常的系统操作中。例如篡改的软件更新包保留有效代码签名，恶意固件复用硬件厂商认证证书，使得防御方难以通过表面特征识别异常。
攻击者运用开源依赖投毒技术，在广泛使用的开源项目中植入恶意代码，精心处理恶意代码的数据层面信息。攻击者将恶意代码巧妙融入开源项目中，把恶意功能的实现拆分成多个看似普通的代码片段，分散在不同的代码模块与函数里。这使得防御者在检查相关产品代码时，难以准确识别恶意意图，实现了数据遮蔽匿迹效应。
| ID | Name | Description |
|---|---|---|
| G1003 | Ember Bear |
Ember Bear has compromised information technology providers and software developers providing services to targets of interest, building initial access to ultimate victims at least in part through compromise of service providers that work with the victim organizations.[1] |
| S1148 | Raccoon Stealer |
Raccoon Stealer has been distributed through cracked software downloads.[2] |
| G0034 | Sandworm Team |
Sandworm Team staged compromised versions of legitimate software installers on forums to achieve initial, untargetetd access in victim environments.[3] |
| ID | Mitigation | Description |
|---|---|---|
| M1013 | Application Developer Guidance |
Application developers should be cautious when selecting third-party libraries to integrate into their application. Additionally, where possible, developers should lock software dependencies to specific versions rather than pulling the latest version on build.[4] |
| M1046 | Boot Integrity |
Use secure methods to boot a system and verify the integrity of the operating system and loading mechanisms. |
| M1033 | Limit Software Installation |
Where possible, consider requiring developers to pull from internal repositories containing verified and approved packages rather than from external ones.[4] |
| M1051 | Update Software |
A patch management process should be implemented to check unused dependencies, unmaintained and/or previously vulnerable dependencies, unnecessary features, components, files, and documentation. |
| M1018 | User Account Management |
Implement robust user account management practices to limit permissions associated with software execution. Ensure that software runs with the lowest necessary privileges, avoiding the use of root or administrator accounts when possible. By restricting permissions, you can minimize the risk of propagation and unauthorized actions in the event of a supply chain compromise, reducing the attack surface for adversaries to exploit within compromised systems. |
| M1016 | Vulnerability Scanning |
Continuous monitoring of vulnerability sources and the use of automatic and manual code review tools should also be implemented as well.[5] |
| ID | Data Source | Data Component | Detects |
|---|---|---|---|
| DS0022 | File | File Metadata |
Use verification of distributed binaries through hash checking or other integrity checking mechanisms. Scan downloads for malicious signatures and attempt to test software and updates prior to deployment while taking note of potential suspicious activity. |
| DS0013 | Sensor Health | Host Status |
Perform physical inspection of hardware to look for potential tampering. Perform integrity checking on pre-OS boot mechanisms that can be manipulated for malicious purposes and compare against known good baseline behavior. |