fix(ci): self-install pinned gosec and resolve findings to green Security Scanning - #1363
Merged
Conversation
…rity Scanning The securego/gosec Docker action bundles Go 1.26.1 with GOTOOLCHAIN=local, which refuses to load the go.mod requiring Go 1.26.5. This causes gosec to scan 0 files and exit 1 with a toolchain mismatch rather than real findings. Fix: replace the Docker action with a go install step that uses the job's existing setup-go toolchain (1.26.5) to install gosec@v2.26.1, then run it directly. Add `if: always()` to the SARIF upload so results are uploaded even when gosec finds issues. After unblocking the toolchain gate, resolve all 68 real findings: - G104 (unhandled errors): handle os.Setenv return values in cmd/server and testutil.SetEnv; handle both m.Close() return values in migrate.go; annotate hash.Hash64.Write and tabwriter.Flush into bytes.Buffer which cannot return errors per their respective interface contracts - G115 (integer overflow): add math.MaxInt32 bounds guards in database connection pool config; annotate conversions where values are provably bounded by API/operator limits (RI counts, CLI flags, pool sizes) - G101 (credential false positives): annotate credential-type name constants, email template body text, env-var name constants, and sentinel hash - G204/G304/G122 (subprocess/file path): annotate deploy tooling (npm, docker, az, gcloud) where binary is hardcoded and args are code-controlled; annotate WalkDir-derived paths and operator-configured file paths - G505 (SHA-1): annotate TOTP HMAC-SHA1 required by RFC 6238 - G706 (log injection): annotate diagnostic logging of operator-controlled env vars and validated task type strings - G703 (path traversal): annotate static file server backed by resolveStaticFilePath with directory-containment validation - G702 (command injection): annotate CI sanity test tooling with hardcoded binary - G705 (XSS via taint): annotate Lambda response body proxy with explicit Content-Type guard - G117 (marshaled secret fields): annotate intentional credential struct marshaling for secure storage Result: gosec exits 0, Issues: 0, Nosec: 68. go build ./... exits 0. go test -short ./... 4716 passed. govulncheck clean.
Member
Author
|
@coderabbitai review |
Contributor
✅ Action performedReview finished.
|
Contributor
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 40 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. 📝 WalkthroughWalkthroughThe pull request updates CI security scans, adds targeted gosec annotations across Go code, improves migration close-error logging, checks selected environment-setting failures, and handles test environment restoration errors. ChangesSecurity lint and CI scanning
Application and server handling
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci.yml:
- Around line 321-327: Update the gosec workflow step to discover and scan every
Go module, including the root, pkg, and providers/* modules, rather than only
running gosec against root ./.... Generate SARIF output for each module, merge
the results into gosec-results.sarif, and preserve that merged file for the
existing upload and hard-fail checks.
In `@ci_cd_sanity_tests/cmd/ri-exchange/main.go`:
- Line 77: Validate the operator-provided targetCount before the int32
conversions used for TargetCount and the other referenced fields. In the main
CLI flow, enforce that targetCount is within the int32 range and reject
out-of-range values before downstream validation or exchange requests; retain
the existing G115 suppressions after this guard.
In `@ci_cd_sanity_tests/cmd/sanity/main.go`:
- Line 28: Validate the CLI maxList value before the int32 conversion used in
MaxList, rejecting any input outside the int32 range with an appropriate error.
Only perform the cast and retain the G115 suppression after validation, while
preserving accepted in-range values and the existing default behavior.
In `@internal/auth/service_mfa.go`:
- Line 7: Update the comment on the crypto/sha1 import to state that SHA-1 is
retained for broad authenticator compatibility and existing otpauth
provisioning; remove the claim that RFC 6238 mandates HMAC-SHA1 and acknowledge
that the RFC also permits SHA-256 and SHA-512.
In `@internal/deploy/frontend.go`:
- Line 95: Before the os.ReadFile call in the deployment file traversal,
validate the WalkDir entry’s type and reject entries whose Type includes
os.ModeSymlink. Ensure symlinked files are skipped or returned as an error
before reading, while preserving normal reads for regular deployment files.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 27874f72-a120-400f-a78e-e6eff63cb30d
📒 Files selected for processing (31)
.github/workflows/ci.ymlci_cd_sanity_tests/cmd/ri-exchange/main.goci_cd_sanity_tests/cmd/sanity/main.goci_cd_sanity_tests/pkg/sanity/azure/azure.gocmd/configure_azure.gocmd/configure_gcp.gocmd/helpers.gocmd/multi_service_csv.gocmd/server/main.gointernal/api/handler_purchases_revoke.gointernal/api/handler_ri_exchange.gointernal/auth/service_mfa.gointernal/auth/service_password.gointernal/config/constants.gointernal/credentials/cipher.gointernal/credentials/gcp_federated.gointernal/credentials/resolver.gointernal/database/connection.gointernal/database/postgres/migrations/migrate.gointernal/deploy/docker.gointernal/deploy/frontend.gointernal/deploy/profiles.gointernal/email/templates.gointernal/oidc/jwks.gointernal/reporter/reporter.gointernal/server/app.gointernal/server/handler.gointernal/server/http.gointernal/server/scheduledauth/validator.gointernal/server/static.gointernal/testutil/testutil.go
4 tasks
Once the gosec toolchain fix let the security-scan job run past gosec, the
previously-masked tfsec step ran and hard-failed on a parse error:
scan failed: terraform/modules/deployment-checks/main.tf:61:
Blocks of type "check" are not expected here
aquasecurity/tfsec-action is deprecated (tfsec is folded into Trivy) and its
bundled HCL parser does not understand Terraform 1.5+ `check {}` blocks. Its
soft_fail only downgrades findings, not scan/parse errors, so the step
hard-failed the job.
Replace it with Trivy config scanning (tfsec's official successor) scoped to
terraform/, preserving IaC misconfiguration coverage. Trivy parses `check {}`
blocks correctly and, like the existing filesystem Trivy step, uses the
default exit-code 0 so findings report to the Security tab without gating the
job, matching tfsec's prior soft_fail: true behaviour. The results upload uses
a distinct SARIF category so it does not overwrite the filesystem Trivy
analysis (both report as tool "Trivy").
The action stays pinned to the same aquasecurity/trivy-action SHA (v0.36.0)
already used for the filesystem scan.
Verified locally with Trivy 0.72.0: `trivy config terraform/` parses all 20
config files with no parse error, exit 0, 0 CRITICAL/HIGH findings.
Member
Author
|
@coderabbitai review |
Contributor
✅ Action performedReview finished.
|
The trivy-action IaC config scan panicked in CI: panic: value is null cty.Value.AsString(...) trivy/pkg/iac/adapters/terraform/aws/provider.adaptDefaultTags adapt.go:147 Process completed with exit code 2 Root cause: aquasecurity/trivy-action@v0.36.0 (the latest release) bundles Trivy v0.70.0, which panics in adaptDefaultTags on terraform/environments/aws/main.tf's provider default_tags block because those tag vars resolve to null when no tfvars are passed to the scan. The panic exits 2 and no SARIF is written, so the upload step then fails on a missing file. The bug is fixed in Trivy >= v0.72.0. Since v0.36.0 is already the newest trivy-action release, pin the Trivy binary independently via the action's `version` input, which it forwards to aquasecurity/setup-trivy. Set both the filesystem scan and the IaC config scan to v0.72.0 so they share one pinned binary. Both keep the default exit-code 0, so findings report to the Security tab without gating the job. Verified locally with Trivy 0.72.0: `trivy config terraform/` and `trivy fs .` both run with no panic and exit 0.
Member
Author
|
@coderabbitai review |
Contributor
✅ Action performedReview finished.
|
…nnotate nosec across modules
- ci_cd_sanity_tests/cmd/ri-exchange: add explicit range validation (1..math.MaxInt32)
before int32 casts of --target-count; update #nosec G115 justification accordingly
- ci_cd_sanity_tests/cmd/sanity: same bounds check for --max-list
- internal/deploy/frontend.go: reject symlinks in WalkDir callback before os.ReadFile
(ModeSymlink check); update #nosec G304,G122 with accurate justification
- internal/auth/service_mfa.go: correct #nosec G505 comment -- RFC 6238 also permits
SHA-256/SHA-512; SHA-1 retained for broad authenticator app compatibility
- providers/aws/provider.go: fix init() to handle RegisterProvider error (panic on
duplicate registration); annotate #nosec G101 on SDK provider-type name constants
- providers/azure/provider.go: same init() fix
- providers/gcp/provider.go: same init() fix; annotate #nosec G703 on CLOUDSDK_CONFIG
and APPDATA env-var paths (standard system vars, not user input)
- providers/azure/services/{compute,internal/reservations}: annotate #nosec G104 on
resp.Body.Close() calls where body is fully drained before Close
- providers/aws/services/{ec2,rds,redshift,opensearch,memorydb,elasticache}: annotate
#nosec G115 on int32(rec.Count) -- CE recommendation counts stay far below MaxInt32
- pkg/logging/logger.go: annotate #nosec G115 on int32(level) -- Level is a bounded
enum (0-3)
- pkg/config/load.go: annotate #nosec G101 on CUDLY_API_KEY (env var name, not
credential) and #nosec G304 on operator-supplied config file path
- pkg/common/audit.go: extend existing #nosec G302 to cover G304 on audit log path
Root ./... silently misses pkg/ and providers/* (each is a separate Go module). Mirror the govulncheck per-module loop: run gosec against each of the six modules (., pkg, providers/aws, providers/azure, providers/gcp, tests/e2e), collect per-module SARIF output to RUNNER_TEMP, then merge all runs into gosec-results.sarif via a Python one-liner before the existing upload-SARIF step. All six modules are clean (0 findings) after the preceding commit.
Member
Author
|
@coderabbitai review |
Contributor
✅ Action performedReview finished.
|
This was referenced Jul 16, 2026
…nline python The multi-line python heredoc embedded in the run block started at column 1, escaping the literal block scalar and making the whole workflow file unparseable (run 29501998444 concluded failure with zero jobs). Replace it with a single jq -s merge; jq is preinstalled on the GitHub Ubuntu runner image so no new dependencies. Validated with PyYAML parse, actionlint (exit 0), and a full local simulation of the loop + merge (6 modules, 6 SARIF runs merged, gosec exit 0 in every module).
Member
Author
|
@coderabbitai review |
Contributor
✅ Action performedReview finished.
|
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@internal/deploy/frontend.go`:
- Around line 85-92: The uploadDirectory entry handling currently skips only
symlinks, allowing FIFOs, devices, and sockets to reach uploadFile. Before
calling uploadFile, obtain the entry info and require
d.Info().Mode().IsRegular(); skip and log non-regular entries, preserving
symlink rejection and adding a regression test covering a special file.
In `@providers/azure/services/internal/reservations/purchase.go`:
- Line 215: Handle the io.ReadAll errors before relying on the suppressed
resp.Body.Close calls: update the response-reading flows at
providers/azure/services/internal/reservations/purchase.go lines 214-215,
317-318, and 402-403 to check and propagate or otherwise appropriately handle
each read error before continuing. Ensure the Close annotations remain valid
only after a successful, fully drained read.
In `@providers/gcp/provider.go`:
- Around line 305-306: Update the `#nosec` G703 suppression comment beside the
os.Stat call in the relevant provider logic to describe CLOUDSDK_CONFIG and
APPDATA as environment-controlled under a trusted deployment, removing the
inaccurate claim that they are not user-controlled; leave the stat probe
unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: b1d1aa3b-ea2f-49b1-92e6-ba876baea9a0
📒 Files selected for processing (19)
.github/workflows/ci.ymlci_cd_sanity_tests/cmd/ri-exchange/main.goci_cd_sanity_tests/cmd/sanity/main.gointernal/auth/service_mfa.gointernal/deploy/frontend.gopkg/common/audit.gopkg/config/load.gopkg/logging/logger.goproviders/aws/provider.goproviders/aws/services/ec2/client.goproviders/aws/services/elasticache/client.goproviders/aws/services/memorydb/client.goproviders/aws/services/opensearch/client.goproviders/aws/services/rds/client.goproviders/aws/services/redshift/client.goproviders/azure/provider.goproviders/azure/services/compute/client.goproviders/azure/services/internal/reservations/purchase.goproviders/gcp/provider.go
🚧 Files skipped from review as they are similar to previous changes (3)
- internal/auth/service_mfa.go
- ci_cd_sanity_tests/cmd/ri-exchange/main.go
- .github/workflows/ci.yml
Comment on lines
+85
to
+92
| // Reject symlinks: filepath.WalkDir does not traverse symlinks but | ||
| // os.ReadFile will dereference them. A symlinked file inside the build | ||
| // dir could point outside it, so we skip any symlink entry explicitly. | ||
| if d.Type()&fs.ModeSymlink != 0 { | ||
| log.Printf("deploy: skipping symlink %s", path) | ||
| return nil | ||
| } | ||
| // Convert to forward slashes for S3 keys | ||
| key := strings.ReplaceAll(relPath, string(filepath.Separator), "/") | ||
| return s.uploadFile(ctx, distDir, bucketName, path) |
Contributor
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Map the relevant file first, then read the smallest useful slices.
ast-grep outline internal/deploy/frontend.go --view expanded || true
echo '--- file: internal/deploy/frontend.go (lines 1-220) ---'
cat -n internal/deploy/frontend.go | sed -n '1,220p'Repository: LeanerCloud/CUDly
Length of output: 9865
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- search for uploadDirectory/uploadFile tests and special-file handling ---'
rg -n --hidden -S "uploadDirectory|uploadFile|ModeSymlink|IsRegular|WalkDir|special file|fifo|socket|device" internal . || true
echo '--- list test files near deploy package ---'
git ls-files 'internal/**' | rg '^internal/.+(_test\.go|testdata/)'Repository: LeanerCloud/CUDly
Length of output: 13328
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- internal/deploy/frontend_test.go ---'
wc -l internal/deploy/frontend_test.go
cat -n internal/deploy/frontend_test.go | sed -n '1,260p'
echo '--- internal/deploy/coverage_extra_test.go ---'
wc -l internal/deploy/coverage_extra_test.go
cat -n internal/deploy/coverage_extra_test.go | sed -n '1,240p'Repository: LeanerCloud/CUDly
Length of output: 19804
Reject all non-regular entries before reading them.
uploadDirectory only skips symlinks, so FIFOs, devices, or sockets can still reach os.ReadFile and block or read unintended data. Check d.Info().Mode().IsRegular() before calling uploadFile, and add a regression test for special files.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@internal/deploy/frontend.go` around lines 85 - 92, The uploadDirectory entry
handling currently skips only symlinks, allowing FIFOs, devices, and sockets to
reach uploadFile. Before calling uploadFile, obtain the entry info and require
d.Info().Mode().IsRegular(); skip and log non-regular entries, preserving
symlink rejection and adding a regression test covering a special file.
| } | ||
| body, _ := io.ReadAll(resp.Body) | ||
| resp.Body.Close() | ||
| resp.Body.Close() // #nosec G104 -- body fully drained by io.ReadAll before Close; transport close error does not affect correctness |
Contributor
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
Check io.ReadAll errors before relying on the Close suppression.
Each site ignores the preceding read error, so the response may be partial despite the annotation claiming it was fully drained.
providers/azure/services/internal/reservations/purchase.go#L215-L215: handle theio.ReadAllerror at Line 214 before continuing.providers/azure/services/internal/reservations/purchase.go#L318-L318: handle theio.ReadAllerror at Line 317 before continuing.providers/azure/services/internal/reservations/purchase.go#L403-L403: handle theio.ReadAllerror at Line 402 before continuing.
📍 Affects 1 file
providers/azure/services/internal/reservations/purchase.go#L215-L215(this comment)providers/azure/services/internal/reservations/purchase.go#L318-L318providers/azure/services/internal/reservations/purchase.go#L403-L403
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@providers/azure/services/internal/reservations/purchase.go` at line 215,
Handle the io.ReadAll errors before relying on the suppressed resp.Body.Close
calls: update the response-reading flows at
providers/azure/services/internal/reservations/purchase.go lines 214-215,
317-318, and 402-403 to check and propagate or otherwise appropriately handle
each read error before continuing. Ensure the Close annotations remain valid
only after a successful, fully drained read.
Comment on lines
+305
to
306
| _, err := os.Stat(filepath.Join(dir, adcFile)) // #nosec G703 -- CLOUDSDK_CONFIG is a standard gcloud env var set by the OS or gcloud CLI, not user-controlled input | ||
| return err == nil |
Contributor
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate the file and inspect the relevant region with line numbers.
sed -n '280,330p' providers/gcp/provider.go
# Show the other mentioned suppression around line 309 if it differs nearby.
sed -n '300,315p' providers/gcp/provider.go
# Find all G703 suppressions in this file for context.
rg -n "nosec G703|CLOUDSDK_CONFIG|APPDATA" providers/gcp/provider.goRepository: LeanerCloud/CUDly
Length of output: 3830
Fix the G703 suppression wording CLOUDSDK_CONFIG and APPDATA are environment-controlled, so the comment should state the trusted-deployment assumption instead of saying they are not user-controlled. The os.Stat probe itself is fine.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@providers/gcp/provider.go` around lines 305 - 306, Update the `#nosec` G703
suppression comment beside the os.Stat call in the relevant provider logic to
describe CLOUDSDK_CONFIG and APPDATA as environment-controlled under a trusted
deployment, removing the inaccurate claim that they are not user-controlled;
leave the stat probe unchanged.
Code scanning rejects a SARIF file whose runs share the same category (github.blog changelog 2025-07-21): run 29512972014's gosec scan itself passed on all six modules, but the upload-sarif step failed with "does not support uploading multiple SARIF runs with the same category". The Trivy IaC upload failure in the same run was a cascade (its scan step was skipped after the gosec upload failed, so the file never existed). Set a distinct automationDetails.id (gosec-<module>/) on each module's run via jq before merging, so all six runs upload under their own category. Verified locally: merged file contains 6 runs with 6 unique automationDetails ids; PyYAML parse OK; actionlint exit 0.
Member
Author
|
@coderabbitai review |
Contributor
✅ Action performedReview finished.
|
Member
Author
|
Merged to main: Security Scanning is GREEN on the merged head (gosec v2.26.1 pinned, ALL 6 Go modules scanned - the pre-merge review caught that only the root module was covered; 21 additional findings in pkg/providers fixed for real incl. two fail-loud init() fixes; per-module SARIF runs tagged with unique automationDetails.id after GitHub's same-category rejection; Trivy pinned v0.72.0). From here, any commit introducing a gosec finding fails its own PR. Lint Code remains the last debt job - #1364 retires it next. Closes the Security-Scanning half of the known-debt exception list. |
This was referenced Jul 16, 2026
cristim
added a commit
that referenced
this pull request
Jul 16, 2026
gocritic importShadow: requireInt32Range's "flag" parameter shadowed the imported flag package; rename to flagName. Surfaced after rebasing onto main with #1363 merged.
cristim
added a commit
that referenced
this pull request
Jul 16, 2026
gocritic importShadow: requireInt32Range's "flag" parameter shadowed the imported flag package; rename to flagName. Surfaced after rebasing onto main with #1363 merged.
cristim
added a commit
that referenced
this pull request
Jul 16, 2026
gocritic importShadow: requireInt32Range's "flag" parameter shadowed the imported flag package; rename to flagName. Surfaced after rebasing onto main with #1363 merged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Root Cause
The
security-scanjob used thesecurego/gosecDocker action (@v2.26.1), which bundles its own Go 1.26.1 toolchain withGOTOOLCHAIN=local. The repository'sgo.modrequires Go 1.26.5 — a newer patch. WithGOTOOLCHAIN=local, the bundled Go refuses to load the module, causing gosec to scan 0 files and exit 1 with a toolchain mismatch, not real findings. CI has been red sincego.modwas bumped past 1.26.1.CI Change
Replace the Docker action with a
run:step that uses the job's existingsetup-go(1.26.5) to install gosec:gosec stays hard-fail (no
-no-fail). The SARIF upload getsif: always()so results reach the Security tab even when the scan finds issues.Finding Disposition
cmd/server/main.goandtestutil; bothm.Close()return values handled inmigrate.go. False positives (hash.Write, tabwriter.Flush to bytes.Buffer) annotated.database/connection.go. Remainder annotated where values are provably bounded by AWS API limits, CLI flag defaults, or operator config.~/.cudly/). Annotated.resolveStaticFilePathvalidates withfilepath.Abs+ containment check. Annotated.azinvocation with hardcoded binary. Annotated.Final gosec result: Issues: 0, Nosec: 68, exit 0.
Verification
go build ./...exit 0gosec ./...exit 0, Issues: 0, Nosec: 68go test -short ./...4716 passed in 21 packages, exit 0govulncheck ./...no vulnerabilities found across all modulesNotes
The Lint Code check will remain red on this PR — that is pre-existing lint debt unrelated to security scanning and tracked separately.
Summary by CodeRabbit