当前位置：首页 > news >正文

⸢ 伍-Ⅰ⸥ ⤳ 默认安全治理实践：软件供应链安全治理

news 2025/9/23 8:41:04

👍点「赞」📌收「藏」👀关「注」💬评「论」

在金融科技深度融合的背景下，信息安全已从单纯的技术攻防扩展至架构、合规、流程与创新的系统工程。作为一名从业十多年的老兵，将系统阐述数字银行安全体系的建设路径与方法论，旨在提出一套可落地、系统化、前瞻性的新一代安全架构。

序号	主题	内容简述
1	安全架构概述	全局安全架构设计，描述基础框架。
👉2	默认安全	标准化安全策略，针对已知风险的标准化防控（如基线配置、补丁管理）。
3	可信纵深防御	多层防御体系，应对未知威胁与高级攻击（如APT攻击、零日漏洞）。
4	威胁感知与响应	实时监测、分析威胁，快速处置安全事件，优化第二、三部分策略。
5	实战检验	通过红蓝对抗演练验证防御体系有效性，提升安全水位。
6	安全数智化	运用数据化、自动化、智能化（如AI）提升安全运营（各部分）效率。

5 默认安全治理应用实践

5.1 软件供应链安全治理

5.1.1 四类核心风险

5.1.2 应对策略（增量风险）

5.1.2.1 攻防对比

1.日常办公工具与软件

2. 三方组件

3. 三方软件

5.1.2.2 治理方案

1. 收敛渠道：统一入口，缩小攻击面

2. 严格准入：建立安全审批与检测流程

3. 主动发现：构建“静态+动态”检测体系

4. 风险分决策：引入元数据评估，降低误报

5.1.3 理清台账（存量风险）

5.1.4 隔离防护：划定边界，遏制横向扩散

👍点「赞」➛📌收「藏」➛👀关「注」➛💬评「论」

5 默认安全治理应用实践

本部分将从实际应用角度，介绍行业典型安全风险痛点方面的具体实践。选取的案例包括：

软件供应链安全治理（本文内容）
水平越权漏洞检测
前端安全风险防控

5.1 软件供应链安全治理

“供应链”概念起源于制造业，指产品从原材料供应、制造到零售的全过程链。
“软件供应链”与之类似，是指：软件从设计、开发到交付最终用户所经历的多个阶段，涵盖代码、人员、系统与流程等内外部环节。

5.1.1 四类核心风险

随着技术迭代加速和系统复杂度的提升，开源代码在应用中的占比已从五年前的40%增至70%以上。虽然显著提升研发效能，但也带来多重风险：

风险类型	具体表现与案例
🔓 信息安全风险	如Log4j漏洞波及全球科技巨头与政府机构；Gartner预测至2025年，近半数企业将遭遇软件供应链攻击。
🚫 内容安全风险	开发者植入政治性内容或恶意代码，如无限循环输出主张、写入垃圾文件等。
⚠️ 质量与支持风险	地缘政治冲突可能导致开源项目维护中断或支持缺失。
©️ 知识产权风险	违反开源许可协议（如GPL、Apache）引发版权、专利或商标纠纷。

5.1.2 应对策略（增量风险）

当前软件供应链攻击呈现多样化、隐蔽化趋势，防护需结合纵深防御与持续治理。
软件供应链产品可大致分为六部分，主要分析：
1)日常办公使用的各类工具、软件。
2)各类三方组件：开源组件（如Fastjson、Log4j），外购SDK等。
3)各类三方软件：开源软件（如Jenkins），外购软件。

5.1.2.1 攻防对比

1.日常办公工具与软件

风险类型	具体案例	防护措施	防护措施的局限性
0Day/NDay漏洞	2022年向日葵远控软件远程代码执行漏洞，攻击者可获取服务器控制权。	1. 网络隔离：限制或禁止办公设备连接互联网。 2. 终端防护：部署杀毒软件、EDR等产品进行行为监控和病毒查杀。	1. 网络隔离效果取决于策略严格性，恶意流量可能通过TCP、UDP、ICMP、伪装HTTP等多种方式绕过限制。 2. 终端防护软件对窃取敏感信息等高级威胁防护能力有限。
应用商城插件恶意植入	2017年Chrome插件“User-Agent Switcher”内藏恶意代码，窃取用户标签页信息并插入广告。	1. 网络隔离 2. 终端防护 3. 软件来源管控：制定策略禁止安装来自非官方或不可信来源的插件/软件。	同上。需要联合使用多种措施才能达到较好效果。
发布/更新渠道污染	2015年XcodeGhost事件，开发者使用被植入病毒的开发工具，导致上亿用户受影响。	1. 网络隔离 2. 终端防护 3. 建立可信下载源：为企业内部提供官方软件、开发工具的可靠镜像或下载渠道。	同上。并且对已通过审批的可信软件内部的漏洞无效。

