示例工程CI/CDDevOps【免费下载链接】starter-workflowsAccelerating new GitHub Actions workflows项目地址https://gitcode.com/GitHub_Trending/st/starter-workflows点击查看免费下载本文基于starter-workflows仓库的 code-scanning 目录系统讲解如何借助 GitHub Actions 工作流为仓库启用代码扫描Code Scanning从 GitHub 原生 CodeQL 到 Bandit、Trivy、Semgrep、Snyk 等第三方扫描器再到依赖审查与供应链安全评分。读完本文你将掌握 code scanning 的启用方式、工作流结构、SARIF 结果上传机制以及一套可直接落地的安全扫描矩阵。一、什么是 GitHub Code Scanning为什么要用工作流启用它GitHub Code Scanning 是一种开发者优先、GitHub 原生的安全能力其核心目标是在漏洞到达生产环境之前尽早发现它们。starter-workflows仓库在 code-scanning/README.md 中明确指出一个关键前提在为一个仓库配置 Code Scanning 之前必须先通过向仓库添加一个 GitHub Actions 工作流来启用它。也就是说Code Scanning 并非一个打开开关就生效的默认功能而是以工作流即配置的形态存在的扫描器无论是 GitHub 官方出品的 CodeQL还是第三方安全工具都以 Action 的形式在 CI 流水线中运行扫描结果通过 SARIF 格式上传回 GitHub 的 Security 标签页统一展示。这正是本仓库code-scanning/目录的价值所在它集中提供了近百个可以直接复制使用的 Code Scanning 起步工作流starter workflow覆盖GitHub 原生静态分析CodeQL语言级 SAST 工具BanditPython、ESLintJavaScript/TypeScript、RuboCop、detekt 等依赖与供应链安全Dependency Review、OSV-Scanner、Debricked、datree镜像与基础设施扫描Trivy、tfsec、kubesec、Checkov 系策略校验综合安全平台Snyk、Semgrep、SonarQube、Veracode、Fortify 等。每个工作流都配套了对应元数据文件code-scanning/properties/*.properties.json描述其名称、创建者、适用语言与分类例如 codeql.properties.json 声明 CodeQL 支持 C、C、C#、Go、Java、JavaScript、TypeScript、Python、Ruby、Kotlin 与 Swift。二、快速上手把起步工作流变成仓库里的扫描任务启用 Code Scanning 的实操路径是从本仓库的 code-scanning 目录中选取合适的工作流文件复制到你的仓库.github/workflows/目录下并提交。工作流一旦被提交到仓库就会按照on声明的触发条件自动运行。以最基础的触发结构为例绝大多数起步工作流统一采用三种触发组合on: push: branches: [ main, protected-branches ] pull_request: branches: [ main ] schedule: - cron: 0 0 * * 0 # 每周定时扫描这种设计覆盖了三种典型场景触发事件作用push每次推送到默认/受保护分支时扫描保证主分支代码始终处于被检查状态pull_request每次 PR 时扫描在合并前拦截新引入的漏洞可与分支保护规则联动schedule定期重扫捕获依赖更新后新暴露的 CVE弥补增量扫描的盲区关键权限约定几乎所有工作流都在 job 级别声明了一组最小权限例如 bandit.yml 与 trivy.yml 中的模式permissions: contents: read # 供 actions/checkout 拉取代码 security-events: write # 供 github/codeql-action/upload-sarif 上传 SARIF 结果 actions: read # 私有仓库中 upload-sarif 获取 Action 运行状态所需其中security-events: write是 Code Scanning 的核心权限——没有它扫描结果无法写入 GitHub 的 Security 标签页。三、核心实战一CodeQL —— GitHub 官方原生静态分析CodeQL 是 GitHub 官方出品的语义代码分析引擎其起步工作流位于 codeql.yml文件头部注释明确提示对大多数项目该文件无需修改只需提交到仓库即可运行需要改动时通常是调整被分析的语言集合或提供自定义查询与构建逻辑。3.1 工作流结构name: CodeQL Advanced on: push: branches: [ $default-branch, $protected-branches ] pull_request: branches: [ $default-branch, $protected-branches ] schedule: - cron: $cron-weekly jobs: analyze: name: Analyze (${{ matrix.language }}) runs-on: ${{ (matrix.language swift macos-latest) || ubuntu-latest }} permissions: security-events: write packages: read actions: read contents: read strategy: fail-fast: false matrix: $codeql-languages-matrix几个值得注意的工程细节矩阵扫描工作流通过strategy.matrix对每种语言分别运行一次分析fail-fast: false保证某一种语言失败不会中断其他语言的分析运行器选择Swift 语言强制使用macos-latest其余语言使用ubuntu-latest注释提示考虑更大规格 runner 以缩短分析时间packages 权限packages: read用于拉取内部或私有的 CodeQL packs查询包。3.2 三步核心流程CodeQL 分析由三个标准步骤组成steps: - name: Checkout repository uses: actions/checkoutv4 - name: Initialize CodeQL uses: github/codeql-action/initv4 with: languages: ${{ matrix.language }} build-mode: ${{ matrix.build-mode }} # 可在此处或配置文件中指定自定义查询 # queries: security-extended,security-and-quality - name: Perform CodeQL Analysis uses: github/codeql-action/analyzev4 with: category: /language:${{matrix.language}}init初始化 CodeQL 工具链并确定分析语言。默认查询集之外可追加security-extended扩展安全查询或security-and-quality安全 质量查询analyze执行查询并产出结果category按语言隔离结果分类。3.3 编译型语言的手动构建模式对于 C/C、Java、Kotlin 等编译型语言若 analyze 步骤报错 We were unable to automatically build your code工作流内置了build-mode: manual的兜底路径在矩阵中为该语言设置手动构建模式后执行一个由用户填充构建命令的步骤- name: Run manual build steps if: matrix.build-mode manual shell: bash run: | echo 请替换为构建代码的命令例如 echo make bootstrap echo make release exit 1该步骤默认以exit 1提醒使用者必须填入真实构建命令避免空跑。四、核心实战二按语言选型 —— Bandit 与 ESLint4.1 BanditPython 安全 lintbandit.yml 基于第三方 Actionshundor/python-bandit-scan运行 Bandit——一个专找 Python 常见安全问题的安全 linter扫描结果同样出现在仓库 Security 标签页。其可配置参数非常丰富- name: Bandit Scan uses: shundor/python-bandit-scanab1d87dfccc5a0ffab88be3aaac6ffe35c10d6cd with: # exit with 0, even with results found exit_zero: true GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # path: # 扫描的文件或目录默认 . # level: # 最低报告级别LOW / MEDIUM / HIGH默认 UNDEFINED全部 # confidence: # 最低置信级别LOW / MEDIUM / HIGH默认 UNDEFINED全部 # excluded_paths: # 排除路径glob默认排除 .git、__pycache__、.tox 等 # skips: # 跳过的测试 ID 列表 # ini_path: # 指向提供命令行参数的 .bandit 文件通过level与confidence组合可以方便地实现只关注 HIGH 级别高置信问题的降噪策略。4.2 ESLintJavaScript/TypeScript 静态规则检查eslint.yml 展示了传统 lint 工具 SARIF 格式化 上传的通用接入模式- name: Install ESLint run: | npm install eslint8.10.0 npm install microsoft/eslint-formatter-sarif3.1.0 - name: Run ESLint env: SARIF_ESLINT_IGNORE_SUPPRESSED: true run: npx eslint . --config .eslintrc.js --ext .js,.jsx,.ts,.tsx --format microsoft/eslint-formatter-sarif --output-file eslint-results.sarif continue-on-error: true - name: Upload analysis results to GitHub uses: github/codeql-action/upload-sarifv3 with: sarif_file: eslint-results.sarif wait-for-processing: true关键点ESLint 本身不是安全扫描器但通过microsoft/eslint-formatter-sarif将结果格式化为 SARIF 后就能借助upload-sarif统一汇入 GitHub 的 Code Scanning 面板。continue-on-error: true保证 lint 报错不阻断 CIwait-for-processing: true则让上传步骤等待 GitHub 处理完成。五、核心实战三镜像与基础设施扫描 —— Trivytrivy.yml 是容器镜像漏洞扫描的完整范例流程为构建镜像 → 扫描 → 上传 SARIF- name: Build an image from Dockerfile run: | docker build -t docker.io/my-organization/my-app:${{ github.sha }} . - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-action7b7aa264d83dc58691451798b4d117d53d21edfe with: image-ref: docker.io/my-organization/my-app:${{ github.sha }} format: template template: /contrib/sarif.tpl output: trivy-results.sarif severity: CRITICAL,HIGH - name: Upload Trivy scan results to GitHub Security tab uses: github/codeql-action/upload-sarifv3 with: sarif_file: trivy-results.sarif这里image-ref复用前面构建的镜像 tag${{ github.sha }}保证唯一性severity: CRITICAL,HIGH过滤出高危及以上问题format: template配合/contrib/sarif.tpl把扫描结果转成 SARIF。这也是容器类扫描的通用范式Dockerfile → 构建 → 扫描 → 上传。六、核心实战四依赖与供应链安全6.1 OSV-Scanner开源漏洞数据库扫描osv-scanner.yml 展示了一个复用型工作流 双场景分流的精巧设计它通过google/osv-scanner-action提供的 reusable workflow 同时处理两类任务jobs: scan-scheduled: if: ${{ github.event_name push || github.event_name schedule }} uses: google/osv-scanner-action/.github/workflows/osv-scanner-reusable.yml1f1242919d8a60496dd1874b24b62b2370ed4c78 # v1.7.1 with: scan-args: |- -r --skip-git ./ scan-pr: if: ${{ github.event_name pull_request || github.event_name merge_group }} uses: google/osv-scanner-action/.github/workflows/osv-scanner-reusable-pr.yml1f1242919d8a60496dd1874b24b62b2370ed4c78 # v1.7.1 with: scan-args: |- -r --skip-git ./定时/推送扫描全量扫描仓库-r递归、--skip-git跳过 git 内部文件PR/merge_group 扫描使用专用的 PR 复用工作流只检查本次变更是否引入新漏洞实现增量拦截。6.2 Dependency ReviewPR 合并前的依赖闸门dependency-review.yml 针对 PR 中变更的依赖清单文件manifest进行审查当 PR 引入已知漏洞版本时可作为 required check 阻止合并- name: Dependency Review uses: actions/dependency-review-actionv4 with: comment-summary-in-pr: always # fail-on-severity: moderate # deny-licenses: GPL-1.0-or-later, LGPL-2.0-or-later # retry-on-snapshot-warnings: true常用增强选项包括fail-on-severity按严重级别失败、deny-licenses拒绝特定许可证实现许可证合规门禁、retry-on-snapshot-warnings。注意其权限要求若同时使用依赖提交Dependency SubmissionAPIcontents权限需提升为write。6.3 Scorecard供应链安全评分scorecard.yml 集成 OpenSSF Scorecard为仓库的供应链安全实践打分。它的触发方式极具特色——专门监听branch_protection_rule事件分支保护变更以保证 Branch-Protection 检查的实时性同时辅以每周定时任务维持 Maintained 检查的更新on: branch_protection_rule: schedule: - cron: $cron-weekly push: branches: [ $default-branch ]核心步骤- name: Run analysis uses: ossf/scorecard-actionf49aabe0b5af0936a0987cfb85d86b75731b0186 # v2.4.1 with: results_file: results.sarif results_format: sarif # repo_token: ${{ secrets.SCORECARD_TOKEN }} # 私有仓库/公开仓库启用 Branch-Protection 检查时按需配置 publish_results: true # 仅默认分支运行私有仓库恒为 false随后通过actions/upload-artifact将 SARIF 作为构建产物留存retention-days: 5并可选上传到 code-scanning 面板。若要在私有仓库启用 Branch-Protection 检查需要配置 fine-grained PAT 形式的repo_token。七、综合平台接入 —— Semgrep 与 Snyk7.1 Semgrep规则可管理的 SAST 平台semgrep.yml 需要先在 Semgrep.dev 注册免费账户以管理规则、文件忽略与通知- uses: returntocorp/semgrep-actionfcd5ab7459e8d91cb1777481980d1b18b4fc6735 with: publishToken: ${{ secrets.SEMGREP_APP_TOKEN }} publishDeployment: ${{ secrets.SEMGREP_DEPLOYMENT_ID }} generateSarif: 1 - name: Upload SARIF file uses: github/codeql-action/upload-sarifv3 with: sarif_file: semgrep.sarif if: always()generateSarif: 1指示 Action 生成 SARIF 文件上传步骤加if: always()确保即使扫描发现问题也照常上传。7.2 Snyk全平台四合一扫描snyk-security.yml 是覆盖面最广的范例一次工作流同时调用 Snyk Open SourceSCA、Snyk CodeSAST、Snyk Container 与 Snyk IaC 四个引擎- name: Set up Snyk CLI uses: snyk/actions/setup806182742461562b67788a64410098c9d9b96adb env: SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }} - name: Snyk Code test run: snyk code test --sarif snyk-code.sarif # 追加 || true 可避免阻断流水线 - name: Snyk Open Source monitor run: snyk monitor --all-projects - name: Snyk IaC test and report run: snyk iac test --report - name: Build a Docker image run: docker build -t your/image-to-test . - name: Snyk Container monitor run: snyk container monitor your/image-to-test --fileDockerfile - name: Upload result to GitHub Code Scanning uses: github/codeql-action/upload-sarifv3 with: sarif_file: snyk-code.sarif要点snyk code test --sarif将 SAST 结果输出为 SARIF 文件最后一步上传到 GitHub Code Scanningsnyk monitor将依赖与镜像结果上报到 Snyk 平台侧持续跟踪使用 Snyk Open Source 前需先配置好开发环境如actions/setup-node。八、贯通全目录一次看懂仓库的扫描器全景code-scanning/目录中每个.yml与其同名.properties.json一一对应后者为工作流提供面向 UI 的元信息名称、创建者、描述、语言分类。从目录清单可以梳理出四大接入范式范式一GitHub 原生三步式—— CodeQL 的checkout → init → analyze以及任何工具产出的 SARIF 文件最终都经由github/codeql-action/upload-sarifv3统一上传这是全目录最通用的收尾步骤见 codeql.yml、trivy.yml、eslint.yml、semgrep.yml 等。范式二独立 CLI SARIF 上传—— 工具以 CLI/命令方式运行手动将结果转成 SARIF 再上传代表有 ESLint、Snyk Code。范式三可复用工作流reusable workflow—— 通过uses: owner/repo/.github/workflows/*.ymlref直接调用上游定义好的扫描流程代表有 OSV-Scannerosv-scanner.yml。范式四平台托管 Action—— 通过第三方 Action 封装完整扫描逻辑配合with:参数化配置代表有 Banditbandit.yml、Semgrep、Scorecardscorecard.yml。其余工作流如 anchore、checkmarx、sonarqube、veracode、fortify、trivy、tfsec、kubesec、osv-scanner、dependency-review 等均可在 code-scanning 目录中直接查阅覆盖语言静态分析、容器、IaC、供应链等全部扫描维度。九、落地建议与踩坑提醒综合以上工作流源码给出几条可直接照搬的实践建议先提交再调参如 codeql.yml 头部注释所言大多数工作流直接提交即可运行提交后务必核对矩阵中的语言集合与仓库实际语言一致。权限最小化统一采用contents: readsecurity-events: write私有仓库actions: read的权限组合仅在确有必要时放宽如 Dependency Review 的pull-requests: write、Dependency Submission 场景的contents: write。SARIF 是通用语言无论扫描器来自哪家最终都以 SARIF 上传到 GitHub Security 标签页因此第三方工具 upload-sarif是最可复用的集成路径。定时扫描别省schedule事件是捕获依赖更新后新暴露漏洞的关键建议保留每周一次的$cron-weekly频率。避免空跑与误伤手动构建模式的占位步骤以exit 1强制填写需要降噪时通过severity、level/confidence、fail-on-severity等参数收紧关注范围或按需追加|| true避免扫描失败阻断发布流水线。最后提醒本仓库的code-scanning/目录是起步模板集实际接入时请以你的仓库语言、依赖形态与合规要求为准进行裁剪扫描结果始终以仓库 Security 标签页展示的 SARIF 报告为最终依据。赞分享示例工程CI/CDDevOps【免费下载链接】starter-workflowsAccelerating new GitHub Actions workflows项目地址https://gitcode.com/GitHub_Trending/st/starter-workflows点击查看免费下载相关推荐kkFileView浏览器里直开 XMind 思维导图免装软件kkFileView浏览器里直开 XMind 思维导图免装软件 周一早上同事在群里甩了个 .xmind 文件让你看方案你盯着手机屏幕——打不开。装个 X后端modern-screenshot疑难杂症排查常见问题与解决方案大全modern screenshot疑难杂症排查常见问题与解决方案大全 modern screenshot是一款基于HTML5 canvas和SVG技术的DOM前端图像处理GPT-OSS-120B在vLLM和Ollama中的部署对比选择最适合你的推理框架GPT OSS 120B在vLLM和Ollama中的部署对比选择最适合你的推理框架 GPT OSS 120B是OpenAI推出的开源大模型具备强大的推理能力人工智能大模型上一篇探索Before After一款强大的Flutter图像对比工具下一篇【免费下载】 Termux API 包使用教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考