baseline-security-audit

基线安全审计技能

概述

此技能通过分析常见的安全漏洞和错误配置，对代码库执行全面的基线安全审计。经用户确认后，它可以为选定的发现创建 Jira 故事，以便跟踪和修复。

此技能的功能

此技能会执行以下安全检查（每项检查均在 references 文件夹中提供详细指南）：

1. 机密和凭据 - 扫描硬编码的机密、凭据和 API 密钥，并验证不同环境使用的凭据是否不同

   • 请参阅 references/secrets.md

2. 软件包安全 - 检查是否存在包含已知漏洞的依赖项、已终止支持的运行时以及供应链控制措施

   • 请参阅 references/packages.md

3. SQL 注入 - 识别数据库查询中的 SQL 注入漏洞

   • 请参阅 references/sql_injection.md

4. 异常处理 - 检查错误处理，确保响应中不包含异常详情，同时记录这些详情

   • 请参阅 references/exception_handling.md

5. 日志安全 - 验证日志接收端、级别、审计隔离，以及日志中是否不存在机密和个人身份信息（PII）

   • 请参阅 references/logging.md

6. 敏感查询字符串 - 检查 URL 查询参数和 URL 日志中是否包含敏感数据

   • 请参阅 references/sensitive_query_strings.md

7. IDOR（不安全的直接对象引用） - 分析对象级和功能级授权检查

   • 请参阅 references/idor.md

8. 输出编码 - 验证编码和清理措施，以防止 XSS

   • 请参阅 references/output_encoding.md

9. 输入验证 - 确保在服务端验证用户输入，包括批量赋值和路径遍历

   • 请参阅 references/input_validation.md

10. 代码压缩 - 验证生产构建不会暴露源映射文件或调试代码

    • 请参阅 references/code_minification.md

11. 数据最小化 - 识别通过 API 和前端不必要地暴露数据，以及不必要地存储敏感数据的情况（GDPR）

    • 请参阅 references/data_minimization.md

12. Cookie 和存储安全 - 验证 Cookie 标志以及浏览器对敏感数据的存储

    • 请参阅 references/cookie_storage_security.md

13. 密码学安全 - 确保使用强算法、妥善管理密钥并安全地哈希密码

    • 请参阅 references/cryptography_security.md

14. 安全标头 - 检查响应安全标头（CSP、HSTS、Permissions-Policy 等）以及是否移除了会泄露版本信息的标头

    • 请参阅 references/security_headers.md

15. HTTP 方法白名单 - 确保仅允许应用程序使用的 HTTP 方法

    • 请参阅 references/http_verb_whitelisting.md

16. SSL/TLS 配置 - 验证 TLS 协议、密码套件、证书和代码级 TLS 设置

    • 请参阅 references/ssl_tls_configuration.md

17. 数据库字段加密 - 验证敏感列是否在列级或应用程序级进行加密

    • 请参阅 references/database_field_encryption.md

18. 代码质量 - 检查构建警告、安全分析器和 SonarQube 安全评级

    • 请参阅 references/code_quality.md

19. 身份验证安全 - 验证是否使用 OpenID Connect 和 Authorization Code + PKCE、是否默认启用授权、Swagger 是否仅限 Development 使用，以及令牌有效期和密码策略

    • 请参阅 references/authentication_security.md

每项检查均提供：

• 要搜索的具体模式
• 需要识别的 RED FLAGS
• 按照下方唯一严重性等级评定的发现
• 修复指南
• 代码示例

严重性等级

每个参考文件都使用这一套等级评定发现的问题。应按影响和可利用性评定，绝不能按输入由谁提供或影响哪个环境来评定：管理员提供的输入不会让问题的严重性低于中危；任何跨租户或跨用户影响至少为高危。

严重性	定义	典型示例
严重	目前可被利用，攻击者只需未认证或低权限输入，且影响严重	源代码、配置或日志中包含机密或凭据；可通过用户输入触发的注入；认证绕过；CVSS 9.0+；以明文存储 CVV 或 PAN；保护机密的加密机制存在缺陷或为自行实现
高危	可通过已认证输入利用，或暴露敏感数据，或缺失核心控制措施	端点缺少授权检查；HTTP 响应中包含堆栈跟踪或异常详情；启用了 TLS 1.0/1.1；缺少 HSTS；将未经认证的 CBC 数据交给客户端；CVSS 7.0–8.9；将个人身份信息或特殊类别数据作为负载记录到日志中；运行时已过生命周期终止日期
中危	纵深防御存在缺口，或存在需要结合另一项弱点才能利用的错误配置	缺少安全标头；未启用安全分析器；SonarQube 安全问题未经审查；CVSS 4.0–6.9；生产环境中日志记录过于详细；没有自动续订证书
低危	属于卫生或信息性问题；本身不存在现实可行的利用路径	未明确设置 SameSite；未启用 HSTS preload；在不同环境间共享公开标识符；后量子就绪情况；文档缺失；CVSS 低于 4.0

