mirror of
https://github.com/securego/gosec.git
synced 2026-06-20 00:15:59 +02:00
Add some skills for claude code to automate some tasks (#1609)
Signed-off-by: Cosmin Cojocar <cosmin@cojocar.ch>
This commit is contained in:
Cosmin Cojocar
@@ -0,0 +1,42 @@
|
||||
# Create a new gosec rule from issue description
|
||||
|
||||
Use this command to design and implement a new gosec rule based on a Go security issue report.
|
||||
|
||||
## Required input
|
||||
|
||||
Provide the issue description using this structure:
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## Execution workflow
|
||||
|
||||
1. Analyze the current source code of gosec, with emphasis on existing analyzers (SSA and taint) and current rules.
|
||||
2. Think deeply and propose the best implementation approach for this issue.
|
||||
3. Prefer an SSA-based analyzer over an AST-based rule when feasible.
|
||||
4. Assess whether this issue is still relevant for supported Go versions (Go 1.25 and Go 1.26).
|
||||
5. Propose a candidate rule ID and stop. Ask for confirmation before implementation.
|
||||
|
||||
After confirmation, implement end-to-end:
|
||||
|
||||
1. Implement the analyzer or rule with idiomatic Go and maintainable structure.
|
||||
2. Optimize for performance (avoid unnecessary repeated AST or SSA traversals).
|
||||
3. Select an appropriate CWE aligned with current repository mappings.
|
||||
4. Integrate the rule in all required registration points.
|
||||
5. Add sample file(s) in testutils following existing conventions:
|
||||
- At least 2 positive samples (issue must trigger)
|
||||
- At least 2 negative samples (issue must not trigger)
|
||||
6. Update rule documentation in README.md in the same style as other rules.
|
||||
7. Validate the change:
|
||||
- Build succeeds
|
||||
- Relevant tests pass
|
||||
- golangci-lint is clean for new code
|
||||
- Rule works against a sample file with the gosec CLI
|
||||
|
||||
## Output requirements
|
||||
|
||||
- First response must only contain:
|
||||
- Proposed rule ID
|
||||
- Approach recommendation (SSA / taint / AST with rationale)
|
||||
- Relevance assessment for Go 1.25 and 1.26
|
||||
- A request for user confirmation
|
||||
- Do not start implementation until confirmation is provided.
|
||||
@@ -0,0 +1,37 @@
|
||||
# Fix a gosec bug from a GitHub issue
|
||||
|
||||
Use this command to fix a bug described in a GitHub issue.
|
||||
|
||||
## Required input
|
||||
|
||||
Provide the GitHub issue URL (and optionally gosec version, Go version, OS/environment, extra notes):
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## Execution workflow
|
||||
|
||||
1. Review the GitHub issue thoroughly and extract the problem statement, reproduction hints, expected behavior, and actual behavior.
|
||||
2. Try to reproduce the issue against the current `master` version of gosec.
|
||||
3. Analyze the codebase and isolate the root cause.
|
||||
4. Produce a detailed, minimal fix plan and stop. Ask for confirmation before changing code.
|
||||
|
||||
After confirmation, implement end-to-end:
|
||||
|
||||
1. Keep the fix small and isolated to the issue scope.
|
||||
2. Follow good design principles and idiomatic Go.
|
||||
3. Add tests for both positive and negative cases.
|
||||
4. When a code sample is appropriate, add or update a sample in `testutils/` in the relevant rule sample file.
|
||||
5. Validate the result:
|
||||
- Build succeeds
|
||||
- Relevant tests pass
|
||||
- `golangci-lint` has no warnings in changed code
|
||||
- `gosec` CLI run on a sample confirms the issue is fixed
|
||||
|
||||
## Output requirements
|
||||
|
||||
- First response must only contain:
|
||||
- Reproduction status on `master` (or clear blocker)
|
||||
- Root cause analysis
|
||||
- Detailed fix plan
|
||||
- Confirmation request
|
||||
- Do not implement any code changes until confirmation is provided.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Update gosec version in GitHub Action metadata
|
||||
|
||||
Use this command to update the gosec version used by this repository's GitHub Action.
|
||||
|
||||
## Required input
|
||||
|
||||
Provide the gosec version (e.g. 2.24.1):
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## Execution workflow
|
||||
|
||||
1. Read `action.yml`.
|
||||
2. Locate `runs.image` with format `docker://ghcr.io/securego/gosec:<version>`.
|
||||
3. Replace only the version segment after the colon with the provided gosec version.
|
||||
4. Do not change unrelated fields or formatting in `action.yml`.
|
||||
5. Validate that the resulting image value is exactly `docker://ghcr.io/securego/gosec:<provided_version>`.
|
||||
6. Create a branch named `chore/update-action-gosec-<provided_version>`.
|
||||
7. Commit the change with message `chore(action): bump gosec to <provided_version>`.
|
||||
8. Push the branch to origin.
|
||||
9. Open a pull request to `master` with:
|
||||
- Title: `chore(action): bump gosec to <provided_version>`
|
||||
- Body: concise summary that this updates `action.yml` GHCR image version.
|
||||
|
||||
## Output requirements
|
||||
|
||||
- Report old version and new version.
|
||||
- Confirm that only `action.yml` was modified for the version bump.
|
||||
- Report the created branch name, commit SHA, pull request title, and pull request URL.
|
||||
@@ -0,0 +1,72 @@
|
||||
# Update supported Go versions across the repository
|
||||
|
||||
Use this command to bump repository Go versions to the newest patch releases of the latest two supported Go major versions.
|
||||
|
||||
Reference source for versions: https://go.dev/doc/devel/release
|
||||
|
||||
## Execution workflow
|
||||
|
||||
1. Fetch and parse the release page.
|
||||
2. Detect the latest two Go major.minor series and their latest patch versions.
|
||||
- Example shape: latest series `1.26.x` and previous series `1.25.x`.
|
||||
3. Derive:
|
||||
- `latest_patch` (for newest series, full patch string, e.g. `1.26.3`)
|
||||
- `previous_patch` (for second newest series, full patch string, e.g. `1.25.9`)
|
||||
- `latest_minor` (e.g. `1.26`)
|
||||
- `previous_minor` (e.g. `1.25`)
|
||||
4. Apply updates carefully across all relevant files.
|
||||
|
||||
## Version update rules
|
||||
|
||||
Use repository-wide search and update all applicable occurrences, including but not limited to:
|
||||
|
||||
- GitHub Actions workflow `go-version` values:
|
||||
- Matrix entries for supported versions must include exactly the two patch versions:
|
||||
- `previous_patch`
|
||||
- `latest_patch`
|
||||
- Single-version setup-go steps should use `latest_patch`.
|
||||
- Build argument and build tool defaults:
|
||||
- `GO_VERSION=<major.minor>` style values should use `latest_minor`.
|
||||
- Module/toolchain minimum version markers:
|
||||
- `go.mod` `go` directive should be set to `previous_minor.0`.
|
||||
- Embedded temporary `go.mod` contents in tests/benchmarks should use `previous_minor` (without patch) unless file style requires otherwise.
|
||||
- Documentation and skill/prompt metadata that state supported versions:
|
||||
- Update text to match the new supported pair (`previous_minor` and `latest_minor`).
|
||||
- Update "requires Go X or newer" style statements to `previous_minor`.
|
||||
|
||||
## Discovery checklist (must run)
|
||||
|
||||
Search the full repository for version markers and review each hit:
|
||||
|
||||
- `go-version:`
|
||||
- `setup-go`
|
||||
- `GO_VERSION`
|
||||
- `golang:`
|
||||
- `^go [0-9]+\.[0-9]+(\.[0-9]+)?$`
|
||||
- `Go 1.`
|
||||
- `1\.[0-9]+\.[0-9]+`
|
||||
|
||||
Do not change unrelated historical references unless they represent active supported-version policy.
|
||||
|
||||
## Validation
|
||||
|
||||
1. Confirm all intended files were updated and no obvious supported-version location was missed.
|
||||
2. Run targeted checks:
|
||||
- `go test ./...`
|
||||
3. Re-run search to ensure old supported pair is removed from active config/docs.
|
||||
|
||||
## Git and PR workflow
|
||||
|
||||
1. Create branch: `chore/update-go-versions-<latest_minor>`
|
||||
2. Commit message: `chore(go): update supported Go versions to <previous_patch> and <latest_patch>`
|
||||
3. Push branch.
|
||||
4. Open PR to `master` with:
|
||||
- Title: `chore(go): update supported Go versions to <previous_patch> and <latest_patch>`
|
||||
- Body summary listing key files changed and source link to go.dev release page.
|
||||
|
||||
## Output requirements
|
||||
|
||||
- Report detected versions (`previous_patch`, `latest_patch`, `previous_minor`, `latest_minor`).
|
||||
- List all updated files grouped by category (workflows, build config, module/tests, docs/metadata).
|
||||
- Report test command result.
|
||||
- Report branch name, commit SHA, PR title, and PR URL.
|
||||
@@ -0,0 +1,51 @@
|
||||
# gosec - Go Security Checker
|
||||
|
||||
gosec is a Go static analysis tool that inspects Go source code for security vulnerabilities by scanning the Go AST and SSA form.
|
||||
|
||||
## Build & Test
|
||||
|
||||
```bash
|
||||
# Build
|
||||
go build ./cmd/gosec/
|
||||
|
||||
# Run all tests
|
||||
go test ./...
|
||||
|
||||
# Run a specific test
|
||||
go test -run TestName ./path/to/package/
|
||||
|
||||
# Lint
|
||||
golangci-lint run
|
||||
|
||||
# Run gosec against a sample file
|
||||
go run ./cmd/gosec/ ./path/to/sample.go
|
||||
```
|
||||
|
||||
## Code Style
|
||||
|
||||
- Idiomatic Go; follow existing patterns in the codebase.
|
||||
- Prefer SSA-based analyzers over AST-based rules when feasible.
|
||||
- Optimize for performance — avoid unnecessary repeated AST or SSA traversals.
|
||||
|
||||
## Project Structure
|
||||
|
||||
- `rules/` — AST-based rule implementations
|
||||
- `analyzers/` — SSA-based analyzer implementations
|
||||
- `cmd/gosec/` — CLI entry point
|
||||
- `testutils/` — sample files used in tests (positive and negative cases)
|
||||
- `issue/` — issue and CWE type definitions
|
||||
- `report/` — output formatters
|
||||
|
||||
## Adding Rules
|
||||
|
||||
- Select an appropriate CWE aligned with current repository mappings.
|
||||
- Integrate the rule in all required registration points.
|
||||
- Add sample files in `testutils/` with at least 2 positive and 2 negative cases.
|
||||
- Update rule documentation in `README.md` in the same style as other rules.
|
||||
|
||||
## Custom Commands
|
||||
|
||||
- `/create-gosec-rule` — Design and implement a new gosec rule from an issue description
|
||||
- `/fix-gosec-bug` — Investigate and fix a bug from a GitHub issue URL
|
||||
- `/update-go-versions` — Bump supported Go versions across the repo
|
||||
- `/update-action-version` — Update the gosec GHCR image version in action.yml
|
||||
Reference in New Issue
Block a user