You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: Plan and apply Go dependency updates, including advisory-driven bumps, Trivy/govulncheck validation, and supply-chain review. Use when the user asks to update dependencies, refresh modules for security alerts, or run dependency vulnerability scans.
4
+
---
5
+
6
+
# Dependency updates
7
+
8
+
Use this skill when the user wants to **update dependencies** in this repo—whether driven by security advisories, Dependabot, or general maintenance.
9
+
10
+
This repository is primarily **Go** (`go.mod` / `go.sum`). There is no root Node workspace; follow the Go workflow below.
11
+
12
+
**Project convention:** Do **not** create or maintain `docs/vuln-residual-risk.md` (or similar residual-risk documents) unless the user explicitly asks. Summarize anything still open in the PR description or chat instead.
13
+
14
+
## Quick Start
15
+
16
+
1. Run Trivy from the project root as a container, not a locally installed binary:
2. Optionally supplement with Go’s official checker (reports module vulnerabilities from the Go vulnerability database):
23
+
24
+
```bash
25
+
go install golang.org/x/vuln/cmd/govulncheck@latest
26
+
govulncheck ./...
27
+
```
28
+
29
+
3. Use `gh` against the upstream repo when helpful, for example Dependabot security alerts:
30
+
31
+
```bash
32
+
gh api repos/trufflesecurity/trufflehog/dependabot/alerts --paginate
33
+
```
34
+
35
+
4. Triage each finding as:
36
+
-`Actionable`: a fixed version exists and the current constraint allows, or can be relaxed to allow, the update.
37
+
-`Blocked`: a fix exists, but taking it would require a major-version bump in a sibling dependency or a broader refactor the user did not ask for.
38
+
-`No fix available`: upstream has not published a patched release.
39
+
40
+
5. Apply module updates, rerun the scans, and note remaining gaps in the PR or response (not in a standing residual-risk doc).
41
+
42
+
## Triage notes
43
+
44
+
- For Dependabot or advisory-driven work, note the affected module, vulnerable version range, fixed version, and exploit conditions called out in the advisory.
45
+
- Check whether this repo is actually affected: look for imports, direct usage of the vulnerable APIs or code paths, and any required configuration, input shape, or runtime exposure described in the alert.
46
+
- Verify that any advisory-listed "fixed version" actually exists upstream before planning around it; scanners can report versions that are not yet published.
47
+
- For each incoming dependency update, spawn a sub-agent to inspect the new version for malicious or suspicious supply-chain changes before you adopt it.
48
+
- Have the sub-agent review release notes and the module diff for typosquat signals, maintainer churn, unexpected build tags or generated code, obfuscated code, unexpected network or process behavior, credential or filesystem access, and unexplained new transitive dependencies.
49
+
- Use sub-agents for per-package advisory and diff review, but keep `go.mod` / `go.sum` edits in a single coordinating agent.
50
+
- Even if the alert appears non-exploitable here, still take the patch when the upgrade is reasonable and low risk.
51
+
- If something cannot be upgraded yet, explain why in the PR or chat (upstream tag missing, incompatible API, etc.); do not create standing residual-risk documentation files unless the user asks.
52
+
53
+
## Go workflow
54
+
55
+
Use this path for findings in `go.mod` or `go.sum`.
56
+
57
+
- Prefer targeted upgrades: `go get example.com/module@vX.Y.Z` (or a compatible minor/patch as appropriate).
58
+
- After changes, run `go mod tidy` from the project root.
59
+
- Never edit `go.sum` manually; it is generated.
60
+
- Run `make lint` (or `./scripts/lint.sh`) to match CI’s golangci-lint configuration.
61
+
- Run tests appropriate to what changed. Broad checks often use:
62
+
-`make test` for the default unit test sweep, or
63
+
-`go test -timeout 30s -tags "integration detectors" ./...` when exercising integration and detector-tagged packages (narrow the path when only specific packages changed).
64
+
- Use `make test-integration` or `make test-detectors` when the change touches integration-only or detector code paths.
65
+
66
+
## Validation
67
+
68
+
After making updates:
69
+
70
+
1. Re-run the same Trivy container command from the project root and confirm the vulnerability count decreased or the actionable findings were removed.
71
+
2. Re-run `govulncheck ./...` if you use it in this pass.
72
+
3. Run `make lint` and the relevant `go test` / `make test*` targets for the areas you touched.
73
+
74
+
## Execution notes
75
+
76
+
- Do not install Trivy locally as part of this workflow; use the containerized command.
77
+
- Never edit `go.sum` manually; regenerate with `go mod tidy` after `go get` / `go mod` changes.
78
+
- Do not create commits unless the user explicitly asks for them.
79
+
- Use sub-agents wherever practical for read-only research and independent validation; keep `go.mod` and `go.sum` edits under one coordinating agent.
80
+
- Include the analysis in the PR description: what the alert or upgrade was, how you checked impact, what the supply-chain review found, and what you changed.
81
+
- Follow nearby project conventions and add tests when dependency updates require behavioral changes.
0 commit comments