2. 三方组件

风险维度	风险描述与案例	防护措施	防护现状与挑战
0Day/NDay漏洞	描述：组件自身存在的安全漏洞，数量多、影响广。典型案例：Fastjson、Log4j2 反序列化漏洞，利用简单，危害巨大。	1. 流量层：部署WAF、IDS检测异常流量。 2. 应用层：使用RASP进行应用内实时防护。 3. 主机层：通过HIDS监控主机行为。 4. 依赖情报：依靠政府、安全厂商、社区发布的高质量漏洞预警。	防御纵深刻画图：防护手段相对成熟，形成了多层次、纵深的防御体系，且外部情报支持及时有效。
恶意投毒攻击	描述：攻击者向公共仓库发布恶意包，通过仿冒包名（如 `requests` vs `request`）、抢注内部包名等方式诱导安装。攻击原理：利用Python、Node.js等在安装时可执行代码的特性植入木马（挖矿、窃密等）。典型案例：2022年攻击者针对Ably公司发布数十个恶意Node.js包。	1. 办公环境：可借助杀毒软件、EDR、联网限制进行有限防护。 2. 生产/测试环境：几乎缺乏有效运行时防护手段（WAF/RASP无效）。 3. 源头治理：搭建私有镜像源并强制使用，是最有效的预防手段。	情报时效性对比：防护手段极度匮乏，尤其在生产环境。外部情报质量差、时效慢： • 官方源（NPM/PyPI）：处理慢（数天至一周），有遗漏。 • 国内镜像源：仅同步，无专人处理，时效更慢。 • 安全团队报告：偶发性，缺乏持续监控。

3. 三方软件

风险维度	风险描述与案例	防护措施	防护挑战与盲区
软件自身漏洞	描述：第三方软件本身存在的安全漏洞。典型案例：GitLab、Jenkins、WebLogic 等基础软件是高频漏洞目标，易被攻陷。	1. 网络层：防火墙隔离、IDS/IPS。 2. 主机层：HIDS、定期漏洞扫描与补丁管理。 3. 监控：订阅安全公告，建立漏洞应急响应流程。	1. 技术栈兼容性：软件技术栈多样（如C/C++, Go），RASP等应用层防护手段难以覆盖。 2. 资产可见性：部署运维方式不统一，安全团队难以全面感知和纳管资产，形成防护盲区。
发布/更新渠道污染	描述：软件的分发、更新流程被攻击者渗透，植入后门。典型案例：2020年SolarWinds事件，攻击者污染其CI/CD管道，通过官方更新分发恶意软件，波及大量政府与企业客户。	1. 渠道可信：从官方或绝对可信的源获取软件及更新。 2. 完整性校验：对下载的软件包进行哈希校验。 3. 安全审计：在隔离环境中对重要更新进行安全测试后再部署。	1. 供应链透明度低：企业难以对供应商的内部开发和安全流程进行审计。 2. 检测难度大：此类攻击具有高度隐蔽性和信任背书，传统防御手段难以发现。

5.1.2.2 治理方案

以构建“事前预防-事中检测-事后响应”的全链路治理体系为目标，其核心治理框架如下所示：

1. 收敛渠道：统一入口，缩小攻击面

📌 目标：杜绝从不可控的第三方渠道下载软件，从根本上减少风险引入。

现状与风险	治理措施
🔍 搜索引擎、公共镜像源提供大量不可控下载地址，风险极高。	✅ 网络隔离：禁止办公、测试、生产环境直接访问外部网络。
⚠️ 员工随意下载，极易引入被篡改或投毒的软件包。	✅ 自建仓库：搭建企业内部统一的 Maven、NPM、PyPI、软件商城。
🚫 风险敞口大，难以进行有效管理和监控。	✅ 强制代理：引导并强制所有开发、部署流程仅从内部仓库获取依赖。

💡 价值：这是所有治理措施的基础，为后续的准入、扫描和监控提供了统一的管控入口。

2. 严格准入：建立安全审批与检测流程

📌 目标：确保进入企业内部的每一个软件组件都经过安全和合规性评估。

产品类型	准入核心措施	检测与扫描重点
🖥️ 三方软件（外部采购/开源）	🔒 引入评估机制：嵌入采购与资源申请流程的安全审批节点。	✅ 安全测试：进行完整细致的安全测试。 ✅ 来源可信：必须从官方渠道下载，校验哈希值。 ✅ 恶意代码扫描：使用VirusTotal等平台进行检测。
📦 三方组件（开源依赖包）	🔒 仓库准入制：所有新增包必须通过安全扫描才能入库。	✅ 漏洞扫描：集成SCA工具（如OpenSCA、BlackDuck），比对CVE/CNVD数据库。 ✅ 投毒检测：自建检测能力，扫描恶意代码（静态+动态）。

三方软件准入机制：阻断凑对互联网上官网库的访问，只允许从内部库下载安装。

软件供应链投毒检测过程：

软件供应链投毒检测机制对比表

检测机制	核心原理	优势	劣势/挑战	主要应对的攻击类型
静态扫描	不运行代码，直接分析软件包源代码或字节码。分为： 1. 正则特征匹配：匹配已知恶意字符串、域名等。 2. 语义分析：通过污点分析等技术追踪恶意代码调用链路。	✅ 速度快，耗时短，适合大规模初筛。 ✅ 能够清晰展示恶意代码的调用链路，便于分析。 ✅ 对特征明显的攻击检测准确率高。	❌ 容易被绕过（如通过代码混淆、加密）。 ❌ 语义分析技术复杂度较高。	特征较明显的投毒攻击，如使用硬编码恶意域名、敏感系统命令等。
动态扫描（沙箱）	在隔离的沙箱环境中实际安装和运行软件包，监控其运行时行为（网络、文件、进程）。	✅ 检测能力强，能发现隐蔽性高的攻击（如代码混淆、二进制后门）。 ✅ 基于行为判断，不依赖特征码，更难被规避。	❌ 耗时较长，分析效率较低。 ❌ 沙箱环境可能缺乏特定依赖，导致恶意代码无法触发（漏报）。 ❌ 可能存在误报（正常操作也可能触发类似行为）。	代码混淆、加密、二进制文件、仅在特定条件下触发的深层后门等。
风险分决策	不直接分析代码，而是基于软件包的元数据（历史版本、文件大小、下载量、Star数等）设定权重进行综合风险评估评分。	✅ 能从另一个维度发现异常，不受代码隐蔽技术的影响。 ✅ 极大减少误报和漏报，与动静扫描结合形成合力，提升整体准确率。 ✅ 实现自动化决策，效率高。	❌ 无法单独作为判定依据，需与其他技术结合使用。 ❌ 需要持续运营和调整权重模型以保持准确性。	所有类型的投毒攻击（作为辅助判断依据），尤其擅长识别那些新发布、低人气、结构简单的恶意包。

核心结论：

⚡ 监管要求：遵循《关于规范金融业开源技术应用与发展的意见》，建立引入、评估、应急、退出的全生命周期管理制度。

3. 主动发现：构建“静态+动态”检测体系

软件供应链后门投毒的主动发现与漏洞发现的思路类似，投毒检测也可分为静态扫描和动态扫描两部分，但实现方式有所区别。

🔍 静态扫描
- 方法一：正则特征匹配：匹配已知恶意特征（如ceye.io、/dev/tcp），速度快，但易被绕过。
- 方法二：语义分析：解析程序语义，通过污点分析（仅需指定污点汇聚点Sink）检测恶意代码调用链路，精准度更高。不需要指定污点源(source)。
🛡️ 动态扫描（沙箱分析）
- 环境：在隔离的独立VPC中构建沙箱集群，通过容器技术进行环境隔离。
- 原理：模拟受害者安装和使用软件包，监控其网络、进程、文件等行为。
- 监听能力：
  - 主机层监听：Hook系统内核函数，监控系统调用，捕获底层行为。
  - 应用层监听：注入Hook点，捕获网络请求详情、域名、函数调用栈，精确定位恶意文件，并可进行函数Fuzz测试。

🖥️ 主机层事件监听：就像小区的“大门保安”和“道路监控”

他是怎么工作的？
这个保安非常敬业，他守在小区唯一的出入口（系统内核）。每一辆进出的车（网络流量）、每一个进出的人（进程调用），他都会拿起小本本记录下基本消息：比如“一辆黑色轿车（外连IP）在下午3点出去了”、“一个穿红衣服的人（进程名）进入了3号楼”。

他的优点是什么？

全面：因为所有人车都必须走大门，所以他几乎不会漏掉任何行为。

稳定：他不关心车里具体是谁、要去干嘛，他只管记录进出这个动作，所以不管小区里住的是谁（什么编程语言开发的应用），他都用同一套方法监控。

他的缺点是什么？

缺乏细节：他只知道“一辆黑色轿车出去了”，但不知道车里坐的是谁、他们具体要去哪里（无法解析域名和请求的详细内容）、他们要去谈什么生意（无法解析加密的数据包）。

难以追查源头：如果保安在记录上发现“有人扔了一堆垃圾”，他很难倒查回去具体是哪一户人家扔的（难以定位到是哪个具体的代码文件发起的恶意行为），尤其这个垃圾还是通过好几手传递出来的（间接依赖）。

📱 应用层事件监听：就像派了一个“贴身秘书”进到每户家里

他是怎么工作的？
为了解决保安的缺点，我们给每户人家（每个应用）都派了一位贴身秘书（应用层安全切面）。这个秘书就在家里看着，记录更详细的情况。

