Skip to content

[deep-report] Introduce a shared Finding/SeverityLevel type across 9 security-scanner integrations #54228

Description

@github-actions

Description

9 independent security-scanner integrations each declare their own bespoke finding/issue struct instead of sharing a common type: zizmorFinding (pkg/cli/zizmor.go:24), poutineFinding (poutine.go:24), grypeFinding (grype.go:53), runnerGuardFinding (runner_guard.go:22), yamllintIssue (yamllint.go:27), grantPackageFinding (grant.go:50), Finding (audit_report.go:66), SecurityFinding (markdown_security_scanner.go:57), ValidationIssue (validation_issue.go:4). Each reinvents severity/location fields under different names (RuleID/Ident/Name, Severity/Level as a bare string with no shared enum, File/Line/Column shaped differently per tool).

Expected Impact

A shared Finding{RuleID string, Severity SeverityLevel, Message string, File string, Line, Column int} type (e.g. in pkg/console or a new pkg/scanfindings package) with a shared SeverityLevel enum gives one severity vocabulary instead of nine, makes adding a new scanner integration mechanical (map native JSON onto the shared type), and enables consistent rendering/sorting across all 9 tools.

Suggested Agent

Existing Go engineering / code-quality refactor agent.

Estimated Effort

Medium (4-6 hours) — 9 call sites, mostly mechanical field-mapping adapters per tool integration.

Data Source

DeepReport analysis, 2026-08-20 ~12:30Z cycle, sourced from discussion #54213 (Typist - Go Type Consistency Analysis), Cluster 1. No existing open or closed issue found covering this consolidation.

Generated by 🔬 Deep Report · agent · 153.5 AIC · ⌖ 12.9 AIC · ⊞ 11.9K ·

  • expires on Aug 22, 2026, 4:31 AM UTC-08:00

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions