Conversation
![baz-reviewer[bot]](https://avatars.githubusercontent.com/in/933528?s=60&v=4){kind=small}
advisories/feed.json
Outdated
| ], | ||
| "exploitability_score": "high", | ||
| "exploitability_rationale": "Medium CVSS score (4.0); requires local access; RCE is critical in agent deployments" |
There was a problem hiding this comment.
The new exploitability_score/exploitability_rationale block added under CVE-2026-27576 (lines 28‑30) is copied verbatim into skills/clawsec-feed/advisories/feed.json and skills/clawsec-suite/advisories/feed.json; all three feeds remain identical. Each new field now needs to be updated in three files, which invites divergence. Can we treat one feed (e.g. the root advisories/feed.json) as canonical and have the other directories pull from it via a sync/copy step or symlink so we only edit one place per CVE? Keeping them synced manually is error-prone.
Finding type: Code Dedup and Conventions
Want Baz to fix this for you? Activate Fixer
| # Handle CVSS v3.x format: "CVSS:3.1/AV:N/AC:L/..." | ||
| if vector_string.startswith("CVSS:3"): | ||
| parts = vector_string.split("/") | ||
| # First part is version, rest are metrics | ||
| for part in parts[1:]: | ||
| if ":" in part: | ||
| key, value = part.split(":", 1) | ||
| metrics[key] = value | ||
|
|
||
| # Handle CVSS v2 format: "(AV:N/AC:L/...)" | ||
| elif vector_string.startswith("(") or "/" in vector_string: | ||
| # Remove parentheses if present | ||
| clean_vector = vector_string.strip("()") | ||
| parts = clean_vector.split("/") | ||
| for part in parts: | ||
| if ":" in part: | ||
| key, value = part.split(":", 1) | ||
| metrics[key] = value |
There was a problem hiding this comment.
The CVSS:3.* branch re‑implements the same for part in parts: if ':' in part: ... loop that's already in the v2 branch, so the parser ends up with two copies of the same parsing logic; can we normalize the vector (strip CVSS:* prefixes and parentheses once) and run a single loop instead to keep the parsing succinct and avoid future drift between the two branches?
Finding type: Conciseness
Want Baz to fix this for you? Activate Fixer
Other fix methods
Prompt for AI Agents:
In utils/analyze_exploitability.py around lines 35 to 52, the parse_cvss_vector function
duplicates the same "for part in parts: if ':' in part: key, value = part.split(':', 1);
metrics[key]=value" logic in the CVSS v3 branch and the v2 branch. Refactor
parse_cvss_vector by normalizing the input first: strip any leading "CVSS:3.x" prefix
and remove surrounding parentheses/whitespace, then split the remaining string on "/"
and run a single loop that extracts key/value pairs into metrics. Remove the duplicated
branch-specific parsing loops so all formats share the same parsing logic while
preserving current behavior.
| # Get high and critical exploitability advisories (most urgent) | ||
| HIGH_EXPLOIT=$(echo "$FEED" | jq '.advisories[] | select(.exploitability_score == "high" or .exploitability_score == "critical")') | ||
| if [ $? -ne 0 ]; then | ||
| echo "Error: Failed to filter by exploitability" | ||
| exit 1 |
There was a problem hiding this comment.
The new “Filter by exploitability score” snippet (lines 393‑397) mirrors the exact same commands that were added to skills/clawsec-suite/SKILL.md (around lines 232‑239). Having two copies of this snippet means every tweak must be made twice and they can drift. Could we pull the shared instructions from a single doc (e.g. the new wiki/exploitability-scoring.md) or otherwise include the snippet once and reference it from both SKILLs so maintenance happens in one place?
Finding type: Code Dedup and Conventions
Want Baz to fix this for you? Activate Fixer
| FEED_PATH="$PROJECT_ROOT/advisories/feed.json" | ||
| SKILL_FEED_PATH="$PROJECT_ROOT/skills/clawsec-feed/advisories/feed.json" | ||
| PUBLIC_FEED_PATH="$PROJECT_ROOT/public/advisories/feed.json" | ||
| ANALYZER="$PROJECT_ROOT/utils/analyze_exploitability.py" | ||
|
|
There was a problem hiding this comment.
FEED_PATH, SKILL_FEED_PATH, and PUBLIC_FEED_PATH are redefined here and the final "sync to other locations" block mirrors the identical configuration + copy logic already living in scripts/populate-local-feed.sh (see its lines 16‑18 and 342‑350). Having the same paths and skill/public feed sync in two scripts means every change must be made twice and makes it easy to forget updating one side when the other evolves. Can we extract the shared feed-path setup and sync-to-skill/public routine into a helper (e.g. scripts/feed-utils.sh or a sourced function) so both scripts reuse the same implementation and stay consistent?
Finding type: Code Dedup and Conventions
Want Baz to fix this for you? Activate Fixer
| const hasMalicious = advisories.some((a) => String(a.type || '').toLowerCase().includes('malicious')); | ||
| const hasRemoveAction = advisories.some((a) => | ||
| /\b(remove|uninstall|disable|quarantine|block)\b/i.test(String(a.action || '')) | ||
| ); | ||
| const hasCritical = advisories.some((a) => a.severity === 'critical'); |
There was a problem hiding this comment.
The hasMalicious | hasRemoveAction | hasCritical | hasHigh | hasHighExploitability checks here duplicate the exact same advisory-risk-decision tree inside skills/clawsec-nanoclaw/mcp-tools/advisory-tools.ts (lines ~303-334). Can we pull that classification/reason logic into a shared helper (e.g. evaluateAdvisoryRisk or a shared evaluateSkillSafety) and call it from both the host-service and the MCP tool so the recommendation strings stay in sync instead of being copy/pasted?
Finding type: Code Dedup and Conventions
Want Baz to fix this for you? Activate Fixer
1 participant
User description
Summary
Added exploitability context for CVE advisories to reduce alert fatigue by providing platform-specific vulnerability assessment. Enhanced advisory feed with exploitability scoring and rationale explaining whether CVEs are actually exploitable in typical OpenClaw/NanoClaw deployments.
Changes Made
exploitability_scorefield (high/medium/low/unknown) to each advisory in feed.jsonexploitability_rationalefield with contextual analysis explaining the exploitability assessmentRelated Issues
Addresses exploitability context enhancement for CVE advisories
Type of Change
Testing
Manual verification of feed.json structure confirms exploitability_score and exploitability_rationale fields are present in advisory records. Workflow changes tested via GitHub Actions execution on poll-nvd-cves.yml and community-advisory.yml.
Checklist
Generated description
Below is a concise technical summary of the changes proposed in this PR:
Enhances the CVE advisory feed with exploitability context to reduce alert fatigue by providing platform-specific vulnerability assessments. Introduces an automated
analyze_exploitability.pyutility and updates GitHub workflows and NanoClaw MCP tools to surface these scores for better prioritization.poll-nvd-cves.yml,community-advisory.yml) to automatically compute exploitability scores and rationales for new and updated CVEs, along with a script to backfill existing advisories.Modified files (4)
Latest Contributors(2)
Modified files (1)
Latest Contributors(0)
exploitability_score, while enhancing theevaluateSkillSafetylogic to block or recommend review of installations based on exploitability context. This includes changes to data interfaces, core advisory logic, and installation documentation.Modified files (8)
Latest Contributors(2)
Modified files (10)
Latest Contributors(2)