Repository navigation
feat: add security finding issue template - #3
Timur Tukaev (tym83) wants to merge 3 commits into
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
📝 WalkthroughWalkthroughA new GitHub issue template Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 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 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
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] " | |||
There was a problem hiding this comment.
The default title [security] is very minimal. Providing a suggested format in the title field can help maintainers create consistent and searchable issue titles across the repository.
title: "[security] <package>: <vulnerability ID>"| - 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: true![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There 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.
Standard issue template for maintainers to track security scanner findings with proper severity, triage status, and affected components. Assisted-by: LLM Signed-off-by: tym83 <6355522@gmail.com>
Add cncf-cozystack-security@lists.cncf.io as alternative reporting channel for external reporters. Assisted-by: LLM Signed-off-by: tym83 <6355522@gmail.com>
The same finding is reported again on every scanner run, and without the scanner name and its own identifier there is no reliable way to tell a repeat from a new issue or to trace an issue back to the alert that raised it. The form now asks for both; the finding ID stays optional because not every scanner assigns one. The CVE field becomes a vulnerability ID that also accepts GHSA and other advisory IDs, since a required CVE field cannot be filled for findings that have no CVE assigned. The default title spells out the package and ID, so issues for the same finding are easy to search for. Assisted-by: LLM Signed-off-by: Timur Tukaev <timur.tukaev@aenix.io>
a148ecf to
ee7e5cd
Compare
Aleksei Sviridkin (lexfrei)
left a comment
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
Timur Tukaev (@tym83) NOT LGTM. As an org-wide default this form shows up in the wrong repos: it skips cozystack/cozystack, which has its own templates, and it appears in public repos where per-finding detail is not supposed to go.
Business context: maintainers want one structured form for tracking scanner findings across the org.
-
The form contradicts the published security policy.
SECURITY.mdincozystack/cozystacksays per-finding detail and triage state "are kept private until fixed, because they describe unfixed exposure in released artifacts". Org-level issue templates in.githubapply to every repo that has no.github/ISSUE_TEMPLATEof its own. Today that includes public repos likewebsite,talm,cozyhrandcozystack-ui, so this adds a "Security Finding" form there that asks for the package, installed version, affected components and triage state of an unfixed finding. The "for maintainers" note does not stop anyone else from using it. -
The form misses the repos it is meant for.
cozystack/cozystackhas its own.github/ISSUE_TEMPLATE/, so org defaults never show there, even though the "Affected Cozystack components" placeholder points atpackages/...in that repo. The scanner itself files its issues in the privatesecurity-scannerrepo withgh issue create, and a form is not used by that path. If maintainers want a manual form, I think the right place issecurity-scanner/.github/ISSUE_TEMPLATE/, which is private and already where thesecurity/*labels and reminders live. -
The PR body ends with the "Generated with Claude Code" line. It also still describes a "CVE ID" field that the third commit renamed to "Vulnerability ID" and does not mention the scanner and finding ID fields. The body becomes the merge commit message, so it needs to match the diff and drop the tool line.
Non-blocking: cncf-cozystack-security@lists.cncf.io is not listed in either SECURITY.md, the org one or the one in cozystack/cozystack. Both name only private vulnerability reporting and a direct maintainer contact. If the list is a real intake channel, it should be added there first, with someone named as reading it.
2 participants
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