SECURE / PARTIALLY SECURE / INSECURE、IMPLEMENTED / PARTIAL / NOT 或 EXCESSIVE / MODERATE / MINIMAL 等状态词不是严重性等级；参考文件使用这些词进行评估时，每项报告的问题仍须标注上述四种严重性之一。

**每项发现都应报告：**严重性 · 检查编号和名称 · 位置（文件:行号、标头或实时 URL）· 发现的问题 · 修复措施 · OWASP Top 10:2025 类别（参见下方映射）。

标准映射

为每项发现标注其检查所属的 OWASP Top 10:2025 类别和 ASVS 5.0 章节。

#	检查项	OWASP Top 10:2025	ASVS 5.0
1	密钥和凭据	A02 安全配置错误	V13 配置
2	软件包安全	A03 软件供应链失效	V15 安全编码与架构
3	SQL 注入	A05 注入	V1 编码与清理
4	异常处理	A10 异常情况处理不当	V16 安全日志记录与错误处理
5	日志安全	A09 安全日志记录与告警失效	V16 安全日志记录与错误处理，V14 数据保护
6	敏感查询字符串	A04 加密失效（数据泄露）	V14 数据保护
7	IDOR（不安全的直接对象引用）	A01 访问控制失效	V8 授权
8	输出编码	A05 注入	V1 编码与清理，V3 Web 前端安全
9	输入验证	A05 注入，A06 不安全设计	V2 验证与业务逻辑
10	代码压缩	A02 安全配置错误	V13 配置，V3 Web 前端安全
11	数据最小化	A04 加密失效，A06 不安全设计	V14 数据保护
12	Cookie 和存储安全	A02 安全配置错误，A07 身份验证失效	V7 会话管理，V3 Web 前端安全
13	密码学安全	A04 加密失效	V11 密码学
14	安全标头	A02 安全配置错误	V3 Web 前端安全，V13 配置
15	HTTP 方法白名单	A02 安全配置错误	V4 API 和 Web 服务，V13 配置
16	SSL/TLS 配置	A04 加密失效，A02 安全配置错误	V12 安全通信
17	数据库字段加密	A04 加密失效	V14 数据保护，V11 密码学
18	代码质量	A03 软件供应链失效，A06 不安全设计	V15 安全编码与架构
19	身份验证安全	A07 身份验证失效，A01 访问控制失效	V6 身份验证，V8 授权，V10 OAuth 和 OIDC

来源：https://owasp.org/Top10/2025/ ，https://github.com/OWASP/ASVS/tree/v5.0.0

使用方法

通过请求安全审计来调用此技能：

• “执行基线安全审计”
• “检查代码库中的安全问题”
• “对这个项目运行安全检查”

执行流程

步骤 0 — 选择要运行的检查（在最开始时询问一次）

在执行任何其他操作之前，请列出所有可用检查，并询问用户要运行哪些检查：

“您想运行哪些安全检查？

#	检查
1	密钥和凭据
2	软件包安全
3	SQL 注入
4	异常处理
5	日志安全
6	敏感查询字符串
7	IDOR（不安全的直接对象引用）
8	输出编码
9	输入验证
10	代码压缩
11	数据最小化
12	Cookie 和存储安全
13	加密安全
14	安全标头
15	HTTP 方法白名单
16	SSL/TLS 配置
17	数据库字段加密
18	代码质量
19	身份验证安全

回复 all 以运行所有检查，或提供以逗号分隔的编号列表（例如 1, 3, 5）以运行指定的检查子集。”

将所选检查编号保存为 SELECTED_CHECKS。只运行和报告所选检查，并仅为所选检查创建 Jira 事项。 审计期间不要再次询问。

如果 SELECTED_CHECKS 包含 14（安全标头） 或 16（SSL/TLS 配置），或者用户选择了 all，则在选择检查后立即询问用户生产环境 URL：

“检查 14 和／或 16 需要一个可访问的实时 URL。生产环境 URL 是什么？（留空则跳过实时检查，并改用静态分析）”

将答案保存为 PRODUCTION_URL。如果用户留空，则将 PRODUCTION_URL 设为空，并对这两项检查进行静态分析。 审计期间不要再次询问此 URL。

步骤 0b — 确定托管模式（运行检查前执行一次）

检查 10、12、14、15 和 16 取决于应用的运行位置，因为 web.config 仅在 Windows 上的 IIS 和 Azure App Service 中生效。运行这些检查前，根据仓库中的证据确定 HOSTING_MODEL；仅当证据相互矛盾或缺失时，才询问用户一次。

