Python如何通过GitHub API检查并恢复Dependabot告警

Python怎样检查并恢复仓库的Dependabot告警？可通过GitHub REST API读取vulnerability-alerts状态，在确认仓库和权限后，再按需要主动发送PUT启用。GET的204表示已启用，PUT成功也返回204且没有JSON正文；404不能在仓库标识或访问权限不明时直接当作“已关闭”。2026年12月8日的不活跃规则还涉及归档、计时与策略豁免，接口检查不能代替这些条件判断。

先准备正确的身份与仓库范围

示例需要Python、requests，以及已通过环境变量GITHUB_TOKEN提供的令牌。检查端点要求仓库管理员读取权限，细粒度令牌对应Administration read；启用则要求Administration write及实际仓库管理权限。令牌还必须覆盖目标仓库，组织和企业策略也可能限制管理员能否改变功能状态。

代码中的YOUR_OWNER和YOUR_REPO是占位符，应替换为真实仓库所有者和仓库名，仓库名不带.git后缀。示例只针对github.com单个仓库，不把查询结果扩展为整个组织或账号的状态。

第一步：只读检查，不自动恢复

以下代码仅发送GET，不更改仓库设置：

import os
import requests

owner = "YOUR_OWNER"
repo = "YOUR_REPO"
url = f"https://api.github.com/repos/{owner}/{repo}/vulnerability-alerts"
response = requests.get(
    url,
    headers={
        "Accept": "application/vnd.github+json",
        "Authorization": "Bearer " + os.environ["GITHUB_TOKEN"],
        "X-GitHub-Api-Version": "2026-03-10",
    },
    timeout=30,
)
if response.status_code == 204:
    print("Dependabot告警已启用")
elif response.status_code == 404:
    print("需核对仓库名、访问权限与未启用状态，未执行修改")
else:
    response.raise_for_status()
    raise RuntimeError(f"未预期的响应状态：{response.status_code}")

官方对该端点列出204为启用、404为未启用，但404也可能与资源不可见或标识不正确有关。脚本因此保留待核对状态，不把它接成自动恢复条件。401、403及其他错误会停止当前检查，不能据此虚报告警已经开启或已经关闭。

第二步：确定需要恢复时再启用

确认目标仓库、令牌权限与策略允许，且确实希望启用后，可单独运行下面完整示例。它会改变该仓库的告警与依赖图启用状态，不涉及个人邮件偏好：

import os
import requests

owner = "YOUR_OWNER"
repo = "YOUR_REPO"
url = f"https://api.github.com/repos/{owner}/{repo}/vulnerability-alerts"
response = requests.put(
    url,
    headers={
        "Accept": "application/vnd.github+json",
        "Authorization": "Bearer " + os.environ["GITHUB_TOKEN"],
        "X-GitHub-Api-Version": "2026-03-10",
    },
    timeout=30,
)
response.raise_for_status()
if response.status_code != 204:
    raise RuntimeError(f"未确认启用：{response.status_code}")
print("启用请求已成功，后续可用只读检查确认状态")

成功响应是204 No Content，因此不能继续调用response.json()并把空正文解析失败误认成启用失败。遇到策略或权限拒绝，应先处理其原因，不用重复写入或更换身份来绕过管理要求。

恢复后为什么要理解归档与一年计时

从2026年12月8日起，多数过去一年无活动的仓库将暂停Dependabot告警，旧告警归档而非删除。向任意分支或标签推送、创建仓库和启用告警，都属于公告定义的活动，不仅限于默认分支提交。

暂停后，任意推送会自动重新开启，仓库设置中的手动启用也能恢复；归档告警重新出现，一年计时重新开始。接口启用改变的是功能状态，恢复旧告警并不代表漏洞已修复，依赖升级和风险处置仍是另一项工作。

组织策略、批量入口和适用平台要分开看

强制安全配置明确启用Dependabot告警的仓库，不因缺少活动关闭；企业策略不允许仓库管理员自行启用或禁用时，也跳过自动暂停。“属于组织”本身不构成豁免，配置必须实际生效；Enforce configuration只强制明确设置的功能，未设项目不因此被统一控制，也无需为此随意开启其他付费功能。

网页支持单仓库设置，个人Advanced Security设置另有对现有仓库Enable all和新仓库默认启用范围；两份脚本并非这些批量入口的替代实现。告警功能与邮件通知也独立，可保留告警而改变通知、使用周摘要或关闭通知，不能靠邮件判断接口状态。

规则适用于github.com所有计划及带数据驻留的Enterprise Cloud，归档告警与企业其他数据保存在同一区域；不适用于GitHub Enterprise Server，不能将上述Cloud规则和端点地址直接当作自建Server管理方案。

接口已启用也不能证明依赖完全安全

Dependabot围绕默认分支依赖生成已知漏洞告警，依赖图变化或Advisory Database新增漏洞都可能触发告警。它能提供受影响文件、严重程度与修复版本，但只由GitHub审核公告触发，入库与生成可能有延迟，也无法捕获所有安全问题。长期不改代码仍可能受到新漏洞影响，功能恢复、告警处理与实际依赖安全应分别管理。