How to contribute

This section covers how to work productively in the Grype codebase: the development loop, conventions, testing, debugging, and tooling.

The canonical contributor docs live under https://oss.anchore.com/docs/contributing/grype/; this wiki focuses on the things that are visible in this repository rather than rephrasing the public docs.

Quick links

• Development workflow — branch, code, test, PR.
• Testing — unit, integration, CLI, quality gates.
• Debugging — logs, profiling, common failure modes.
• Patterns and conventions — coding style, error handling, configuration patterns.
• Tooling — Taskfile, binny, golangci-lint, goreleaser.

Where to look first

If you want to ...	Start here
Add a new package matcher	Matcher system and grype/matcher/<existing>/ for a template
Add a new output format	Presenters and grype/presenter/<existing>/
Touch the vulnerability DB	Vulnerability database and grype/db/v6/
Add a new CLI subcommand	CLI app and cmd/grype/cli/commands/
Add a new VEX format	VEX processing and grype/vex/<existing>/

PR expectations

From CONTRIBUTING.md:

• All commits must be signed off (DCO). The contribution guide enforces this.
• Open an issue for non-trivial features before coding.
• Security issues go through the security policy, not public issues.
• The validations.yaml GitHub workflow runs unit, integration, and CLI tests; PRs must pass it.

Definition of done

A change is considered done when:

1. task validate passes locally (lint + tests + install-test).
2. The change is covered by at least one test (unit or integration). Coverage gate is 47% as defined in Taskfile.yaml::unit.
3. Affected presenters and JSON schemas are regenerated (task generate) and committed.
4. The DB schema, if changed, has a corresponding Addition or Revision bump in grype/db/v6/db.go and a migration plan documented in the PR.
5. The PR title and description follow the conventional commit style — release.yaml parses these for changelog generation.