在安全运营工作中，我们常常面临一个棘手的问题：多个安全扫描工具产生的数据格式五花八门，难以统一管理。本文将介绍我们如何利用 OCSF（Open Cybersecurity Schema Framework） 来解决这一痛点，并详细解析 OCSF 的架构设计。

背景：多工具时代的数据碎片化

在我们的代码安全审计体系中，为了最大化漏洞检测能力与覆盖广度，同时引入了多种自研与商采的 静态应用安全测试（SAST） 工具。

这种「多工具」策略虽然增强了技术上的检出能力，但也直接导致了一个核心挑战：扫描结果数据的严重碎片化。

核心痛点

痛点 影响
高昂的整合成本 每引入新工具都需编写专用解析脚本，耗时且易出错
低效的漏洞研判 跨工具告警关联与去重难以自动化
缺失的统一度量 难以横向对比工具效能、追踪 MTTR 等关键指标

什么是 OCSF

OCSF（Open Cybersecurity Schema Framework，开放网络安全架构框架） 是由 AWS、Splunk、IBM 等多家科技巨头于 2022 年 8 月联合发起的开源项目，旨在为各类安全事件提供 通用的、可扩展的数据模型。

2022-08 OCSF 发布

AWS、Splunk、IBM 等联合发布 OCSF v1.0

2024-11 加入 Linux 基金会

OCSF 正式被纳入 Linux 基金会，成为业界广泛共识

核心设计原则

原则 说明
标准化 定义统一字段和格式，实现跨来源数据整合
开放性 开源托管于 GitHub，人人可访问和贡献
兼容性 适用于任何环境，同时符合现有安全标准
可扩展性 支持自定义扩展，满足特定业务场景
版本控制 完善的版本控制标准，支持架构持续演进

OCSF 架构详解

OCSF 采用分层架构设计，通过 Category → Class → Object 的层级关系组织所有安全事件。

Categories（类别）

OCSF 将所有安全事件划分为多个顶层类别：

类别 ID 名称 说明
1 System Activity 系统活动事件
2 Findings 发现类事件（漏洞、威胁检测）
3 Identity & Access Management 身份与访问管理
4 Network Activity 网络活动事件
5 Discovery 资产发现事件
6 Application Activity 应用程序活动

Classes（事件类）

每个类别下包含多个具体事件类。以 Findings（类别 2） 为例：

类 ID 名称 说明
2001 Security Finding 通用安全发现
2002 Vulnerability Finding 重点 漏洞发现
2003 Compliance Finding 合规性发现
2004 Detection Finding 威胁检测发现

SAST 扫描结果对应的正是 Vulnerability Finding (class_uid: 2002) 事件类。

Objects（对象）

Objects 是 OCSF 中可复用的数据结构：

  • Vulnerability — CVE、CVSS 评分等漏洞信息
  • File — 路径、哈希值等文件信息
  • Device — 设备信息
  • User — 用户信息
  • Product — 产品/工具信息

Vulnerability Finding 事件结构

对于 SAST 扫描结果，主要使用 Vulnerability Finding (class_uid: 2002)：

点击查看完整字段结构
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
{
  "class_uid": 2002,
  "class_name": "Vulnerability Finding",
  "category_uid": 2,
  "category_name": "Findings",
  "activity_id": 1,
  "activity_name": "Create",
  "severity_id": 3,
  "severity": "Medium",
  "status_id": 1,
  "status": "New",
  "time": 1703232000000,
  "message": "SQL Injection vulnerability detected",

  "finding_info": {
    "uid": "finding-uuid-12345",
    "title": "SQL Injection in UserController",
    "desc": "Unsanitized user input is directly concatenated into SQL query",
    "created_time": 1703232000000,
    "first_seen_time": 1703232000000,
    "last_seen_time": 1703232000000,
    "types": ["Static Analysis"]
  },

  "vulnerabilities": [
    {
      "uid": "vuln-uuid-67890",
      "title": "SQL Injection",
      "desc": "CWE-89: Improper Neutralization of Special Elements used in an SQL Command",
      "cwe": {
        "uid": "CWE-89",
        "caption": "SQL Injection"
      },
      "severity": "High",
      "references": ["https://cwe.mitre.org/data/definitions/89.html"]
    }
  ],

  "resources": [
    {
      "type": "File",
      "name": "UserController.java",
      "uid": "/src/main/java/com/example/UserController.java"
    }
  ],

  "metadata": {
    "version": "1.2.0",
    "product": {
      "name": "Internal SAST Scanner",
      "vendor_name": "Security Team",
      "version": "2.1.0"
    },
    "logged_time": 1703232000000
  }
}

关键字段速查

字段 类型 说明
class_uid Integer 事件类 ID，Vulnerability Finding 为 2002
severity_id Integer 严重程度（1-6：Unknown → Fatal）
finding_info Object 发现的详细信息
vulnerabilities Array 关联的漏洞列表（含 CWE、CVE）
resources Array 受影响的资源（文件、代码位置）
metadata Object 元数据（产品信息、版本等）

我们的解决方案

项目目标

借助 OCSF 标准，将各类 SAST 工具的扫描结果进行 统一化和结构化 处理。

预期收益

目标：将不同 SAST 工具（如 Pharaoh、Xcheck、HardCode 等）输出的异构告警转换为统一的 OCSF 格式

价值 消除为每种工具编写专用解析脚本的需求，降低接入成本

目标：为每条漏洞结果系统性地附加关键上下文（代码仓库、项目负责人、应用业务等级、代码修改者等）

价值 帮助安全工程师快速判断漏洞的真实业务影响，区分高风险与误报

目标：通过统一数据格式建立稳定可靠的漏洞度量体系

价值 支持跨工具统计分析和 MTTR 追踪

总结

通过将 SAST 扫描结果转换为 OCSF 格式，我们能够：

  1. 打破数据孤岛 — 统一不同工具的输出格式
  2. 提升运营效率 — 简化数据整合和分析流程
  3. 增强可观测性 — 建立统一的漏洞度量体系
  4. 面向未来 — 为后续的自动化运营奠定基础

随着 OCSF 被纳入 Linux 基金会，它正成为安全数据标准化的事实标准。尽早采用，将为安全运营带来长远收益。

参考资料