If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/analysis-tools-dev/static-analysis shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit today
• 23+ active contributors
• Distributed ownership (top contributor 31% of recent commits)
• MIT licensed
• CI configured
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live analysis-tools-dev/static-analysis repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/analysis-tools-dev/static-analysis.

What it runs against: a local clone of analysis-tools-dev/static-analysis — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in analysis-tools-dev/static-analysis | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of analysis-tools-dev/static-analysis. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/analysis-tools-dev/static-analysis.git
#   cd static-analysis
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of analysis-tools-dev/static-analysis and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "analysis-tools-dev/static-analysis(\\.git)?\\b" \\
  && ok "origin remote is analysis-tools-dev/static-analysis" \\
  || miss "origin remote is not analysis-tools-dev/static-analysis (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "data/tools.yml" \\
  && ok "data/tools.yml" \\
  || miss "missing critical file: data/tools.yml"
test -f "ci/render/src/lib.rs" \\
  && ok "ci/render/src/lib.rs" \\
  || miss "missing critical file: ci/render/src/lib.rs"
test -f "ci/render/src/types.rs" \\
  && ok "ci/render/src/types.rs" \\
  || miss "missing critical file: ci/render/src/types.rs"
test -f "ci/pr-check/src/main.rs" \\
  && ok "ci/pr-check/src/main.rs" \\
  || miss "missing critical file: ci/pr-check/src/main.rs"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/analysis-tools-dev/static-analysis"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A curated registry and documentation hub for static analysis tools (SAST, linters, formatters) across all programming languages, maintained as a YAML source (data/tools.yml) that renders into a searchable website via Rust-based CI pipelines. The core capability is aggregating tool metadata (name, languages, features, licensing) and auto-generating the HTML/API output at analysis-tools.dev through templated rendering. Monorepo with two Rust workspaces under ci/: (1) render/ contains the template engine (Askama in src/lib.rs and src/bin/main.rs) that transforms data/tools.yml into README markdown and API JSON, outputting to data/api/; (2) pr-check/ validates PRs and generates bot comments using templates/comment.md. The data/ folder holds the canonical YAML source and generated outputs; Makefile orchestrates CI steps.

Security engineers, tech leads, and DevOps teams evaluating which static analysis tools to integrate into CI/CD pipelines; open-source maintainers seeking comprehensive recommendations for their language ecosystem; and tool vendors who want their projects listed in a trusted, community-curated registry.

Production-ready with solid CI/CD infrastructure: the repo has comprehensive GitHub Actions workflows (links.yml, pr-check.yml, render.yml, stats.yml, auto-merge.yml), a Rust-based build system with workspace dependencies, and strict PR validation. Actively maintained with issue templates for tool suggestions and a PR comment bot, though the last activity snapshot isn't provided—check commit graph to confirm recent updates.

Low risk overall: the codebase is primarily data-driven (YAML source) rather than complex logic, reducing maintenance burden. Main risks are (1) reliance on external tool repos for links validation (links.yml workflow), (2) single source of truth in data/tools.yml means one bad edit can break rendering, and (3) dependency on Rust ecosystem (Askama templates, serde_yaml, tokio) requires Rust toolchain stability. No evident single-maintainer bottleneck given the issue template automation.

Active maintenance with PR automation and link validation: the .github/workflows/ includes auto-merge.yml (likely auto-merging dependabot PRs), links.yml (validating tool URLs), and pr-check.yml (blocking bad PRs). The copilot-instructions.md and .windsurfrules suggest AI assistant integration for contributor guidance. The stats.yml workflow generates analytics into data/api/stats/.

git clone https://github.com/analysis-tools-dev/static-analysis.git
cd static-analysis
rustup update  # ensure Rust toolchain
cd ci/render && cargo build --release
cd ../.. && make  # or run ./ci/render/target/release/main to render README

Daily commands:

cd ci/render
cargo run --release -- --input ../../data/tools.yml --output ../../README.md
# or via Makefile: make render

The render binary reads data/tools.yml and outputs to README.md and data/api/. Check Makefile for the full invocation syntax.

• data/tools.yml — Master data file containing all static analysis tool definitions; every contributor must understand its schema and conventions since the README warns it's the source of truth
• ci/render/src/lib.rs — Core rendering engine that transforms tool YAML data into README and API outputs; understanding this is essential for any tooling or data pipeline changes
• ci/render/src/types.rs — Defines the canonical data structures (Tool, Tag, etc.) that all tooling depends on; any schema changes propagate through the entire system
• ci/pr-check/src/main.rs — Validates PR submissions against tool data requirements; contributors must know what checks will run on their contributions
• .github/workflows/ci.yml — Primary CI pipeline orchestrating render, validation, and deployment; shows how data flows from YAML to published website and API
• CONTRIBUTING.md — Establishes submission guidelines and processes for adding or modifying tools in the curated list
• data/tags.yml — Taxonomy of tool categories and tags used for organization and filtering; must be consistent with tool YAML definitions