HOSTING_MODEL	证据	对检查的影响
iis	包含 <aspNetCore> 或 <system.webServer> 的 web.config、不含 linuxFxVersion 的 Bicep Microsoft.Web/sites、部署到 IIS 或 Windows App Service 的管道	web.config 中的配置节（customHeaders、requestFiltering、removeServerHeader、httpErrors）适用
linux	Dockerfile、Bicep linuxFxVersion、kind: 'app,linux'、AKS 或 Container Apps 清单、直接公开的 Kestrel	web.config 会被忽略；对应配置应使用中间件（UseHsts、安全标头中间件、方法过滤）以及容器或平台设置。不要报告缺少 web.config 配置项
edge（修饰项，与任一模式组合）	Bicep Microsoft.Cdn/profiles（Front Door）、Microsoft.Network/applicationGateways，或位于应用前方的反向代理	标头、TLS 策略和方法过滤可能在边缘层设置或剥离；如果有 PRODUCTION_URL，则以实时响应为准，并且必须配置 UseForwardedHeaders

将结果保存为 HOSTING_MODEL，之后不要再次询问。

Jira 集成

步骤 1 — 收集 Jira 项目代码（在最开始时询问一次）

确认所选检查后，仅向用户询问一次：

“应在哪个 Jira 项目中创建安全事项？请提供项目代码。（例如 SEC、PROJ）”

将答案保存为 JIRA_PROJECT_CODE，并在后续所有事项创建调用中使用。 审计期间不要再次询问。

步骤 2 — Jira 优先级映射

所有发现都已标记为严重性级别部分中的四种严重性之一。按如下方式将其映射到 Jira 优先级（请对照目标 Jira 项目的方案核实优先级名称；某些方案使用 Medium 而不是 Normal）：

严重性	Jira 优先级
Critical	Highest
High	High
Medium	Normal
Low	Low

步骤 3 — 展示所有发现，并询问要将哪些发送到 Jira

所有选定的检查完成后，输出一张包含所有发现的编号汇总表。每项检查都涵盖不同主题，因此每项配置只会在一项检查中报告；如果同一文件和行号出现两次，则将该发现保留在主题对应的检查下，并删除另一项：

#	检查	发现	位置	严重性	OWASP 2025
1	1 密钥和凭据	硬编码的 API 密钥	src/Api/appsettings.json:14	Critical	A02
2	...	...	...	...	...

然后只询问用户一次：

“要将哪些发现创建为 Jira 故事？ 回复 all 以为所有发现创建故事；回复以逗号分隔的编号列表（例如 1, 3, 5）；或者回复 none 跳过创建 Jira 故事。”

收到回答前，不要创建任何 Jira 故事。

第 4 步 — 为每个选定的发现创建 Jira 故事

软件包安全 — 特殊合并规则： 不要为每个软件包各创建一个故事，而是将所有 npm 发现合并为一个故事，将所有 NuGet 发现合并为一个故事（此项检查最多创建 2 个故事）。在合并后故事的描述中列出每个受影响的软件包、当前版本、建议版本、CVE 和风险级别。合并后故事的优先级采用各单项发现中的最高优先级。如果某个软件包生态系统没有发现，则完全省略其故事。

创建第一个故事前，调用一次 getAccessibleAtlassianResources，并将返回的 cloud id 保存为 CLOUD_ID；下面的每次 Jira 调用都需要它。

对于用户选定的每项发现，使用 createJiraIssue 工具创建一个 Jira 故事，并填写以下字段：

字段	值
cloudId	CLOUD_ID
projectKey	JIRA_PROJECT_CODE（前面收集的值）
issueTypeName	Story
summary	[Security Audit] <Check Name>: <short finding title>
description	发现位置（文件 + 行号）、问题描述、修复步骤，以及 OWASP Top 10:2025: <category> 这一行（Markdown）
additional_fields	{"labels": ["BaselineSecurity"], "priority": {"name": "<mapped priority>"}} — 标签和优先级只能通过此对象传入

摘要示例： [Security Audit] Secrets Management: Hardcoded API key in appsettings.json

每次 createJiraIssue 调用成功后：

1. 在审计输出中内联显示创建的故事键，例如：(→ 已创建 PROJ-42)
2. 调用 createIssueLink，将新故事关联到此项目的 ETL 项目故事：
   • cloudId：CLOUD_ID
   • type："Relates"
   • inwardIssue：新创建的故事键（例如 YES-42）
   • outwardIssue：ETL 项目故事键（例如 ETL-2879）

在创建第一个关联前，使用 searchJiraIssuesUsingJql 查找一次 ETL 故事（cloudId = CLOUD_ID），例如 project = ETL AND summary ~ "<current project name>" AND summary ~ "Baseline security"。如果匹配到多个问题或没有匹配项，请显示候选项并向用户询问故事键。将其保存为 ETL_STORY_KEY，之后不要再次搜索。

⚠️ 不要将 customfield_10014（Epic Link）用于此目的 — 此字段只接受 Epic。 ETL 故事是一个 Story，不是 Epic。请改用 createIssueLink。

第 5 步 — 最终汇总表

创建完所有选定的故事后，输出一张汇总表：

故事键	检查项	摘要	优先级
PROJ-42	Secrets Management	Hardcoded API key in appsettings.json	High
...	...	...	...

如果用户回复了 none，则跳过故事创建，并省略此表。