CVE skills#756
Conversation
scan Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Stephane Bouchet <sbouchet@redhat.com>
… rebase rules Prefer parent-scoped cascading npm overrides over @major-scoped ones when fixing transitive CVEs. Update Step 6 to ask the user before running /add-rebase-rules. Signed-off-by: Stephane Bouchet <sbouchet@redhat.com> Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Stephane Bouchet <sbouchet@redhat.com>
Remove the "unscoped" option and clarify that parent-scoped overrides should be used even for single-version cases. The @major scoping is an absolute last resort only. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Stephane Bouchet <sbouchet@redhat.com>
Document that `npm run prepare` should be used at the repo root and in launcher/ to regenerate lock files, compile, and run tests. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Stephane Bouchet <sbouchet@redhat.com>
After npm run prepare, verify that every modified package.json has its corresponding package-lock.json regenerated. Fall back to npm install in specific directories (build/, test/) if not. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Stephane Bouchet <sbouchet@redhat.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Stephane Bouchet <sbouchet@redhat.com>
For transitive dependencies, analyze whether a newer version of the parent package pulls in a fixed transitive before falling back to overrides. Parent bumps are cleaner and more likely to align with upstream updates. Signed-off-by: Stephane Bouchet <sbouchet@redhat.com> Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Stephane Bouchet <sbouchet@redhat.com>
Signed-off-by: Stephane Bouchet <sbouchet@redhat.com>
Signed-off-by: Stephane Bouchet <sbouchet@redhat.com>
Signed-off-by: Stephane Bouchet <sbouchet@redhat.com>
Signed-off-by: Stephane Bouchet <sbouchet@redhat.com>
|
Hi! I'm che-ai-assistant — I help with your pull requests. Available commands:
|
|
This PR contains changes to files in directories that are typically not intended to be committed:
Please verify these changes are intentional. |
📝 WalkthroughWalkthroughAdds two Claude skill playbooks: one for Jira-driven CVE remediation across npm, Cargo, and container RPMs, and one for triaging Dependabot alerts into deduplicated Jira vulnerability tickets. The remediation workflow includes advisory analysis, dependency updates, rebase rules, security review, and Jira transitions. The triage workflow filters alerts, verifies installed packages, creates Jira issues, links advisories, and reports results. Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ 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 |
|
Pull Request images published ✨ Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-756-amd64 |
1 similar comment
|
Pull Request images published ✨ Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-756-amd64 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
🤖 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 @.claude/skills/cve-remediation/SKILL.md:
- Around line 72-90: The workspace scan in the CVE remediation workflow must
discover every matching package.json rather than only fixed roots and
lockfile-bearing extensions. Replace the sequential cd commands with a loop that
derives each workspace directory and runs npm ls <package-name> inside a
subshell for that directory, preserving failures instead of redirecting stderr
to suppress them.
- Around line 354-364: Update the unresolved-advisory handling in the CVE
remediation workflow so cases where no patched version can be determined receive
a terminal Jira outcome, such as a comment, label, or manual-review transition,
before skipping the fix. Preserve the warning and do not guess a version, while
ensuring future cron polls do not retry the same unresolved ticket.
- Around line 194-218: Update the “Verification sequence” to fail closed:
require each affected workspace lockfile to change or otherwise explicitly
verify the patched resolution, and stop the remediation process on any npm
install, npm ls, or npm audit failure. Run audit checks for every affected
workspace rather than only code/, and do not suppress audit errors; report
discrepancies as failures instead of warnings.
- Around line 238-243: Clarify the Jira-comment rules in the CVE remediation
instructions so the RPM/system-level dependency path explicitly requires adding
the provided manual-intervention comment, despite the global comment
restriction. Preserve the requirement that RPM cases must not change the Jira
ticket status, and align the corresponding guidance at both referenced sections.
- Around line 33-35: Harden the package extraction and command usage in the CVE
remediation workflow: validate the Jira-derived package token against the
allowed ecosystem-specific package-name formats before using it, rejecting
invalid input. Update the affected grep, npm, Cargo, and Dockerfile commands to
pass the package through a shell variable using “--” where supported and
“"$pkg"” quoting, covering the extraction and command blocks around the
referenced sections.
- Around line 102-122: Update the “Container image system packages (RPMs)”
guidance in SKILL.md to require scanning the built image or its package
manifest/RPM database for installed packages and resolved versions. Do not use
Dockerfile searches or infer versions from Dockerfile text; compare each actual
installed RPM version against the advisory’s affected and patched ranges, while
retaining source and dependency classification where applicable.
- Around line 244-303: Update the “Step 6 — Add rebase rules” workflow to
validate every generated rebase rule before declaring remediation complete. Add
JSON syntax checks for .rebase/add and .rebase/override files, and perform a
dry-run or apply verification against the upstream tree for both JSON merges and
.rebase/replace exact text substitutions, failing when a replacement does not
match. Require these checks before commit or Jira-ticket transition.
In @.claude/skills/dependabot-cve-triage/SKILL.md:
- Line 166: Replace the concrete employee email in the JIRA_USER documentation
with a non-personal placeholder or service-account example, keeping the
description of the required Jira account email intact.
- Around line 25-28: The single-alert flow must match the all-alert flow by
requiring an open alert. Update the single-alert gh api projection to include
state, then validate that returned state is open before allowing the alert
through filtering or Jira ticket creation; reject dismissed and closed alerts.
- Line 198: Update the manifest-filtering guidance in the Dependabot CVE triage
skill to skip `.rebase/` paths and package-lock-only manifests only when the
package is not direct in the corresponding `package.json`; retain direct-package
alerts and rewrite their manifest path as required by Step 2.
- Around line 151-153: Update the remotelink curl invocation in the Jira issue
flow to stop passing JIRA_API_TOKEN through the -u command-line argument. Use a
protected temporary netrc/config or equivalent credential mechanism, ensure curl
reads it without exposing the token in argv, and remove the temporary credential
material after the request completes.
- Around line 75-79: Update the dependency scan loop to find directories
containing package.json, while preserving the existing exclusions and avoiding
duplicate directories. In the npm ls invocation, gate output on a successful
exit status rather than non-empty stdout, so only confirmed package presence is
reported.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: f868067e-3a87-4651-8fcc-2f2e4742dbbd
📒 Files selected for processing (2)
.claude/skills/cve-remediation/SKILL.md.claude/skills/dependabot-cve-triage/SKILL.md
| Extract: | ||
| - **CVE ID**: e.g. `CVE-2026-12143` | ||
| - **Package name**: the token after `code-rhel9:` and before the next `:` (trimmed) |
There was a problem hiding this comment.
🔒 Security & Privacy | 🔴 Critical | 🏗️ Heavy lift
Treat Jira-derived package names as untrusted input.
The package token comes from Jira and is interpolated into shell commands without strict validation. Quoted grep arguments still allow shell substitution, while npm ls, Cargo, and Dockerfile commands use the placeholder unquoted. A malicious ticket summary could execute commands with the agent’s credentials. Validate ecosystem-specific package names and pass shell variables safely with -- and "$pkg".
Also applies to: 72-75, 97-109
🤖 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 @.claude/skills/cve-remediation/SKILL.md around lines 33 - 35, Harden the
package extraction and command usage in the CVE remediation workflow: validate
the Jira-derived package token against the allowed ecosystem-specific
package-name formats before using it, rejecting invalid input. Update the
affected grep, npm, Cargo, and Dockerfile commands to pass the package through a
shell variable using “--” where supported and “"$pkg"” quoting, covering the
extraction and command blocks around the referenced sections.
| Search across all workspaces: | ||
| ```bash | ||
| find code/ -name "package.json" -not -path "*/node_modules/*" -exec grep -l "<package-name>" {} \; | ||
| ``` | ||
|
|
||
| Then for each package.json that references the package, run `npm ls` from that workspace root: | ||
| ```bash | ||
| cd code/ && npm ls <package-name> 2>/dev/null | ||
| cd code/remote/ && npm ls <package-name> 2>/dev/null | ||
| cd code/build/ && npm ls <package-name> 2>/dev/null | ||
| ``` | ||
|
|
||
| Also check sub-workspaces that have their own lock files: | ||
| ```bash | ||
| for dir in code/extensions/*/; do | ||
| if [ -f "$dir/package-lock.json" ] || [ -f "$dir/npm-shrinkwrap.json" ]; then | ||
| (cd "$dir" && npm ls <package-name> 2>/dev/null) && echo " ^ in $dir" | ||
| fi | ||
| done |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
Enumerate every npm workspace with cwd-safe commands.
The workflow claims to inspect every independent package.json, but only checks three fixed roots plus extensions that have lockfiles. Test workspaces and other matching workspaces can be skipped. Additionally, sequential cd code/ followed by cd code/remote/ resolves the latter relative to code/ when run as one shell block. Derive each workspace root and execute commands in a subshell, without suppressing failures.
🤖 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 @.claude/skills/cve-remediation/SKILL.md around lines 72 - 90, The workspace
scan in the CVE remediation workflow must discover every matching package.json
rather than only fixed roots and lockfile-bearing extensions. Replace the
sequential cd commands with a loop that derives each workspace directory and
runs npm ls <package-name> inside a subshell for that directory, preserving
failures instead of redirecting stderr to suppress them.
| ### 4c. Container image system packages (RPMs) | ||
|
|
||
| Some vulnerabilities target system-level packages installed via RPM/yum in the container image (defined in `build/dockerfiles/`). These are multi-stage builds targeting musl/Alpine, libc-ubi8, and libc-ubi9. | ||
|
|
||
| Run: | ||
| ```bash | ||
| grep -ri "<package-name>" build/dockerfiles/ | ||
| ``` | ||
|
|
||
| If the package is not found in npm or Cargo but appears in the Dockerfiles or is a known system library (e.g. glibc, openssl, curl, krb5), note it as a container-level dependency. | ||
|
|
||
| ### 4d. Cross-reference with the version map | ||
|
|
||
| For each installed version found: | ||
| 1. Check if it falls within any **affected range** from the version map | ||
| 2. If yes, note: | ||
| - The **source** (npm workspace, Cargo, or RPM) | ||
| - Whether it is a **direct** or **transitive** dependency | ||
| - The **parent** that pulls it in (for transitive deps) | ||
| - The **patched version** for that major line from the version map | ||
| 3. If no installed version falls in any affected range → the package is **not vulnerable** |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
Do not infer installed RPM versions from Dockerfile text.
Searching Dockerfiles misses packages inherited from base images and does not reveal the resolved RPM version. The workflow can therefore incorrectly classify a vulnerable container package as absent or unaffected. Scan the built image or its package manifest/RPM database and compare the actual installed version against the advisory range.
🤖 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 @.claude/skills/cve-remediation/SKILL.md around lines 102 - 122, Update the
“Container image system packages (RPMs)” guidance in SKILL.md to require
scanning the built image or its package manifest/RPM database for installed
packages and resolved versions. Do not use Dockerfile searches or infer versions
from Dockerfile text; compare each actual installed RPM version against the
advisory’s affected and patched ranges, while retaining source and dependency
classification where applicable.
| #### 5c. Verification sequence | ||
|
|
||
| After updating `package.json` files: | ||
|
|
||
| 1. **Regenerate lock files** — run `npm install` in each modified workspace root: | ||
| ```bash | ||
| cd code && npm install | ||
| cd code/remote && npm install | ||
| cd code/build && npm install | ||
| ``` | ||
| For extensions with their own lock files: | ||
| ```bash | ||
| cd code/extensions/<name> && npm install | ||
| ``` | ||
|
|
||
| 2. **Verify the fix** — run `npm ls <package-name>` in each modified workspace. Confirm all instances resolve to the patched version. Look for `overridden` markers in the output. | ||
|
|
||
| 3. **Check for remaining vulnerabilities**: | ||
| ```bash | ||
| cd code && npm audit 2>/dev/null | grep -i "<package-name>" | ||
| ``` | ||
|
|
||
| 4. **Warn the user about stale lock files** — if any lock file did not change after `npm install`, check whether the lock file was already up to date or whether the override was not applied. Report any discrepancies. | ||
|
|
||
| All checks must pass before committing. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Fail closed on stale lockfiles and audit errors.
A stale lockfile can cause CI to install the vulnerable version even after package.json is changed, so reporting a warning is insufficient. Also, npm audit only runs from code/ and hides errors. Require every affected workspace’s lockfile to reflect the patched resolution, and stop on install, listing, or audit failures.
🤖 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 @.claude/skills/cve-remediation/SKILL.md around lines 194 - 218, Update the
“Verification sequence” to fail closed: require each affected workspace lockfile
to change or otherwise explicitly verify the patched resolution, and stop the
remediation process on any npm install, npm ls, or npm audit failure. Run audit
checks for every affected workspace rather than only code/, and do not suppress
audit errors; report discrepancies as failures instead of warnings.
| 1. Add a Jira comment: | ||
| ``` | ||
| Automated CVE scan: package "<package-name>" appears to be a system-level (RPM) dependency in the container image, not a direct project dependency. The fix requires a base image update or an explicit package update in the Dockerfile. Manual intervention needed. | ||
| ``` | ||
| 2. Do NOT change the ticket status. | ||
|
|
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Resolve the contradictory Jira-comment rules.
The RPM path requires a Jira comment for manual intervention, while the global notes say to comment only for missing or non-vulnerable packages. Define the RPM behavior explicitly; otherwise these tickets may be left without an actionable Jira record.
Also applies to: 354-359
🧰 Tools
🪛 markdownlint-cli2 (0.23.0)
[warning] 239-239: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 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 @.claude/skills/cve-remediation/SKILL.md around lines 238 - 243, Clarify the
Jira-comment rules in the CVE remediation instructions so the RPM/system-level
dependency path explicitly requires adding the provided manual-intervention
comment, despite the global comment restriction. Preserve the requirement that
RPM cases must not change the Jira ticket status, and align the corresponding
guidance at both referenced sections.
| If `$ARGUMENTS` contains an alert number, fetch that single alert instead: | ||
| ```bash | ||
| gh api /repos/che-incubator/che-code/dependabot/alerts/<NUMBER> \ | ||
| --jq '{number, severity: .security_advisory.severity, relationship: .dependency.relationship, package: .dependency.package.name, manifest: .dependency.manifest_path, ghsa: .security_advisory.ghsa_id, cve: (.security_advisory.cve_id // null), summary: .security_advisory.summary, advisory_url: .security_advisory.permalink, patched: [.security_advisory.vulnerabilities[].first_patched_version.identifier | select(. != null)]}' |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Filter the single-alert path by state too.
The all-alert query selects only open alerts, but the single-alert query omits state. A dismissed or closed alert can therefore proceed through filtering and create a Jira ticket. Include state in the single-alert projection and reject non-open alerts.
🤖 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 @.claude/skills/dependabot-cve-triage/SKILL.md around lines 25 - 28, The
single-alert flow must match the all-alert flow by requiring an open alert.
Update the single-alert gh api projection to include state, then validate that
returned state is open before allowing the alert through filtering or Jira
ticket creation; reject dismissed and closed alerts.
| for dir in $(find . -name "package-lock.json" -not -path "*/node_modules/*" -not -path "*/.build/*" -not -path "*/vscode-reh-web-*" -not -path "*/.rebase/*" -not -path "*/.vscode/*" -exec dirname {} \;); do | ||
| result=$(cd "$dir" && npm ls <package-name> 2>/dev/null) | ||
| [ -n "$result" ] && echo "=== $dir ===" && echo "$result" | ||
| done | ||
| ``` |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- target lines ---'
sed -n '1,140p' .claude/skills/dependabot-cve-triage/SKILL.md
echo '--- search for manifest discovery / npm ls usage ---'
rg -n 'package-lock\.json|package\.json|npm ls|npm ls <package-name>|find \.' .claude/skills/dependabot-cve-triage/SKILL.mdRepository: che-incubator/che-code
Length of output: 7238
🏁 Script executed:
#!/bin/bash
set -euo pipefail
sed -n '180,220p' .claude/skills/dependabot-cve-triage/SKILL.mdRepository: che-incubator/che-code
Length of output: 1255
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
print("Need additional evidence on npm ls semantics; checking docs/search next.")
PYRepository: che-incubator/che-code
Length of output: 233
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
from collections import defaultdict
pkg_json_dirs = set()
pkg_lock_dirs = set()
for p in Path('.').rglob('package.json'):
if any(part in {'.git', 'node_modules', '.build', '.rebase', '.vscode'} for part in p.parts):
continue
pkg_json_dirs.add(str(p.parent))
for p in Path('.').rglob('package-lock.json'):
if any(part in {'.git', 'node_modules', '.build', '.rebase', '.vscode'} for part in p.parts):
continue
pkg_lock_dirs.add(str(p.parent))
only_json = sorted(pkg_json_dirs - pkg_lock_dirs)
only_lock = sorted(pkg_lock_dirs - pkg_json_dirs)
print("package.json dirs:", len(pkg_json_dirs))
print("package-lock.json dirs:", len(pkg_lock_dirs))
print("package.json-only dirs:", len(only_json))
for d in only_json[:50]:
print(" ", d)
print("package-lock-only dirs:", len(only_lock))
for d in only_lock[:50]:
print(" ", d)
PYRepository: che-incubator/che-code
Length of output: 2236
🌐 Web query:
npm ls exit status stdout missing package documentation
💡 Result:
The npm ls command is designed to print the dependency tree of an installed package to stdout [1][2]. Regarding its exit status, the command is intended for programmatic use and will exit with a non-zero status code (typically 1) if it detects dependency issues, such as missing, invalid, or unmet peer dependencies [3][4][5]. It is important to note the following nuances regarding this behavior: 1. Consistency and Evolution: While npm ls generally exits with a non-zero code when problems exist, its specific error-handling logic has evolved across versions [6][5][7]. For instance, older versions of npm sometimes exited with an error code for extraneous packages, whereas newer versions have been updated to treat extraneous packages as non-fatal, meaning they do not trigger a non-zero exit status [5][7]. 2. Handling Exit Status: Because npm ls is used to validate the state of the dependency graph, the non-zero exit code is considered intentional behavior [3]. If you need to run this command in a CI/CD environment or a script where you want to suppress the error code even when issues are found, you can use the OR operator (e.g., npm ls || true) to force a successful exit status [3]. 3. Official Documentation: The official npm documentation focuses on the command's functionality—listing packages and identifying missing, extraneous, or invalid dependencies—but often does not explicitly list every variation of exit codes in the primary command reference page [1][8][9]. Developers typically rely on the CLI's standard behavior of returning non-zero status codes for detected dependency problems to signal failures in build pipelines [3].
Citations:
- 1: https://docs.npmjs.com/cli/v12/commands/npm-ls/
- 2: https://manpages.debian.org/bullseye-backports/npm/npm-ls.1.en.html
- 3:
npm lsreturns an exit code of 1 if it finds unmet peer dependencies npm/npm#17624 - 4: `npm ls` should NOT return an exit code of 1 if it finds unmet peer dependencies npm/rfcs#456
- 5: [BUG]
npm lsfails if there are extraneous packages npm/cli#2664 - 6:
npm ls <pkgname>always exits in error (even when there are no ls problems) npm/cli#1979 - 7: npm/cli@42ca59e
- 8: https://docs.npmjs.com/cli/v9/commands/npm-ls
- 9: https://docs.npmjs.com/cli/v9/commands/npm-ls/
Scan manifest directories, not just package-lock.json trees (.claude/skills/dependabot-cve-triage/SKILL.md:75-79).
This skips package.json-only workspaces, and npm ls should be gated on its exit status rather than stdout because tree output alone doesn’t prove the package is present.
🤖 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 @.claude/skills/dependabot-cve-triage/SKILL.md around lines 75 - 79, Update
the dependency scan loop to find directories containing package.json, while
preserving the existing exclusions and avoiding duplicate directories. In the
npm ls invocation, gate output on a successful exit status rather than non-empty
stdout, so only confirmed package presence is reported.
| curl -s -o /dev/null -w "%{http_code}" -X POST \ | ||
| "https://redhat.atlassian.net/rest/api/3/issue/<ISSUE-KEY>/remotelink" \ | ||
| -u "$JIRA_USER:$JIRA_API_TOKEN" \ |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Do not pass the Jira token in the curl command line.
-u "$JIRA_USER:$JIRA_API_TOKEN" places the expanded secret in the process arguments while curl runs, which can expose it through process inspection or command logging. Use a protected netrc/config file or another credential mechanism that does not put the token in argv, then remove temporary credential material.
🤖 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 @.claude/skills/dependabot-cve-triage/SKILL.md around lines 151 - 153, Update
the remotelink curl invocation in the Jira issue flow to stop passing
JIRA_API_TOKEN through the -u command-line argument. Use a protected temporary
netrc/config or equivalent credential mechanism, ensure curl reads it without
exposing the token in argv, and remove the temporary credential material after
the request completes.
| }' | ||
| ``` | ||
|
|
||
| - **`JIRA_USER`**: Jira account email (e.g. `sbouchet@redhat.com`) |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
Remove the concrete employee email from the committed runbook.
Use a placeholder or service-account example instead of embedding a personal identifier and encouraging human-account credentials for automation.
🤖 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 @.claude/skills/dependabot-cve-triage/SKILL.md at line 166, Replace the
concrete employee email in the JIRA_USER documentation with a non-personal
placeholder or service-account example, keeping the description of the required
Jira account email intact.
| - Always check for existing tickets before creating — duplicate tickets create confusion. | ||
| - The `[dependabot]` suffix in the summary distinguishes these from Product Security-created tickets which use `[rhos_devspaces-X.XX]`. | ||
| - If a Dependabot alert has no CVE ID (only a GHSA ID), skip it — the existing Jira workflow requires CVE IDs for tracking. | ||
| - Respect the same manifest filtering as the CVE remediation skill: skip `.rebase/` paths and `package-lock.json`-only manifests. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Clarify the package-lock exception.
This line says to skip package-lock.json-only manifests unconditionally, while Step 2 says to keep them when the package is direct in the corresponding package.json and rewrite the manifest path. Resolve the contradiction so actionable alerts are not discarded.
🤖 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 @.claude/skills/dependabot-cve-triage/SKILL.md at line 198, Update the
manifest-filtering guidance in the Dependabot CVE triage skill to skip
`.rebase/` paths and package-lock-only manifests only when the package is not
direct in the corresponding `package.json`; retain direct-package alerts and
rewrite their manifest path as required by Step 2.
|
Pull Request images published ✨ Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-756-amd64 |
2 participants
What does this PR do?
this PR introduce two skills.
Needs JIRA MCP correclty configured and github access to security panel
What issues does this PR fix?
https://redhat.atlassian.net/browse/CRW-11156
How to test this PR?
Does this PR contain changes that override default upstream Code-OSS behavior?
git rebasewere added to the .rebase folderSummary by CodeRabbit