Add a New Static Analysis Tool

1. Create a new YAML file in data/tools/ with the tool name (e.g., data/tools/mytool.yml) (data/tools/mytool.yml)
2. Define required fields: name, url, languages, tags, pricing (matching schema in ci/render/src/types.rs) (data/tools/mytool.yml)
3. Ensure all tags used exist in data/tags.yml; add new tags if needed with description (data/tags.yml)
4. Submit PR; ci/pr-check will validate YAML syntax and required fields (.github/workflows/pr-check.yml)
5. On merge, ci/render workflow auto-regenerates README.md and data/api/tools.json (.github/workflows/render.yml)

Extend Tool Classification (Add New Tags/Categories)

1. Edit data/tags.yml and add a new tag with name, description, and category (data/tags.yml)
2. Update tool YAML files in data/tools/ to use the new tag where applicable (data/tools)
3. The render workflow will regenerate README and stats automatically on merge (.github/workflows/render.yml)

Customize Tool Rendering (Update README Template)

1. Edit the Askama template to change how tools are formatted in README (ci/render/templates/README.md)
2. Update rendering logic if adding new tool fields in ci/render/src/lib.rs (ci/render/src/lib.rs)
3. Update type definitions if adding new tool properties in ci/render/src/types.rs (ci/render/src/types.rs)
4. Manually trigger or wait for next render workflow to regenerate README.md (.github/workflows/render.yml)

• Rust (Tokio, Askama, serde_yaml) — Compiled binaries for fast CI/CD validation and rendering; serde_yaml enables strongly-typed YAML deserialization with schema validation
• YAML for data (tools.yml, tags.yml, individual tool files) — Human-readable format suitable for community contributions; easy to version control and diff; supports nested structure for tool metadata
• GitHub Actions workflows (render.yml, pr-check.yml, ci.yml) — Native GitHub integration for automated data validation, generation, and deployment without external services
• Askama templating — Compile-time template validation and efficient markdown generation from structured tool data
• JSON API outputs (data/api/) — Static JSON files enable website (analysis-tools.dev) and third-party tools to consume tool metadata via HTTP without backend

• README.md is generated, not manually edited (per header notice)

  • Why: Ensures single source of truth in data/tools.yml; prevents manual edits being overwritten
  • Consequence: Contributors must edit YAML instead of README; requires automation but eliminates merge conflicts

• Validation (pr-check) runs on every PR before merge

  • Why: Catches schema violations and inconsistencies early; maintains data quality
  • Consequence: Adds CI latency (~1–2min); prevents broken contributions but requires PR author involvement to fix errors

• Static JSON API instead of dynamic backend

  • Why: No server cost; scales to unlimited users; simple to cache and distribute via CDN
  • Consequence: Cannot serve real-time data; rendering happens offline on merge; stats.json must be pre-computed

