Open the source and read safety notes before installing.
Citation facts
Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.
- Canonical URL
- https://heyclau.de/entry/tools/garak
- Source URLs
- https://github.com/NVIDIA/garak
- Brand
- Garak
- Brand domain
- github.com
- Author
- NVIDIA
- Claim status
- unclaimed
- Last verified
- 2026-04-27
Schema details
- Install type
- copy
- Troubleshooting
- No
- Scope
- Source repo
- Pricing
- open-source
- Disclosure
- editorial
- Application category
- SecurityApplication
- Operating system
- macOS, Windows, Linux
Full copyable content
## Editorial notes
Garak is useful for security teams that need repeatable checks for model, prompt, and application-level LLM risks.
## Disclosure
Editorial listing. No paid placement or affiliate link is used.About this resource
Editorial notes
Garak is useful for security teams that need repeatable checks for model, prompt, and application-level LLM risks.
Disclosure
Editorial listing. No paid placement or affiliate link is used.
Source citations
Add this badge to your README
How it compares
Garak side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
| Field | Open-source LLM vulnerability scanner for probing model behavior, prompt attack surfaces, and safety failures. Open dossier | AI testing platform for evaluating, scanning, and monitoring machine learning and LLM application quality. Open dossier | Apache-2.0 vulnerability scanner from Anchore for container images, filesystems, archives, SBOMs, PURLs, and CPEs, with risk scoring, VEX filtering, and CI-friendly output. Open dossier | Open-source prompt testing and red-teaming framework for LLM outputs, regressions, evaluations, and security checks. Open dossier |
|---|---|---|---|---|
| Trust | ||||
| Install risk | Review first | Review first | Review first | Review first |
| Notes | Safety · Privacy · | Safety · Privacy · | Safety ✓ Privacy ✓ | Safety · Privacy ✓ |
| Brand | — | |||
| Category | tools | tools | tools | tools |
| Source | source-backed | source-backed | source-backed | source-backed |
| Author | NVIDIA | Giskard | Anchore | Promptfoo |
| Added | 2026-04-27 | 2026-04-27 | 2026-06-04 | 2026-04-27 |
| Platforms | CLI | CLI | CLI | CLI |
| Source repo | — | — | — | — |
| Safety notes | — missing | — missing | ✓Grype parses container images, archives, filesystems, SBOMs, package identifiers, and vulnerability data; run it from trusted automation with bounded filesystem access and resource limits for untrusted targets. The install script and binary update paths should be verified before use in production CI; pin versions and checksums where reproducible builds or regulated environments require it. Scanning private images can use registry credentials, client certificates, tokens, Docker or Podman daemon access, and local image metadata, so CI jobs should scope credentials and avoid broad registry permissions. Vulnerability findings are advisory and depend on package detection, vulnerability database freshness, distro context, CPE matching, fix-state metadata, EPSS, KEV, and risk-scoring inputs; high-impact findings still need human triage. Fail-on thresholds, only-fixed filters, only-notfixed filters, ignore rules, VEX documents, and suppressed-result settings can change pipeline outcomes, so policy changes should be reviewed like security code. The configuration reference includes options for insecure registry TLS behavior and HTTP registry access; these should be avoided outside tightly controlled test environments. Automatic database updates and application update checks make outbound network requests unless disabled or pinned by policy. Large images, archives, monorepos, or SBOMs can produce expensive scans and large JSON/SARIF artifacts; set timeouts, artifact limits, cache policy, and retention rules in CI. | — missing |
| Privacy notes | — missing | — missing | ✓The Grype getting-started docs say Grype runs locally and does not send scan data to external services; it needs internet access for downloading container images and the vulnerability database. Pulling images from remote or private registries can disclose image names, tags, digests, registry hostnames, platform requests, authentication attempts, and network metadata to registry infrastructure. Scan output can reveal package names, package versions, ecosystems, distro names, image identifiers, file metadata, file digests, executable metadata, vulnerability identifiers, fix versions, EPSS, KEV, risk scores, and suppressed findings. JSON, SARIF, CycloneDX, and template outputs are useful for automation but can leak dependency inventory and security posture when uploaded to CI logs, code scanning tools, tickets, dashboards, or long-retention artifacts. Configuration files and environment variables can include registry usernames, passwords, tokens, client certificates, client keys, CA certificates, cache paths, update URLs, ignore rules, VEX documents, and output paths. SBOM inputs may contain full dependency inventories and build metadata; treat Grype reports and source SBOMs as security-sensitive artifacts. | ✓Promptfoo sends your prompts and test inputs to the model providers you configure to run evals and red-team probes; review which providers are used and keep secrets out of test cases. |
| Prerequisites | — none listed | — none listed |
| — none listed |
| Install | — | — | — | — |
| Config | — | — | — | — |
| Citations | ||||
| Claim | Unclaimed | Unclaimed | Unclaimed | Unclaimed |
Related guides
Source-backed guides for putting this to work.
Auditing MCP Client Configuration Before Team Rollout
Audit MCP client configuration before sharing it with a team.
Featured in
Signals
Loading live community signals…
A short, calm digest of reviewed Claude resources. Unsubscribe any time.