
应用安全供应链安全【免费下载链接】gitleaksFind secrets with Gitleaks 项目地址https://gitcode.com/GitHub_Trending/gi/gitleaks点击查看免费下载Gitleaks 是一款用于扫描仓库中硬编码密钥的开源工具其默认检测能力全部来自自动生成的 config/gitleaks.toml 配置文件。本篇指南基于仓库根目录的 CONTRIBUTING.md完整讲解如何为 Gitleaks 贡献一条新的检测规则从创建规则源码文件、注册到生成入口、再到运行make config/gitleaks.toml产出正式配置并提交 Pull Request。读完本文你将掌握 Gitleaks 规则体系的两大核心生成函数GenerateSemiGenericRegex与GenerateUniqueTokenRegex、真/假阳性验证机制以及一条规则从 Go 源码到 TOML 配置的完整生命周期。一、贡献流程总览Issues 与 Pull RequestsIssues先声明再动手如果你希望贡献一个新功能或 Bug 修复先检查仓库中是否已有描述该提议的 open issue若已有对应 issue在 issue 下留言声明你正在处理它避免多人重复劳动若没有则新建一个 issue 详细描述你的改动并在后续的 PR 中链接到该 issue。Pull Requests模板与测试提交 PR 时尽量完整填写 PR 模板并确保所有测试通过。仓库的 Makefile 中定义了test目标go test -v ./... --race且test依赖config/gitleaks.toml——这意味着任何规则改动都会先触发配置重新生成再执行全量测试。此外如果你看到他人提交的 PR 并希望其进入下一个版本可以在该 PR 描述上点一个 thumbs up表示支持。二、规则代码生成架构为什么新增规则要改 Go 代码Gitleaks 的默认配置并非手写 TOML而是通过cmd/generate下的一组 Go 程序自动生成。整个生成链路为每条规则以 Go 函数形式定义在 cmd/generate/config/rules 目录下的独立文件中每个 provider 一个文件例如beamer.go、aws.go、github.gocmd/generate/config/main.go 的main()把所有这些规则函数收集进configRulesslice程序通过 cmd/generate/config/rules/config.tmpl 这个 Gotext/template模板把规则对象渲染成 TOML写入 config/gitleaks.tomlMakefile 中config/gitleaks.toml目标的依赖是$(wildcard cmd/generate/config/**/*)执行体为go generate ./...因此改动cmd/generate下任何文件后运行make config/gitleaks.toml即可触发重新生成。模板文件开头特意注明This file has been auto-generated. Do not edit manually.——也就是说正确的贡献方式是改 Go 源码而不是直接手改 TOML。每条规则在模板中会被渲染为一段[[rules]]配置块包含id、description、regex、keywords并可选渲染path、secretGroup、entropy、tags与规则级 allowlist。三、第一步创建cmd/generate/config/rules/{provider}.go新增规则的第一步是创建cmd/generate/config/rules/{provider}.go文件。以 cmd/generate/config/rules/beamer.go 为例该文件与文档示例完全一致一条规则函数的完整形态如下package rules import ( github.com/zricethezav/gitleaks/v8/cmd/generate/config/utils github.com/zricethezav/gitleaks/v8/cmd/generate/secrets github.com/zricethezav/gitleaks/v8/config ) func Beamer() *config.Rule { // define rule r : config.Rule{ Description: Detected a Beamer API token, potentially compromising content management and exposing sensitive notifications and updates., RuleID: beamer-api-token, Regex: utils.GenerateSemiGenericRegex([]string{beamer}, b_[a-z0-9_\-]{44}, true), Keywords: []string{beamer}, } // validate tps : utils.GenerateSampleSecrets(beamer, b_secrets.NewSecret(utils.AlphaNumericExtended(44))) fps : []string{ │ ├── R21A-A-V010SP13RC181024R16900-CN-B_250K-Release-OTA-97B6C6C59241976086FABDC41472150C.bfu, } return utils.Validate(r, tps, fps) }对照 config/rule.go 中Rule结构体的定义可以理解各字段的语义Description人类可读的规则描述会原样写入 TOML也会出现在扫描报告中RuleID规则唯一标识main.go会对它做唯一性检查重复会直接 FatalRegex用于检测秘密的 Go 正则表达式是整个规则的核心Keywords预过滤关键词。Gitleaks 在跑完整正则前会先做一次快速的字符串比较只有内容中出现至少一个 keyword 才继续匹配正则相当于扫描性能的前置过滤器。从 config/rule.go 的注释可见keywords 用于 pre-regex check filtering此外Rule还支持Entropy香农熵下限、SecretGroup从正则匹配中提取秘密的捕获组序号、Path按文件路径过滤、Tags报告元数据、Allowlists规则级豁免等字段需要时可在规则文件中补充。正则与秘密生成两条核心辅助函数为了让规则风格统一、便于维护绝大多数规则都应使用 cmd/generate/config/utils/generate.go 中定义的两个生成器。其函数签名如下func GenerateSemiGenericRegex(identifiers []string, secretRegex string, isCaseInsensitive bool) *regexp.Regexp func GenerateUniqueTokenRegex(secretRegex string, isCaseInsensitive bool) *regexp.RegexpGenerateSemiGenericRegex半通用正则接受一组标识符identifiers、一个秘密正则、以及是否大小写不敏感的布尔值。identifiers列表应当与规则定义中的Keywords保持一致——两者都充当过滤器告诉 Gitleaks 内容中至少出现这些字符串之一才可能构成泄露。从源码可以看到它实际拼装的完整模式(?i)[\w.-]{0,50}?(?:ident1|ident2)(?:[ \t\w.-]{0,20})[\s]{0,3}(?:||:{1,3}|\|\||:||\?|,)[\x60\s]{0,5}(SECRET)(?:[\x60\s;]|\\[nr]|$)其中运算符部分覆盖了常见的赋值或函数调用写法、、:、:、::、||、、?、,等秘密前后的边界符则保证了匹配到的是真实值而不是长文本中的偶然命中。GenerateUniqueTokenRegex唯一令牌正则只接受秘密正则与大小写不敏感开关。当令牌本身足够独特、无需标识符辅助时使用。文档给出了选型建议如果令牌前缀超过 3 个字符通常就可以直接用GenerateUniqueTokenRegex。仓库中的对照示例是 cmd/generate/config/rules/pulumi.go——Pulumi 的 API Token 前缀为pul-足够独特因此直接使用GenerateUniqueTokenRegex(pul-[a-f0-9]{40}, false)并辅以Entropy: 2与Keywords: []string{pul-}而 Beamer 的b_前缀只有 2 个字符、不够独特所以改用GenerateSemiGenericRegex并要求beamer标识符必须出现。此外 patterns.go 还提供了一批字符类辅助函数用于拼接秘密正则的字符集部分函数生成的正则片段典型用途Numeric(size)[0-9]{n}纯数字令牌Hex(size)[a-f0-9]{n}十六进制令牌AlphaNumeric(size)[a-z0-9]{n}字母数字令牌AlphaNumericExtendedShort(size)[a-z0-9_-]{n}含下划线/连字符AlphaNumericExtended(size)[a-z0-9_\-]{n}含等号/下划线/连字符AlphaNumericExtendedLong(size)[a-z0-9\/_\\-]{n}含斜杠/加号等Hex8_4_4_4_12()[0-9a-f]{8}-[0-9a-f]{4}-…-{12}UUID 形态Beamer 的秘密体b_[a-z0-9_\-]{44}就是通过AlphaNumericExtended(44)生成的字符集拼出来的。secrets.NewSecret(regex)见 cmd/generate/secrets/regen.go基于reggen库按给定正则随机生成一个合规的秘密值用于构造 true positive 样本。验证部分真阳性与假阳性规则文件最后必须调用utils.Validate(r, tps, fps)见 cmd/generate/config/utils/validate.go。它的工作方式是对每一个 true positivetps用单规则检测器执行DetectString若检测不到任何 finding则记录 Fatal 日志并终止生成对每一个 false positivefps同样执行检测若产生了 finding同样 Fatal 终止。也就是说新增规则在生成配置时就会被强制验证——规则必须能命中你提供的正样本、且不能误伤负样本否则make config/gitleaks.toml直接失败。这样从源头保证了默认配置的质量。tps建议通过generateSampleSecret/GenerateSampleSecrets构造。前者生成identifier_api_token secret这种单一样本后者见 generate.go 中的GenerateSampleSecrets则一次性生成覆盖 INI、JSON、XML、YAML、C#、Go、Java、Kotlin、PHP、Python、Makefile含、:、::、?等赋值形式以及 logstash 等多种写法的样本集大大增强规则的健壮性。仓库还提供了ValidateWithPaths变体当规则使用Path过滤时样本以map[string]string形式同时携带文件路径检测器通过detect.Fragment{Raw: …, FilePath: …}验证正则 路径的组合行为。验证用的检测器由createSingleRuleDetector构建它会先把关键词统一小写并去重strings.ToLower map 去重再套用 base.CreateGlobalConfig 中的全局 allowlist 后构造单规则配置。这意味着新规则在开发期就运行在与真实扫描相同的全局豁免规则之下行为可预期。四、第二步在cmd/generate/config/main.go中注册规则创建好规则文件后打开 cmd/generate/config/main.go在main()的configRulesslice 中追加rules.Beamer(),。请尽量按字母序插入——例如rules.Beamer()就位于rules.BittrexSecretKey()与rules.CodecovAccessToken()之间。从main.go的后续逻辑可以看到注册环节附带的三重保障规则自检遍历configRules时对每条规则调用rule.Validate()config/rule.go 中的实现会检查RuleID非空regex与path至少有一个否则该规则将毫无效果secretGroup不能超过正则的捕获组数量。校验失败会输出带 rule-id 的 Fatal 日志并退出ID 唯一性检查以RuleID为键存入ruleLookUpmap若发现重复 ID 直接 Fatal——保证生成出的 TOML 中每条[[rules]]的id全局唯一allowlist 归一化对规则级与全局 allowlist 中的Commits与StopWords做排序保证多次生成结果稳定可复现。最后程序用base.CreateGlobalConfig()构造带全局 allowlist 的配置对象并把ruleLookUp注入其中通过tmpl.Execute渲染出完整的 TOML 文件。五、第三步运行make config/gitleaks.toml重新生成配置注册完成后在仓库根目录执行make config/gitleaks.toml该目标在 Makefile 中定义依赖cmd/generate/config下所有文件执行go generate ./...。main.go顶部的//go:generate go run $GOFILE ../../../config/gitleaks.toml指令会把生成结果输出到 config/gitleaks.toml。注意main.go运行时要求命令行参数指定输出路径go generate已代为传入若手动运行则需提供路径参数否则程序会向 stderr 输出错误并以状态码 2 退出。六、第四步检查生成的config/gitleaks.toml生成完成后打开 config/gitleaks.toml 检查新规则。以beamer-api-token为例位于文件中 L243-L247实际渲染结果如下[[rules]] id beamer-api-token description Detected a Beamer API token, potentially compromising content management and exposing sensitive notifications and updates. regex (?i)[\w.-]{0,50}?(?:beamer)(?:[ \t\w.-]{0,20})[\s]{0,3}(?:||:{1,3}|\|\||:||\?|,)[\x60\s]{0,5}(b_[a-z0-9_\-]{44})(?:[\x60\s;]|\\[nr]|$) keywords [beamer]可以看到RuleID渲染为idDescription原样保留GenerateSemiGenericRegex拼装出的完整正则渲染进regex字段捕获组即为秘密体Keywords渲染为keywords。如果规则设置了Entropy、SecretGroup、Path、Tags或规则级 allowlist也会按 config.tmpl 的规则分别渲染为对应 TOML 字段。minVersion字段也值得留意模板中固定写入minVersion v8.25.0它表示运行该配置所需的最低 Gitleaks 版本版本过旧时会记录警告并提示部分配置功能可能不生效。同时建议确认生成的规则在全局 allowlist由 base/config.go 提供之下不会误伤常见占位符、环境变量引用、插值变量等场景相关豁免行为有 config_test.go 中的TestConfigAllowlistRegexes与TestConfigAllowlistPaths做回归保障。七、第五步提交 Pull Request确认新规则在 config/gitleaks.toml 中渲染正确、全量测试通过后即可提交 PR并在 PR 描述中链接对应的 issue。提交时应同时包含两部分改动新增的规则源码文件如cmd/generate/config/rules/{provider}.go重新生成的 config/gitleaks.toml不要手工编辑必须由生成器产出否则下一轮make config/gitleaks.toml会覆盖手改内容。遵循改源码、跑生成、验结果、提 PR这条流程就能以最小成本为 Gitleaks 的默认规则集持续添砖加瓦同时借助内置的规则校验与真/假阳性验证机制确保每一条新规则在上线前都经过严格的质量把关。赞分享应用安全供应链安全【免费下载链接】gitleaksFind secrets with Gitleaks 项目地址https://gitcode.com/GitHub_Trending/gi/gitleaks点击查看免费下载相关推荐如何为TruffleHog添加新的凭证检测器完整贡献指南如何为TruffleHog添加新的凭证检测器完整贡献指南 TruffleHog是一款强大的开源凭证嗅探工具能够帮助开发者在代码中发现泄露的敏感信息。本文将详应用安全安全与开源治理漏洞扫描RemBERT vs mBERT对比分析为什么分离嵌入能提升模型性能RemBERT vs mBERT对比分析为什么分离嵌入能提升模型性能 RemBERT和mBERT作为多语言预训练模型的代表在跨语言自然语言处理任务中发挥着重终极Alex.js贡献指南如何为包容性写作工具添加新规则终极Alex.js贡献指南如何为包容性写作工具添加新规则 Alex.js是一款强大的包容性写作工具能够帮助开发者和内容创作者识别并替换文本中可能冒犯他人的表开发工具Lint上一篇U-Flow 模型深度解析U 形归一化流与无监督阈值的图像异常定位anomalib 实现下一篇Security-101 应用安全AppSec关键能力全解析13 类工具与测试方法的实战选型指南创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考