Open-source tooling

Tools by category

Within each category, tools are listed by GitHub stars. Stars measure popularity, not quality, so read them next to the rating. Tools that also cover a category without being built for it are listed under it as "Also covers this".

All tools

Sorted by GitHub stars by default. The rating is ghtier's own (see how the ratings work). Scorecard is the tool's own repository scored by OpenSSF Scorecard in its weekly public scan, out of 10. It measures how the project protects itself (branch protection, pinned dependencies, signed releases, token permissions), not how good its findings are. 11 of 18 repositories are in the scan.

Putting it together: a PR security job

No single tool covers a pull request. This is one way to combine them in a single job, cheapest checks first. It is modelled on a production workflow that runs every scanner, posts one summary comment on the PR, and then fails in a final gate step.

A trimmed version of the job. Every scanner step uses continue-on-error, so its outcome records the result while the job keeps going, and the last step decides. Tools are installed at fixed versions, and downloaded binaries are checked against the release's checksum file.

name: Security (PR)

on:
  pull_request:

permissions:
  contents: read

concurrency:
  group: security-pr-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<sha> # v7.0.1
        with:
          fetch-depth: 0              # gitleaks needs the PR's commits, not just the tip
          persist-credentials: false

      - name: Install scanners at pinned versions
        env:
          OSV_VERSION: "2.6.0"
          OSV_SHA256: "<sha256 of osv-scanner_linux_amd64 from the release's SHA256SUMS>"
          GITLEAKS_VERSION: "8.30.1"
          GITLEAKS_SHA256: "<sha256 of the linux_x64 tarball from the release's checksums.txt>"
        run: |
          set -euo pipefail
          pip install --user "zizmor==1.30.1" "semgrep==1.180.0"
          curl -sSLo osv-scanner "https://github.com/google/osv-scanner/releases/download/v${OSV_VERSION}/osv-scanner_linux_amd64"
          echo "${OSV_SHA256}  osv-scanner" | sha256sum -c -
          curl -sSLo gitleaks.tgz "https://github.com/gitleaks/gitleaks/releases/download/v${GITLEAKS_VERSION}/gitleaks_${GITLEAKS_VERSION}_linux_x64.tar.gz"
          echo "${GITLEAKS_SHA256}  gitleaks.tgz" | sha256sum -c -
          tar -xzf gitleaks.tgz gitleaks
          sudo install -m755 osv-scanner gitleaks /usr/local/bin/

      # Nothing is installed from the project: every scanner reads the lockfile or the source.

      - name: npm audit
        id: audit
        continue-on-error: true
        run: npm audit --package-lock-only --audit-level=high

      - name: OSV-Scanner
        id: osv
        continue-on-error: true
        run: osv-scanner scan -L package-lock.json

      - name: zizmor
        id: zizmor
        continue-on-error: true
        run: zizmor --no-online-audits --format plain .

      - name: Semgrep
        id: semgrep
        continue-on-error: true
        run: semgrep scan --config p/ci --metrics off --error .

      - name: Gitleaks
        id: gitleaks
        continue-on-error: true
        env:
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
        run: gitleaks detect --source . --redact --log-opts="${BASE_SHA}..HEAD"

      - name: Security gate
        if: ${{ !cancelled() }}
        env:
          OUTCOMES: >-
            audit=${{ steps.audit.outcome }}
            osv=${{ steps.osv.outcome }}
            zizmor=${{ steps.zizmor.outcome }}
            semgrep=${{ steps.semgrep.outcome }}
            gitleaks=${{ steps.gitleaks.outcome }}
        run: |
          printf '%s\n' $OUTCOMES
          case " $OUTCOMES " in *=failure*) exit 1 ;; esac

Fork PRs get a read-only token and no secrets, so steps that need an API key (Socket) or write access (the PR comment) should skip cleanly instead of failing. The GitHub Actions page covers why pull_request is the right trigger here and pull_request_target is not.

How the ratings work

The rating is an editorial judgement of how useful a tool is for its job today: accuracy, maintenance, how easy it is to run in CI, and how much works without a paid account. It is relative to the tool's category. A 4 for a niche linter and a 4 for a vulnerability scanner are not the same thing.

• Rated 5 of 5, Top pickTop pickTop pick: The default choice for its job. Accurate, actively maintained, easy to run in CI, fully usable without a paid account.
• Rated 4 of 5, RecommendedRecommendedRecommended: Worth running, with a real trade-off: more noise, narrower scope, heavier setup, or the best parts need an account.
• Rated 3 of 5, SituationalSituationalSituational: Good for a specific need or as a second opinion. Smaller project or slower maintenance.
• Rated 2 of 5, NicheNicheNiche: Mostly superseded or very narrow. Use it only if you have a specific reason.
• Rated 1 of 5, LegacyLegacyLegacy: Archived or deprecated. Listed for reference. Plan a migration if you still run it.

Stars, licenses, last release and Scorecard scores are fetched from the GitHub API and the OpenSSF Scorecard API, not written by hand. They were last refreshed on 10 October 2026. Licenses are GitHub's detection of the repository license. Where a hosted service does the main work, the table says so under the license.