feat: add security finding issue template#3
Conversation
Standard issue template for maintainers to track security scanner findings with proper severity, triage status, and affected components. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughA new GitHub issue template Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request introduces a new GitHub issue template, security-finding.yml, designed for maintainers to report automated security scanner findings. The template includes structured fields for vulnerability details, affected components, and triage status. Feedback suggests enhancing the default title format for better consistency and renaming the CVE ID field to a more generic Vulnerability ID to support a wider range of security identifiers such as GHSA.
| @@ -0,0 +1,81 @@ | |||
| name: Security Finding | |||
| description: Report an automated security scanner finding (for maintainers) | |||
| title: "[security] " | |||
| - type: input | ||
| id: cve | ||
| attributes: | ||
| label: CVE ID | ||
| placeholder: CVE-YYYY-NNNNN | ||
| validations: | ||
| required: true |
There was a problem hiding this comment.
The cve field is mandatory, but not all security findings have a CVE ID (e.g., they might have a GHSA ID or be an internal finding). It is better to use a more inclusive label like 'Vulnerability ID' and update the placeholder to reflect this. I also suggest renaming the ID to vulnerability_id for clarity.
- type: input
id: vulnerability_id
attributes:
label: Vulnerability ID
placeholder: "e.g., CVE-YYYY-NNNNN or GHSA-xxxx-xxxx-xxxx"
validations:
required: trueThere was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
ISSUE_TEMPLATE/security-finding.yml (1)
29-69: Add scanner and finding-ID fields for triage traceability.This will make deduping and audit trails much easier across repeated scanner runs.
Suggested addition
- type: input + id: scanner + attributes: + label: Scanner source + placeholder: "e.g., Trivy, Grype, Dependabot, osv-scanner" + validations: + required: true + - type: input + id: finding_id + attributes: + label: Scanner finding ID (if available) + placeholder: "e.g., advisory ID / rule ID / alert URL" + - type: input id: package attributes: label: Affected package🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ISSUE_TEMPLATE/security-finding.yml` around lines 29 - 69, Add two new form fields to the security-finding template to capture scanner metadata: an input field with id "scanner" (attributes.label: Scanner, placeholder e.g., "Trivy/Ghsa/OSV") and an input field with id "finding_id" (attributes.label: Finding ID, placeholder e.g., "scanner-specific id or hash") so triage and deduping are possible; mark both with validations.required: true (and keep them alongside the existing fields such as "package", "installed_version", "fixed_version", "affected_components", and "description") and ensure their ids ("scanner" and "finding_id") are unique in the YAML so downstream tooling can reliably reference them.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@ISSUE_TEMPLATE/security-finding.yml`:
- Line 10: The template currently hardcodes the private reporting URL
"https://github.com/cozystack/cozystack/security/advisories/new", which can
misroute disclosures if the template is reused; update the line referencing
"Private Vulnerability Reporting" to use repo-agnostic wording such as "use this
repository's Security → Advisories" or explicitly state that submissions should
go to a centralized intake, and replace the hardcoded URL with either a relative
instruction or a configurable placeholder so the advisory destination is not
tied to cozystack/cozystack.
---
Nitpick comments:
In `@ISSUE_TEMPLATE/security-finding.yml`:
- Around line 29-69: Add two new form fields to the security-finding template to
capture scanner metadata: an input field with id "scanner" (attributes.label:
Scanner, placeholder e.g., "Trivy/Ghsa/OSV") and an input field with id
"finding_id" (attributes.label: Finding ID, placeholder e.g., "scanner-specific
id or hash") so triage and deduping are possible; mark both with
validations.required: true (and keep them alongside the existing fields such as
"package", "installed_version", "fixed_version", "affected_components", and
"description") and ensure their ids ("scanner" and "finding_id") are unique in
the YAML so downstream tooling can reliably reference them.
🪄 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: a203d79c-f5c9-41c7-a7c6-8753b3bed468
📒 Files selected for processing (1)
ISSUE_TEMPLATE/security-finding.yml
| attributes: | ||
| value: | | ||
| **This template is for automated scanner findings reviewed by maintainers.** | ||
| If you are an external reporter, please use [Private Vulnerability Reporting](https://github.com/cozystack/cozystack/security/advisories/new) instead. |
There was a problem hiding this comment.
Hardcoded private-report URL can misroute security disclosures.
If this template is reused outside cozystack/cozystack, reporters may submit to the wrong advisory destination. Prefer repo-agnostic wording (e.g., “use this repository’s Security → Advisories”) or clearly state centralized intake is intentional.
Suggested edit
- If you are an external reporter, please use [Private Vulnerability Reporting](https://github.com/cozystack/cozystack/security/advisories/new) instead.
+ If you are an external reporter, please use this repository’s **Private Vulnerability Reporting** flow from the Security tab.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| If you are an external reporter, please use [Private Vulnerability Reporting](https://github.com/cozystack/cozystack/security/advisories/new) instead. | |
| If you are an external reporter, please use this repository's **Private Vulnerability Reporting** flow from the Security tab. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@ISSUE_TEMPLATE/security-finding.yml` at line 10, The template currently
hardcodes the private reporting URL
"https://github.com/cozystack/cozystack/security/advisories/new", which can
misroute disclosures if the template is reused; update the line referencing
"Private Vulnerability Reporting" to use repo-agnostic wording such as "use this
repository's Security → Advisories" or explicitly state that submissions should
go to a centralized intake, and replace the hardcoded URL with either a relative
instruction or a configurable placeholder so the advisory destination is not
tied to cozystack/cozystack.
Add cncf-cozystack-security@lists.cncf.io as alternative reporting channel for external reporters. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> -e Signed-off-by: tym83 <6355522@gmail.com>
Summary
Add a standard issue template for security findings (
ISSUE_TEMPLATE/security-finding.yml).This template is used by maintainers to track scanner findings with structured fields: CVE ID, severity, affected package, components, triage status.
Reporters of new vulnerabilities should use Private Vulnerability Reporting instead.
Fields
🤖 Generated with Claude Code
Summary by CodeRabbit