他的优点是什么？

细节丰富：他不仅能记录“一个人出去了”，还能记录“张三拿着一个牛皮纸袋，开车去了www.evil.com的地址，袋子里装的是‘账号密码’”（捕获访问的域名、请求的URL、甚至提交的数据详情）。

精准定位：一旦发生问题，秘书能立刻报告：“是家里书桌上那个叫malicious.js的文件让张三这么做的！”（精确定位到触发恶意行为的源代码文件）。

主动试探：秘书甚至还能主动问：“如果我碰一下这个花瓶（Fuzz测试：用各种参数调用函数），你会有什么反应？”，从而发现那些隐藏极深、只有特定条件才会触发的恶意代码。

他为什么需要和保安配合？
秘书虽然厉害，但他只负责一户人家。如果有一户新搬进来的人家（一个新的技术栈或应用），我们还得专门为这户培训一个懂他家规矩的秘书（需要适配不同的语言环境）。而保安（主机层监听）不需要，他永远在门口守着所有人

4. 风险分决策：引入元数据评估，降低误报

📌 目标：解决仅靠纯技术扫描的误报和漏报问题，提升判断准确性。

仅靠代码扫描无法100%准确，因为：

误报：正常操作（如下载依赖、编译）也会触发类似恶意行为。
漏报：沙箱环境缺失依赖可能导致恶意代码无法触发。

不同于分析代码本身，该机制通过分析软件包的 “元数据画像”（Metadata Profiling）来评估其潜在风险。其原理是：恶意投毒包通常在某些外部特征上与正常、健康的软件包存在显著差异：

📦 包体特征：文件体积通常较小，包含的目录和文件数量较少。
🕰 历史与流行度：历史版本数量少，下载量低。
🌐 社区与维护度：
- 未填写代码库地址或官网。
- 代码库地址虚假或Star、Fork、Commit数量极少（表明项目无人维护、缺乏社区关注）。

风险分决策机制：

风险分决策机制通过为这些元数据设定不同权重进行综合评分：

高风险分：多项元数据指标均表现异常 → 极可能为投毒包
低风险分：元数据指标正常 → 即使有可疑行为，也可能是误报

将风险分与静态、动态扫描结果联动，能最大程度减少误报和漏报，实现精准判定。

5.1.3 理清台账（存量风险）

严格的准入控制了增量风险，而治理存量风险的第一步是彻底摸清家底，建立完整的软件供应链产品台账。这是一项复杂但至关重要的工作，需要针对不同对象采取不同策略。

治理对象	主要挑战	梳理方法与数据源
三方组件（开源依赖）	隐式依赖难以发现（被其他依赖间接引入，未在主配置文件中声明）。	1. 🛠️ 构建分析：在CI/CD流程中，通过Maven、NPM等构建工具直接获取完整的依赖树，这是最准确的方式。 2. 🖥️ 运行时采集：在主机或容器镜像中下发采集脚本，扫描`jar`、`so`等实际存在的组件文件，作为补充验证。
三方软件（开源/商业软件）	部署运维非标准化，常脱离企业标准CI/CD流程（如黑屏运维、使用自定义镜像），导致资产不可见。	1. 🤝 联合SRE：梳理非标资源（独立物理机、定制镜像容器），与采购合同、财务记录核对，建立清单。 2. 🔍 流量与资产探测： - 利用Web指纹识别技术扫描发现。 - 分析历史流量数据，在负载均衡和域名中识别匹配三方软件特征。
办公软件	终端设备分散，软件及插件来源多样，难以统一管理。	1. 📊借助EDR终端Agent：全面收集设备安装的软件列表及其下载来源（如MacOS Gatekeeper数据）。 2. 🔌插件管理：专项收集浏览器（Chrome）、IDE（IDEA）等常用软件的插件清单。

💡 核心价值：清晰的台账是应急响应和风险治理的基石。只有知道“有什么”、“在哪里”，才能在出现漏洞时快速定位影响范围并实施修复。

5.1.4 隔离防护：划定边界，遏制横向扩散

三方软件因技术栈各异，难以像自研应用一样统一部署RASP、WAF等高级防护手段，导致其安全水位往往较低。因此，必须采用 “网络隔离” 这一最有效且普适的防护策略。

核心思想： 基于“零信任”原则，默认不信任三方软件，将其与企业核心环境进行隔离。

🏗️ 建立隔离区：
划定独立的三方软件隔离区（通常是独立的VPC或网段），将企业内所有三方软件统一迁移至该区域。
🚧 实施严格访问控制：
- 在隔离区与生产/测试环境之间部署防火墙或安全组。
- 遵循最小权限原则，仅配置严格的白名单策略，放行必需的通信流量。
- 阻断所有非白名单的入向和出向访问。