silviooerudon/triagerook

# TriageRook      扫描你的 GitHub 仓库，涵盖十一大类检测器，并在无依赖关系时并行运行 —— **60 多种密钥模式**、敏感文件、**28 条基于 AST 的 SAST 规则**，覆盖 **npm、PyPI、Go、RubyGems、Maven/Gradle 和 Composer** 的依赖项（外加从 Trivy SARIF 报告中摄取的**容器镜像 OS 软件包 CVE**）、供应链配置错误、针对 **Dockerfile、GitHub Actions、Terraform、Kubernetes、CloudFormation 和 Helm** 的 IaC 检查，代码中的云 IAM 风险（AWS / GCP / Azure / GitHub scope），以及 git 历史重放 —— 无需 CLI，无需配置，也无需搭建任何 pipeline。使用 GitHub 登录或粘贴一个公开 URL，然后在一分钟内获得按优先级排序的检测结果列表。每个检测结果只需点击一下即可导出为 **SARIF 2.1.0** 格式，随时可上传至 GitHub Code Scanning。 📖 完整的规则目录（170+ 条规则，涵盖所有 CWE）发布在 [`/docs/rules`](https://www.triagerook.com/docs/rules)。SARIF 集成指南位于 [`/docs/sarif`](https://www.triagerook.com/docs/sarif)。 ## 为什么开发这个工具 我在身份与访问管理领域工作了 10 多年 —— 这个领域的存在正是因为凭据泄露和人们被黑客攻击。像 Snyk 和 GitGuardian 这样的工具很棒，但它们的价格是为有安全预算的团队准备的。独立开发者和微型初创公司完全跳过安全扫描，因为入门门槛太高了。 TriageRook 是我对最小实用安全工具的尝试：一键扫描仓库，看看有什么问题，然后修复它。公开构建。 ## TriageRook 实际检测的内容 TriageRook 会对你的仓库运行十一个独立的检测器，并将结果聚合到一个按优先级排序的报告中。 ### 1. 源代码中的密钥（60+ 种模式） 针对跨云提供商、SCM 平台、AI API、支付、通信、监控和开发者工具的现代 token 格式进行高置信度正则表达式检测 —— AWS/Azure/GCP/DigitalOcean/Cloudflare/Vercel/Netlify/Fly/Render；GitHub（classic、fine-grained、OAuth、App token）、GitLab、Bitbucket；Anthropic、OpenAI（当前 + 旧版）、Hugging Face、Replicate、Groq、Perplexity；Stripe、Braintree、Square、Shopify、Adyen；Slack、Discord、Telegram、SendGrid、Mailgun、Twilio；Datadog、New Relic、Sentry、PagerDuty、Algolia；npm/PyPI/Docker Hub/JFrog token；HashiCorp Vault、Terraform Cloud；以及诸如 `-----BEGIN PRIVATE KEY-----`、`.npmrc` 中的 `_authToken=`、HTTP Basic-Auth URL、Supabase `service_role` JWT 等通用格式。 ### 2. 提交到仓库的敏感文件 基于文件名的检测，用于标记那些无论内容如何都不适合提交的文件：`*.pem`、`*.key`、`*.pfx/.p12/.jks/.keystore`、`id_rsa`/`id_ed25519`/`id_ecdsa`、`.kdbx`（KeePass）、`.env.production`、`.aws/credentials`、GCP 服务账号 JSON、kubeconfig、`.docker/config.json`、带 auth 的 `.npmrc`、`terraform.tfstate`、数据库转储、`.git-credentials`、`.htpasswd`、`.pgpass`。每个检测结果都附带具体的修复步骤。 ### 3. `.env` / 配置文件中的高熵密钥 当正则表达式不起作用时，熵分析就能派上用场。TriageRook 会逐行解析 `.env`、`.envrc`、`.ini`、`.toml`、`.properties`、`.yaml` 和 `.conf` 文件，提取 `KEY=VALUE` 对，丢弃占位符（`xxx`、`changeme`、URL、semver、IP），并标记 Shannon 熵 ≥ 4.0 bits/char 且键名匹配 `password|secret|api_key|access_key|auth_token|client_secret|…` 的值。能够捕获专用正则表达式遗漏的自定义企业 token。 ### 4. 近期 git 历史中的密钥 即使是一个已轮换的密钥，如果它存在于过去的 commit 中，仍然是一个受损的密钥。TriageRook 通过 GitHub API 获取最多 30 次最近的 commit，提取添加的补丁行，并在其上重新运行完整的 60+ 模式库。检测结果会与当前树进行去重，因此只会显示历史记录中独有的匹配项，并标记上 commit SHA + 作者 + 日期。 ### 5. 代码级漏洞（SAST） 两层并排运行： - **AST 分析** 通过 TypeScript Compiler API（`ts-morph`）—— 针对带有 property 跳转的 JS/TS 进行 28 条规则检测，跟踪流入危险 sink 的用户输入，这是正则表达式层无法做到的。 - **保守的正则表达式规则** 适用于 AST 解析显得过于复杂的 JS/TS 和 Python —— 例如 TLS 验证被禁用、弱 bcrypt 成本、NEXT_PUBLIC_ 密钥读取、未使用 `SafeLoader` 的 Python `yaml.load` 等。 每条规则都绑定到一个 CWE 标识符，因此检测结果具有可操作性。核心覆盖范围（完整列表见 [`/docs/rules`](https://www.triagerook.com/docs/rules)）： - **注入** —— SQL（CWE-89）、命令（CWE-78）、NoSQL（`$where` 用户输入，CWE-943）、SSTI（CWE-1336）、原型污染（CWE-1321）、XXE（CWE-611） - **跨站脚本攻击** —— React `dangerouslySetInnerHTML`（CWE-79）、通过 `res.send` 反射的 XSS - **SSRF / 开放重定向** —— 带有 `req.body` / `req.params` 的 `fetch`/`axios`（CWE-918）、带有从请求派生的 URL 的 `res.redirect`（CWE-601） - **认证 / 授权** —— 没有签名 `expiresIn` 的 JWT（CWE-613）、带有硬编码字符串密钥的 JWT（CWE-798）、在未验证签名情况下解码的 JWT（CWE-347）、硬编码的管理员凭据、时间不安全的凭据比较（CWE-208） - **加密** —— 用于密码或密钥哈希的 MD5/SHA1（CWE-327）、弱密码模式（ECB / 弃用的 `createCipher`）、硬编码的加密密钥、用于会话 ID、OTP、token 的 `Math.random()`（CWE-338）、不安全的随机性 `uuid.v1()` - **路径 / 文件** —— 通过带有请求派生路径的 `fs.readFile`/`open()` 进行路径遍历（CWE-22） - **动态代码 / 执行** —— `eval`、`new Function`、`setTimeout(string)`、Python `eval`/`exec`（CWE-95） - **拒绝服务** —— 通过由用户输入构造的动态 `RegExp` 导致的 ReDoS（CWE-1333） - **网络 / 传输** —— TLS 验证被禁用（CWE-295）、通过明文 `ws://` 打开 WebSocket（CWE-319）、通过带有凭据的 `setHeader('Access-Control-Allow-Origin', '*')` 设置的通配符 CORS、带有 `origin: '*'` 的 CORS `credentials: true`（CWE-942） - **会话 / cookie 卫生** —— 不安全的 cookie `httpOnly: false` / `secure: false`（CWE-1004 / CWE-614）、不安全的会话配置（`resave: true`、`saveUninitialized: true`、弱密钥）、弱 bcrypt 成本（CWE-916） - **不安全的反序列化** —— Python `pickle.loads`、未使用 `SafeLoader` 的 `yaml.load`（CWE-502） - **信息泄露** —— 输出 `password` / `apiKey` / `token` / `secret` 命名局部变量的 `console.log`（CWE-532）、内联到客户端 bundle 中的 Next.js `NEXT_PUBLIC_*SECRET*` 环境变量读取（CWE-200） - **杂项 AI 典型错误** —— `process.env.X || "sk-…"` 后备字面量、N 低于 10 的 `bcrypt.hash(..., N)` 检测主要针对 JavaScript / TypeScript 运行。Python 的覆盖范围扩展到 SAST 的正则表达式层和漏洞的依赖项层。 **框架感知规则（上下文感知 SAST）。** 第三层读取仓库的 manifest 以检测正在使用的技术栈（Next.js、Express、NestJS、Django、Flask、FastAPI、Spring、Laravel、Rails），并*仅在该框架存在时*运行特定于框架的检查 —— 因此 `DEBUG = True` 会被标记为 Django 生产风险，而不是对任何名为 `DEBUG` 的变量产生的噪音。覆盖范围包括 Django `DEBUG`/`ALLOWED_HOSTS=['*']`/`@csrf_exempt`、Flask `debug=True`、FastAPI 带有凭据的通配符 CORS、Express/NestJS 默认通配符 CORS、Spring `csrf().disable()` / `@CrossOrigin("*")` / Actuator `exposure.include=*`、Laravel `'debug' => true` 以及 Rails `skip_before_action :verify_authenticity_token`。 ### 6. 易受攻击的依赖项（npm、PyPI、Go、RubyGems、Maven/Gradle、Composer） - **npm** —— 优先使用 `package-lock.json` 以覆盖整个依赖树（直接 + 传递），支持 lockfile v1、v2 和 v3。查询 npm advisory bulk API，并将每个检测结果链接到其 GHSA + CVSS 分数。 - **PyPI** —— 解析 `requirements.txt`、`pyproject.toml`（PEP-621 + Poetry）和 `Pipfile`。查询 [OSV.dev](https://osv.dev) batch API，并用严重程度、受影响范围和 GHSA 链接来丰富每个漏洞的详细信息。 - **Go** —— 解析 `go.mod`（直接 + 间接 require，剥离 `+incompatible`）。使用 ecosystem `Go` 查询 OSV；advisory 链接到 `pkg.go.dev/vuln/...` 以获取官方 Go 漏洞页面（如果有）。 - **RubyGems** —— 解析 `Gemfile.lock` 以获取固定版本（单独的 Gemfile 不具有权威性，因为它只包含约束，不包含具体版本）。使用 ecosystem `RubyGems` 查询 OSV，advisory 覆盖范围与 `bundler-audit` 相同。 - **Maven / Gradle (JVM)** —— 解析 `pom.xml` 和 `build.gradle` / `build.gradle.kts`（两者都解析 Maven 坐标 artifact）。使用 ecosystem `Maven` 查询 OSV。无法静态解析的属性插值（`${spring.version}`）和动态（`1.+`）版本将被跳过。 - **Composer (PHP)** —— 解析 `composer.lock`（`packages` + `packages-dev`）。使用 ecosystem `Packagist` 查询 OSV，与 `composer audit` 使用的数据库相同。 - **容器镜像** —— OS 软件包 CVE（lockfile 无法看到的 `apt`/`apk`/`rpm` 层）通过你在 CI 中运行并 commit 的 [Trivy](https://trivy.dev) SARIF 报告摄取 —— 作为 **Container** ecosystem 并入。我们这端不需要镜像扫描基础设施；设置指南见 [`docs/container-scanning.md`](docs/container-scanning.md)。 所有 ecosystem 共享一个 OSV 查询核心、相同的 500 个软件包上限以及优雅降级（注册表故障会将检测器标记为跳过，而不是导致扫描失败）。 ### 7. 供应链攻击（typosquatting、install hook、dependency confusion） - **Lifecycle hook 滥用（npm + PyPI）** —— `package.json` 脚本（`preinstall`/`install`/`postinstall`/`prepare`）以及运行 `curl | sh`、`base64` 解码并执行、环境变量外泄与网络调用相结合，或具有破坏性的 `rm -rf` 链的 Python `setup.py`/`pyproject.toml` 构建钩子。捕获近期 npm 和 PyPI 入侵事件中使用的安装时供应链攻击向量。 - **依赖 manifest 中的 typosquatting** —— 标记名称为流行的 npm 和 PyPI 注册表名称的编辑距离为 1（`lodahs`、`expres`、`reqests`）、编辑距离为 2 前缀（`lodashes`）或大小写变体（`Chalk`）的软件包。 - **注册表支持的供应链信号（npm）** —— 通过公开的 npm 注册表元数据：**dependency confusion**（一个在公共注册表上返回 404 的声明名称 —— 攻击者可以认领它并劫持解析）、**最近发布**的软件包（在 30 天内创建 —— 常见的 typosquat/劫持载体），以及**可疑维护者**信号（已弃用的软件包，或列出的维护者为零）。 ### 8. IaC & CI 配置错误 - **Dockerfile** —— 以 root 身份运行容器、缺少 `USER` 指令、`:latest` 基础 tag、`ADD http(s)://`、烘焙到 `ENV` 中的密钥、`RUN curl | sh`、`chmod 777`、未固定的 `apt install`，以及**生命周期已结束（EOL）的基础镜像** - **GitHub Actions** —— 暴露密钥的 `pull_request_target` 签出 PR head（s1ngularity / GhostAction 向量）、未固定到完整 SHA 的第三方 Actions、插值 `${{ github.event.* }}` 字段的 `run:` 步骤（脚本注入）、工作流级别的 `permissions: write-all`，以及**设置为由提交的字面量而非 `${{ secrets.* }}` 的以密钥命名的 `env:` 值** - **Terraform** —— 公共 S3 ACL 和被禁用的 public-access-block 标志、对 `0.0.0.0/0`（以及 `::/0`）开放的安全组 `ingress`、通配符 IAM `Action`/`Resource`（`*`）、未加密的存储（`storage_encrypted = false`）、可公开访问的数据库（`publicly_accessible = true`） - **CloudFormation** —— 针对 CFN 模板（YAML **和** JSON）设置相同的 AWS 配置错误集：公共 S3 ACL / 被禁用的 public-access-block、通配符 IAM action/resource、对 `0.0.0.0/0` 开放的 `SecurityGroupIngress`（正确忽略 egress）、未加密的存储、可公开访问的 RDS。基于 `AWSTemplateFormatVersion` / `Resources` + `AWS::` 类型进行自我保护，从而跳过非模板的 YAML/JSON。 - **Kubernetes** —— 带有特权容器、host namespace（`hostNetwork`/`hostPID`/`hostIPC`）、`allowPrivilegeEscalation`、以 root 运行（`runAsUser: 0` / `runAsNonRoot: false`）、可变镜像 tag（`:latest`/未打 tag）以及危险添加的 Linux capability（`SYS_ADMIN`、`NET_ADMIN`、`ALL`、…）的 manifest（通过 `apiVersion:` + `kind:` 检测）。Helm 模板化的行将被跳过以避免噪音。 - **Helm** —— chart 的 `values*.yaml` 中流入每个渲染出的工作负载的不安全默认值（`privileged`、`runAsNonRoot: false` / `runAsUser: 0`、host namespace、`allowPrivilegeEscalation`、可变镜像 tag）。Values 文件不是渲染后的 manifest，因此 Kubernetes 层会跳过它们 —— 这就抓住了这个盲点。 - **代码中的云 IAM** —— 代码/配置中声明的过度特权云 IAM（云权限的 `chmod 777`）：带有通配符 action（`"Action": "*"`）、服务级通配符（`"s3:*"`）、通配符 resource（`"Resource": "*"`）或公共 principal 的 **AWS** IAM policy 文档 —— 基于真实的 `Statement` + `Effect` 上下文进行拦截，以避免对任意 JSON 产生误报；**GCP** 原始角色（`roles/owner`、`roles/editor`）；**Azure RBAC** 内置的 `Owner` / `Contributor` 分配和通配符自定义角色；以及 **GitHub** 过于宽泛的 OAuth/PAT scope 请求（`delete_repo`、`admin:org`、`admin:enterprise`、`admin:repo_hook`、`site_admin`）。HCL（`.tf`）留给 Terraform 层处理。这是*代码中*的身份风险，有别于 IAM 姿态信号（#9）和 IAM 风险扫描器（#10）。 ### 9. 仓库姿态评分 除了寻找特定的检测结果外，TriageRook 还会对仓库的设置方式进行评分：治理文档（`SECURITY.md`、`LICENSE`、`CODEOWNERS`）、默认分支上的分支保护 + 规则集（需要 PR 审查、status check、enforce-admins）、已签名的 commit 比例、组织 MFA 强制执行、依赖更新自动化、lockfile/`.gitignore` 卫生，以及 **GitHub secret scanning + push protection**、**最小权限默认 `GITHUB_TOKEN` 权限**和**发布签名 / build provenance**（cosign / sigstore / SLSA / npm `--provenance`）。结果是一个单一的 A-F 评分，计算方式为**可评估信号的百分比** —— token 无法检查的信号（例如公共扫描中仅限管理员的 secret scanning 状态）将被报告为 `unknown` 并从计算中排除，而不是算作失败，从而保持评分的真实性，并且缺少管理员 scope 也不会拉低分数。每个信号的详细分类准确展示了需要修复什么才能提高评分。 ### 10. IAM 风险扫描器 一个拥有 10 多年经验的 IAM/IGA 专家真正关心的角度：你提交的 IAM policy-as-code 中的身份和访问风险。TriageRook 从 Terraform、CloudFormation/SAM、原始 JSON 和 serverless 配置中解析出 IAM policy 文档，然后对它们运行三大类检查 —— **GitHub Actions OIDC 信任**弱点（无 `Condition`、通配符 repo/ref、`pull_request` 信任）、**提权**路径（`*` 上的 `iam:PassRole`、PassRole 与计算创建结合、自我管理策略、无条件的 `sts:AssumeRole`、`Allow` + `NotAction`），以及**等同于管理员的**授权（`Resource: *` 上的 `Action: *`、敏感服务的通配符、没有 `Condition` 的通配符 `Principal`）。检测结果会从映射到低/中/高/严重级别的 100 分制中扣分。它读取的是 policy-as-code，而不是你实时的云控制平面，并且不需要提升的 GitHub scope。（组织级别的 MFA 强制执行作为仓库姿态信号单独评分。）带有易受攻击与已修复示例的完整文章见 [`/docs/iam-risk-scanner`](https://www.triagerook.com/docs/iam-risk-scanner)。这是独立开发者和小团队以前无法接触到的企业 IAM 工具的切片。 ### 11. 开源许可证 / 合规风险 法律风险而非安全风险：专有产品中传递的 GPL/AGPL 依赖项，或者一个完全没有许可证的软件包（这授予你使用它的法律权利），是 CVE 扫描永远不会暴露的真实问题。对于 **npm**，TriageRook 读取记录在 `package-lock.json`（v2/v3）每个条目上的 `license` 字段 —— **无需额外的网络调用**。对于 **PyPI / Go / RubyGems**（其 lockfile 不携带许可证数据），它通过 [deps.dev](https://deps.dev)（Google 的 Open Source Insights —— 与 OSV.dev 同属良性的公共元数据性质）进行丰富，限制在 200 个软件包以内并具有优雅降级。它标记**强 copyleft**（GPL/AGPL/SSPL）、**弱 copyleft**（LGPL/MPL/EPL/CDDL）和**专有/UNLICENSED** 许可证。带有宽松许可出口的双授权 `(MIT OR GPL-3.0)` 表达式被视为可接受的，而仅用于开发的 npm 依赖项会被跳过，因为它们不会被重新分发。 ## 超越检测 ### SARIF 2.1.0 导出 + GitHub Code Scanning 每次保存的扫描只需点击一下即可导出为 SARIF 2.1.0。将该文件放入 `github/codeql-action/upload-sarif`，检测结果就会显示在你仓库的 `Security → Code scanning` 标签页中，紧挨着 CodeQL 和 Dependabot —— 每个结果都深度链接回其规则文档。`/scan-public//` 上的匿名扫描也可以导出 SARIF（在客户端从处理中的结果生成）。对于公开仓库，匿名扫描 endpoint 直接接受 `?format=sarif` —— 将[现成的工作流](https://www.triagerook.com/workflows/triagerook.yml)放在 `.github/workflows/triagerook.yml`，每次 push 都会被扫描 + 上传，且无需任何 auth 设置。完整的设置指南和可复制粘贴的工作流 YAML 见 [`/docs/sarif`](https://www.triagerook.com/docs/sarif)。 ### 密钥有效性验证（可选启用） 启用后（`ENABLE_SECRET_VALIDATION=true`），已认证的扫描会额外针对单个只读 endpoint 探测每个检测到的提供商密钥 —— GitHub、GitLab、Stripe、OpenAI、Anthropic、SendGrid、Slack、npm —— 将其标记为**有效**或**已撤销/未激活**，*绝不暴露或存储其值*（仅限状态）。确认有效的凭据会被提升到报告的顶部；被拒绝的凭据会被下推，因为几乎可以肯定它已经被轮换了。这是密钥检测结果中最大的误报消除手段。它**默认关闭**，并且**绝不**在匿名公共扫描路径上运行 —— 该路径扫描任意仓库，而 TriageRook 不会使用陌生人泄露的凭据发起第三方 API 调用。AWS 密钥被报告为不可验证（验证它们需要两半密钥以及请求签名）。 ### 风险优先级排序 按原始严重程度排序的 500 条检测结果只是噪音。TriageRook 在排名之前会针对每个检测结果的*真实*紧急程度进行评分：基础严重程度，然后是对所检测到的密钥是否**确认为有效**（验证，见下文）、易受攻击的依赖项是**传递的**还是直接的，或者是**仅用于开发还是用于生产**（开发依赖项不会发布到 runtime）、代码检测结果是否位于 **HTTP 可访问的文件**中（位于 `routes/`、`controllers/`、`pages/api` 或 `app/**/route.ts` 的检测结果可被攻击者触达，因此其排名高于内部代码中相同的 bug），以及它是否位于**测试夹具**中（降低优先级）中的乘数。仓库评分经过对数压缩，因此一个拥有数百个严重问题的大型 monorepo 的评分读起来不会像一个只有四个问题的业余项目。 ### 攻击路径与爆炸半径 单个的检测结果告诉你*出了什么问题*；而这个功能告诉你*那又怎样*。TriageRook 将检测结果关联成多跳的**攻击路径**，并为每个泄露的凭据分配一个**爆炸半径** —— 它能触及的具体资产。一个泄露的 AWS 密钥变成“→ AWS 账户 → S3/RDS/数据”；将其与同一仓库中公共 S3 或通配符 IAM 的检测结果配对，该路径就会被链接并提升为严重级别。SCM token 揭示了“→ CI/CD → 下游供应链”的跳板；支付密钥揭示了客户数据的可触及性。当密钥验证（见上文）确认凭据有效时，其路径会被标记并置顶。纯粹是基于现有检测结果的关联 —— 无需额外调用。 ### 自动修复 Pull Request 对于具有明确、确定性修复的检测结果，TriageRook 可以直接针对你的仓库开启一个 PR： - **将硬编码的密钥提取**到环境变量 + 更新 `.env.example` - **将易受攻击的依赖项**（npm / Python）升级到非易受攻击的版本 - **将生命周期已结束的 Docker 基础镜像升级**到当前版本（保留变体后缀） - 用最小权限的 `contents: read` 替换工作流中的 `permissions: write-all` 需要在目标仓库上安装 **TriageRook Security** GitHub App 才能创建 PR —— 安装仅限于单个仓库，并且仅授予 `Contents: write` 和 `Pull requests: write` 权限。你可以在合并前审查该 PR。（未固定 Actions 的 SHA 固定特意不进行自动修复 —— 将 tag 解析为 commit SHA 需要网络查找，这不符合纯补丁模型。） ### 按仓库屏蔽 误报时有发生。你可以检测结果视图中屏蔽单个检测结果（通过指纹）、路径上的某条规则（通过 glob），或针对仓库屏蔽整条规则。屏蔽是按用户划分范围的，并通过 Supabase 同步 —— 它们可以在多次扫描中保留，而无需向仓库提交 `.repoguardignore`（尽管该文件在扫描时也会被采用）。 ## 文档 完整的产品文档位于 **[triagerook.com/docs](https://www.triagerook.com/docs)** —— 专为充满怀疑精神的开发者编写，每一个事实陈述均源自此代码库： - [安全与数据处理](https://www.triagerook.com/docs/security-and-data-handling) —— GitHub App 权限、每个扫描 endpoint 存储的内容、密钥掩码。 - [扫描限制](https://www.triagerook.com/docs/scan-limits) · [屏蔽](https://www.triagerook.com/docs/suppressions) · [快速入门](https://www.triagerook.com/docs/quickstart) · [FAQ](https://www.triagerook.com/docs/faq) - [检测器](https://www.triagerook.com/docs/detectors) · [检测规则](https://www.triagerook.com/docs/rules) · [姿态评分](https://www.triagerook.com/docs/posture-score) · [IAM 风险扫描器](https://www.triagerook.com/docs/iam-risk-scanner) - [SARIF 导出](https://www.triagerook.com/docs/sarif) · [更新日志](https://www.triagerook.com/docs/changelog) 安全策略和漏洞报告：[SECURITY.md](SECURITY.md)。 ## 隐私 我们**绝不**在我们的数据库中存储： - 你的源代码（我们只保留文件路径和掩码后的预览 —— 绝不包含完整的文件内容） - 你的 GitHub access token（它存在于加密的 Auth.js session cookie 中，用于服务器端的扫描调用，并且绝不会写入 Supabase 或通过 `/api/auth/session` 暴露） - 完整的密钥值（仅限类型、文件路径、行号和掩码后的预览） 我们**确实**存储：扫描元数据（所有者/仓库、时间戳、计数）和检测结果（文件路径 + 行号 + 模式 ID + 掩码预览），以便你可以审查历史记录。 数据位于 Supabase（欧盟区域）和 Vercel 中。你可以随时通过你的 [GitHub 设置](https://github.com/settings/applications)撤销访问权限。完整详情见[安全页面](https://www.triagerook.com/security)。 ## 技术栈 - **框架：** Next.js 16 (App Router) + TypeScript + Tailwind - **认证：** 由 **TriageRook Security GitHub App** 支持的 NextAuth v5（用户 OAuth 提供对公开仓库的读取权限；在目标仓库上安装 App 会授予自动修复 PR 所需的范围受限的写入权限） - **数据库：** Supabase（Postgres + JSONB，欧盟区域），以 RLS 策略作为纵深防御层 - **托管：** Vercel - **静态分析：** `ts-morph`（TypeScript Compiler API 包装器），用于 AST 层 - **API：** GitHub REST v3、npm audit bulk、OSV.dev（PyPI/Go/RubyGems/Maven/Composer）、deps.dev（注册表许可证元数据）、npm registry（供应链信号）；容器 CVE 从提交的 Trivy SARIF 报告中摄取 ## 在本地运行 前提条件：Node 20+、一个 GitHub 账号、一个 Supabase 项目（免费套餐即可）。 ``` git clone https://github.com/silviooerudon/triagerook.git cd triagerook npm install ``` 创建 `.env.local`： ``` AUTH_SECRET= # generate with: npx auth secret AUTH_GITHUB_APP_CLIENT_ID= # from the TriageRook Security GitHub App (OAuth user flow) AUTH_GITHUB_APP_CLIENT_SECRET= SUPABASE_URL= SUPABASE_SECRET_KEY= # Supabase service-role key (server-side only) # 可选 — 仅当您想在本地测试 auto-fix PR 流程时需要： # AUTH_GITHUB_APP_ID= # AUTH_GITHUB_APP_PRIVATE_KEY= # PEM, 在 .env 中将换行符转义为 \n ``` 在 Supabase 中创建 `scans` 表（schema 在 `docs/` 中），然后： ``` npm run dev ``` 打开 [http://localhost:3000](http://localhost:3000)。 ## 路线图 公开构建。现在的检测面已经很广了 —— 最近的工作弥补了针对标准“仓库扫描器必须涵盖的内容”检查清单的 遗留盲点： - [x] SARIF 2.1.0 导出和 GitHub Code Scanning 集成 —— [`/docs/sarif`](https://www.triagerook.com/docs/sarif) - [x] 忽略规则 / 针对单个检测结果的屏蔽（按用户划分范围，通过 Supabase 同步） - [x] 自动修复 Pull Request —— 提取密钥、依赖项升级、EOL 基础镜像升级、工作流 `write-all` → 最小权限 - [x] Go 和 Ruby 依赖项扫描（OSV.dev —— `go.mod` + `Gemfile.lock`） - [x] Maven/Gradle + Composer 依赖项扫描（OSV.dev —— `pom.xml` / `build.gradle` / `composer.lock`） - [x] 通过 Trivy SARIF 摄取的容器镜像 OS 软件包 CVE —— [`docs/container-scanning.md`](docs/container-scanning.md) - [x] Terraform + **CloudFormation** + **Helm** IaC 规则 - [x] PyPI/Go/RubyGems 许可证/合规覆盖范围（通过 deps.dev） - [x] 代码中的云 IAM：AWS + GCP + **Azure RBAC** + **GitHub OAuth scope** - [x] 姿态：secret scanning、工作流最小权限、发布出处 - [ ] 通过 GitHub webhook 进行持续扫描（push 时扫描 + 新检测结果警报） - [ ] 团队账号和共享扫描历史 - [ ] 私有仓库支持（读取范围扩大） - [ ] 计费 / 付费层 剩余的未完成项目属于商业化层（持续监控、 团队、私有仓库、计费），而不是检测覆盖范围。 如果这里有你关注的内容，请[提出 issue](https://github.com/silviooerudon/triagerook/issues) —— 反馈决定优先级。 ## 作者 由 **Silvio Gazzoli** 开发 —— 位于爱尔兰都柏林的 IAM/IGA 专家。拥有 10 多年使用 SailPoint、CyberArk 和企业身份治理的经验。 [LinkedIn](https://www.linkedin.com/in/silvio-junior-de-almeida-gazzoli-78453a8a/) · [GitHub](https://github.com/silviooerudon) ## 许可证 MIT

标签：IaC安全, SARIF, SCA软件成分分析, StruQ, 代码安全审计, 自动化攻击, 静态应用安全测试