semgrep的severity都有哪些？哪个算是真的漏洞

在AI基础设施和模型部署的流程中，代码安全审计是不可或缺的一环。静态分析工具Semgrep因其强大的模式匹配能力和灵活的规则定义，成为保障MLOps代码安全的首选工具之一。然而，对于初次使用者来说，理解Semgrep输出结果中不同的

（严重性）级别，以及判断哪些级别真正代表了可被利用的漏洞，至关重要。

本文将深入探讨Semgrep的四个主要严重性级别，并提供实战指南，帮助您快速聚焦于真正的安全风险。

1. Semgrep Severity 级别详解

Semgrep允许规则设计者通过规则文件中的

字段指定规则的严重性。虽然Semgrep本身不强制定义这些级别，但在默认的规则包（如

或

）中，它们被广泛使用并具有明确的含义。这些级别从低到高分别是：

INFO (信息)

• 含义: 通常用于提供一般性的信息、代码风格建议、或者指出潜在的最佳实践优化点，通常不直接关联安全漏洞。
• 示例: 使用已弃用的库函数、冗余的代码块、或低效的日志记录模式。

WARNING (警告)

• 含义: 指出潜在的配置风险、边界情况处理不当，或者轻微违反安全规范的行为。它们可能不是直接的漏洞，但如果被忽略，可能导致未来的安全问题。
• 示例: 缺少必要的输入验证、配置文件中使用的默认权限过于宽松。

ERROR (错误)

• 含义: 高度自信地指出代码中存在的安全漏洞或关键的错误。这些通常是需要立即修复的问题，因为它可能导致应用程序崩溃或被攻击者利用。
• 示例: 硬编码的敏感凭证、未经处理的异常可能暴露堆栈信息。

CRITICAL (危急)

• 含义: 最高级别的严重性，代表了最直接、最易被利用、影响最大的安全漏洞。这些漏洞通常对应于高CVSS分数（如RCE, SQL Injection, XXE）。
• 示例: 在生产环境中使用

  1

  eval()

  处理不可信的用户输入、未经验证的反序列化操作。

2. 哪个级别算是真正的漏洞？

在实践中，您应该将ERROR和CRITICAL级别的发现视为真正的安全漏洞（True Vulnerabilities），需要立即投入资源进行修复。

• CRITICAL/ERROR: 对应于直接的、可利用的安全风险。在AI部署场景中，这可能意味着模型权重泄露、API Key硬编码、或导致部署Pod被远程代码执行（RCE）。
• WARNING: 对应于安全“气味”（Security Smells）或配置缺陷。虽然需要审查，但优先级低于ERROR/CRITICAL。对于合规性要求较高的系统，WARNING也应被纳入修复计划。

高效的安全审计流程应该首先过滤和修复所有CRITICAL/ERROR级别的结果。

3. 实战示例：在ML部署代码中定义和运行Severity规则

假设我们正在审计一个用于加载模型配置的Python文件。我们希望定义一个CRITICAL规则来阻止不安全的配置加载，并定义一个WARNING规则来提示不良实践。

步骤 1: 编写待审计的ML代码 (

1	deployment_script.py

)

这是一个简化的ML部署脚本，包含一个高风险操作和一个低风险操作。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# deployment_script.py

import json

import os



CONFIG_PATH = os.getenv("MODEL_CONFIG_FILE")



# CRITICAL 风险：使用 eval() 来加载配置，可能导致 RCE

def load_insecure_config(path):

    with open(path, 'r') as f:

        config_data = f.read()

    # 攻击者可以构造恶意 JSON 并注入 Python 代码

    return eval(config_data)



# WARNING 风险：使用不安全的 hardcoded Secret

def check_api_key():

    # 这是一个不应该出现在代码库中的 hardcoded secret

    if os.getenv("ENV") == "PROD":

        api_key = "SK-A1B2C3D4E5F6G7H8I9J0"

        print("API Key loaded")



if __name__ == "__main__":

    # 加载模型配置

    model_settings = load_insecure_config(CONFIG_PATH)

    check_api_key()

步骤 2: 定义 Semgrep 规则 (

1	security_checks.yaml

)

我们将为上述两个问题定义不同严重性的规则。

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
# security_checks.yaml

rules:



# 规则 1: 发现不安全的 eval 调用 (CRITICAL)

- id: critical-unsafe-eval-in-deployment

  message: "CRITICAL VULNERABILITY: Use of eval() to process file content can lead to Remote Code Execution (RCE). Use json.loads or yaml.safe_load instead."

  severity: CRITICAL

  languages: [python]

  patterns:

    - pattern: eval($X)

    - pattern-inside: | 

        def $FUNC(...):

          ...

          $Y = $FILE.read()

          ...

          return eval($Y)



# 规则 2: 发现硬编码的 Secret (ERROR)

- id: error-hardcoded-api-key

  message: "ERROR VULNERABILITY: Hardcoded API Key detected. Secrets must be loaded securely via environment variables or secret management services."

  severity: ERROR

  languages: [python]

  patterns:

    - pattern: $KEY = "SK-$SECRET"



# 规则 3: 发现无用的 os.getenv 检查 (INFO)

- id: info-redundant-os-check

  message: "INFO: Consider simplifying redundant environment checks."

  severity: INFO

  languages: [python]

  patterns:

    - pattern: os.getenv($VAR) == "PROD"

步骤 3: 运行 Semgrep

使用

输出并过滤结果，通常在CI/CD管道中会使用这个命令来只关注高严重性的问题。

1
semgrep --config security_checks.yaml deployment_script.py

输出结果分析 (精简版):

通过这种方式，您可以在自动化流程中设置门槛，例如：如果Semgrep发现任何

或

，则阻止代码合并或部署。