• Individual YAML files per tool (data/tools/*.yml) vs. single monolithic file

  • Why: Enables granular Git history, easier conflict resolution, and parallel community contributions
  • Consequence: Slightly higher merge complexity; render process must aggregate hundreds of files

• Does not provide a dynamic backend API or serve real-time requests (uses static JSON)
• Does not execute or sandbox tools; only catalogs metadata about them
• Does not implement authentication or per-user data; purely public curated list
• Does not track tool versions or historical changes (focuses on current state)
• Does not host or mirror tool binaries; links to official vendor pages only

No hard env vars required, but check: (1) The render binary expects data/tools.yml to exist and be valid YAML—a malformed entry will fail the whole build silently; (2) links.yml workflow makes external HTTP requests to validate tool URLs, so it may rate-limit or timeout if the tool list grows large; (3) Askama template compilation is strict—whitespace and syntax errors in templates/README.md cause cryptic compile failures; (4) The Cargo.lock files are committed, so cargo update will fail CI—use cargo update --locked or bump versions explicitly in Cargo.toml.

• mre/awesome-dynamic-analysis — Sister project mentioned in README—curates dynamic analysis and testing tools, complementing this SAST registry; useful for users needing runtime analysis alongside static checks.
• caramelomartins/awesome-linters — Alternative curated linter/tool list with different organization; helpful for cross-referencing tools and seeing how other communities structure tool registries.
• dwyl/security-as-code — Ecosystem companion that lists security tools and compliance automation; users of this repo often integrate tools into security-as-code pipelines.
• analysis-tools-dev/assets — Holds static assets (images, sponsor logos, redesign SVG) referenced in README and website; required for rendering the full docs locally with images.
• github/super-linter — Orchestrates multiple linters in one container; many users discover this repo while evaluating tools mentioned in the super-linter documentation.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add validation tests for data/tools/*.yml schema consistency

The repo contains 100+ tool definition files in data/tools/ but there's no visible test suite validating that each YAML file conforms to the expected schema. The pr-check binary in ci/pr-check/src/main.rs likely does some validation, but it should have accompanying unit tests. This would catch malformed tool entries before merge and make contributions more reliable.

• [ ] Create ci/pr-check/tests/schema_validation_test.rs to test YAML parsing against ci/pr-check/src/types.rs structs
• [ ] Add test cases for missing required fields (name, description, etc.) and invalid data types
• [ ] Document the expected tool YAML schema in data/README.md with examples
• [ ] Integrate the tests into ci/pr-check Cargo.toml and verify they run in the existing CI workflows

Add GitHub Action workflow to validate tool data freshness and detect orphaned entries

The repo has a links.yml workflow for checking broken URLs, but no workflow that validates tool metadata integrity (e.g., detecting tools with invalid/unreachable repo URLs, missing required fields at scale, or duplicate tool entries). This would catch data quality issues early.

• [ ] Create .github/workflows/data-validation.yml that runs the pr-check binary with strict validation flags
• [ ] Extend ci/pr-check/src/main.rs to add checks for: duplicate tool names, unreachable repository URLs, and missing required fields across all data/tools/*.yml files
• [ ] Configure the workflow to comment on PRs with specific validation errors (similar to pr-comment.yml pattern)
• [ ] Document the validation rules in CONTRIBUTING.md

Add integration tests for ci/render output generation and templating

The ci/render binary generates the README.md and API responses from tool data using askama templates (ci/render/templates/), but there are no tests verifying that the rendered output is correct or that template changes don't break the generated files. This is critical since rendering errors would affect the public website.

• [ ] Create ci/render/tests/render_integration_test.rs that runs the render binary with sample data/tools/*.yml entries
• [ ] Test that: (1) README.md is generated with correct tool counts, (2) API JSON files (data/api/tools.json, data/api/tags.json) are valid JSON, (3) tool descriptions are properly escaped in output
• [ ] Add a fixture with 3-5 sample tool entries in ci/render/tests/fixtures/ to make tests reproducible
• [ ] Integrate tests into the existing CI pipeline to run on every PR that modifies templates or tool data

• Add validation in ci/pr-check/src/main.rs to check that all URLs in new tool entries are valid HTTPS (not http://) and follow the repo's URL format guidelines; this requires adding a regex check to the PR validation logic.
• Expand ci/render/src/stats.rs to compute and export per-language tool counts and most-active tool categories to data/api/stats/ as JSON; this surfaces usage patterns without changing the core rendering pipeline.
• Write integration tests in ci/render/tests/ that verify a sample tools.yml renders to expected Markdown sections and that all language groups appear in the table of contents; currently there's no test coverage visible.

This is a curated metadata repository with low inherent security risk. The codebase consists primarily of YAML configuration files and Rust CI tools. No critical vulnerabilities detected. Main concerns are around template rendering with external data and ensuring branch protection rules are properly configured for the auto-merge workflow. Dependencies are relatively recent and well-maintained. The project would benefit from input validation on YAML data sources and comprehensive security review of the Rust code in ci/pr-check and ci/render directories.

• Low · Outdated Tokio Dependency — ci/Cargo.toml (workspace.dependencies). The workspace dependency 'tokio' is pinned to version 1.x without upper bound constraints. While tokio 1.x is generally stable, this pattern could miss important security patches if minor version vulnerabilities are discovered. Fix: Monitor tokio releases for security updates and consider using a more recent stable version. Consider specifying a more conservative version constraint like '1.40' or higher once LTS stability is confirmed.
• Low · Potential XSS Risk in Template Rendering — ci/render/src/lib.rs, ci/render/templates/. The codebase uses Askama templates (ci/render/templates/) for generating markdown output. If user-controlled data from YAML files (data/tools/*.yml) is rendered without proper escaping, it could introduce XSS vulnerabilities in the generated content. Fix: Ensure all dynamic content from YAML files is properly escaped before template rendering. Verify that Askama's auto-escaping is enabled and validate YAML content for malicious payloads.
• Low · Dependency on External URL Validation — .github/workflows/links.yml, data/tools/*.yml. The GitHub workflow '.github/workflows/links.yml' performs URL validation on external links referenced in markdown and YAML files. Malicious or broken URLs could be injected into data files. Fix: Implement URL validation and sanitization in the CI/PR check pipeline. Add content security policy validation for generated artifacts.
• Low · Public Repository with Auto-Merge Enabled — .github/workflows/auto-merge.yml. The repository has auto-merge workflow configured (.github/workflows/auto-merge.yml) which could potentially merge untrusted contributions without sufficient review if branch protection rules are misconfigured. Fix: Verify that branch protection rules require at least one approval from code owners before auto-merge is triggered. Ensure automated checks must pass before merging.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.