今天（6月18日）, 国家安全部发布了一则安全提示方面的文章, 国家网络安全通报中心监测后发现, 近期有好多起供应链投毒攻击事件集中并快速地爆发了, 这些事件涉及开源软件仓库以及商用工具这两大核心的供应链场景, 相关的“供应链投毒”事件展现出攻击隐蔽性很强、影响范围宽广、危害程度颇高以及传播速度飞快的共同特性, 能够造成凭据被窃取、远程代码得以执行以及敏感数据出现泄露等极为严重的危害。
攻击来势汹汹
把软件从组件获取开始, 历经开发集成、版本分发等环节, 一直到交付终端用户使用的整个流程链条, 称作软件供应链。“供应链投毒”是一种典型的“上游污染、下游传导”模式, 这和直接针对终端的网络攻击不一样。攻击者运用劫持开发者官方账号、篡改开源代码仓库源码、污染软件安装包与发布版本等办法, 把恶意程序植入各类软件里。随着软件进行发布与更新, 这些潜伏着的“毒瘤”就被持续不断地输送到数目庞大的终端设备中去。
链条环环相扣
引发软件“供应链投毒”的, 并非是单一节点出现的安全故障, 而是全域遭受感染的系统性危机。
——传播范围不容易把控, 基础组件被成千上万的软件依靠, 一旦某个关键组件遭污染, 使用该组件的软件都会受影响, 风险会顺着代码依赖链持续扩散。
账号密钥已非安全之物, 开发环境之中, 常常存有账号密码, API密钥, 加密证书等重要凭证, 服务器里亦是如此, 一旦这些“钥匙”遭窃取,便会致使个人隐私, 工作敏感信息泄露。
终端设备沦为被操控之物, 被“投毒”的组件有可能暗自连接攻击者服务器, 接收远程下达的指令, 攻击者能够凭借此来窃取文件、数据, 甚至于把被控制的设备用以对外展开攻击、进行非法“挖矿”活动。
安全修复的周期是漫长的, 普通的漏洞, 也许一个补丁就能够解决, 然而“供应链投毒”这种情况, 往往得先去查清上游组件的问题, 接着再逐个推动下游软件进行更新, 之后还要进行测试, 最后重新发布, 整个处置成本比较高, 周期也比较长。
防护处处留心
涵盖开发厂商和运营平台, 涉及亿万终端用户, 软件供应链的安全, 离不开链条上的每一个主体, 需多管齐下, 要协同发力, 方可抵御侵袭。
——把“入口关”守好。软件开发者得坚持从官方网站那儿获取开源组件、插件以及研发工具, 防止去使用来源不清楚的网盘资源、破解版工具还有第三方安装包。在引入开源组件这个举动上, 要依靠国家级漏洞平台去核查组件漏洞以及补丁信息。
——把控住“依赖链”, 研发管理部门需构建软件物料清单管理机制, 全方位了解系统里开源组件等地情况, 包括来源、维护以及漏洞等方面, 对于长时间无人维护、来源不明、版本老旧、权限过高等情况的组件, 得及时进行替换或者降低权限使用。重点系统上线之前, 要开展代码安全检测、依赖项扫描以及恶意代码排查这样子的操作。
时刻留意“运行端”, 网络运维部门需着重强化开发环境、测试环境以及生产环境之间的隔离工作, 防止核心服务器、代码仓库还有构建平台直接于公网呈现。针对服务器出现异常外联、陌生进程启动、异常账号登录以及流量突然升高这般的状况, 要即刻进行预警处置。一旦发现高风险组件, 就得马上排查受影响的系统, 迅速升级安全版本；要是暂时没办法升级, 那就得采取断网隔离、关闭相关功能以及回退安全版本等举措。
首先, 要把“责任方”给梳理清楚。对于单位用户而言, 需要确切地明确软件供应链安全责任部门所涉及的具体范围, 以及明确责任人究竟是谁。然后, 要把开源组件使用、第三方软件采购、系统上线验收、安全更新处置这些方面都纳入日常管理范畴之内。在采购商业软件、外包开发以及技术服务的时候, 应当在合同里面对安全检测、漏洞修复、组件来源、数据保护、应急响应责任等方面都做出明确的规定, 绝不能仅仅侧重于功能方面, 而对安全问题不闻不问。
通过官方网站、正规应用商店下载软件, 避开“非官方”, 个人用户不随意安装破解版、绿色版以及来历不明的插件, 不轻易运行陌生脚本和命令。收到软件更新提示时, 优先核实来源, 不点击不明链接下载所谓“补丁包”“增强版”“内部版”。
