---
name: cve-intelligence-gathering
description: Gather comprehensive vulnerability information from multiple authoritative sources with fallback strategies
---

# CVE Intelligence Gathering

Systematically collects CVE vulnerability details from multiple authoritative sources, handles search failures, and compiles a comprehensive vulnerability profile for analysis.

## When to Use This Skill

Use this skill when:
- Starting CVE analysis and need complete vulnerability information
- Web searches are returning limited or no results
- CVE is very new and not yet in all databases
- Need to distinguish between authoritative and user-provided information
- Building evidence for security compliance reports

## Prerequisites

### Required
- Valid CVE identifier (format: CVE-YYYY-NNNNN)
- Internet connectivity (recommended but not required)
- `web_search` tool access

### Optional
- User-provided CVE details (fallback when internet unavailable)
- Links to security advisories

## Implementation Steps

### Step 1: Validate CVE Format

```bash
# Regex pattern for CVE ID
CVE_PATTERN="^CVE-[0-9]{4}-[0-9]{4,}$"

# Validate format
if [[ "$CVE_ID" =~ $CVE_PATTERN ]]; then
  echo "Valid CVE format"
else
  echo "ERROR: Invalid CVE format. Expected: CVE-YYYY-NNNNN"
  exit 1
fi
```

**Extract components:**
- Year: `YYYY` from `CVE-YYYY-NNNNN`
- Number: `NNNNN` from `CVE-YYYY-NNNNN`

**Decision Point:**
- IF invalid format → Return error to parent command
- IF valid → Continue to Step 1.5

### Step 1.5: Seed Profile from Jira Context (if available)

If a `jira_context` object was passed in from the `jira-cve-extraction` skill (i.e. the parent command was invoked with `--jira=` or `--jql=`), pre-populate the vulnerability profile before any web searches. This reduces redundant lookups and surfaces internal context that is not available in public databases.

**Fields to extract and pre-populate:**

| Jira field | Profile field | Notes |
|---|---|---|
| `cvss_score` + `cvss_vector` | `severity.cvss_score`, `severity.cvss_vector` | Prefer Jira value; verify against NVD in Step 2 |
| `cwe_id` | `cwe_id` | Cross-check with NVD; flag if they differ |
| `summary` (parsed description) | `description` (supplement) | Internal phrasing may be more specific |
| `affects_versions` | Analysis scope (which project/release versions are affected) | |
| `target_versions` | Fix target / release window | |
| `release_note_text` | `remediation.recommended_action` (supplement) | May already describe the fix or upgrade path |
| `components`, `labels` | Context only | |
| Description body (workaround scan) | `remediation.workarounds` | Already extracted by `jira-cve-extraction` |
| Internal notes from description | `internal_context` field in profile | Capture any previous analysis, conclusions, or decisions noted in the ticket body |

**Mark each pre-populated field as `source: jira`** in the profile.

**Conflict resolution:** If Jira and a public source (NVD, GHSA) disagree on CVSS score or CWE:
- Note both values in the profile
- Prefer the higher CVSS score for risk assessment (conservative)
- Flag the discrepancy as a gap

**Decision Point:**
- IF `jira_context` is null or absent (direct `<CVE-ID>` mode) → Skip this step entirely, proceed to Step 2 as normal
- IF `jira_context` is present → Pre-populate, then continue to Step 2 to fill remaining gaps and verify

### Step 2: Search Primary Sources (NVD and MITRE)

**National Vulnerability Database (NVD)**

```text
Search query: "CVE-{ID} site:nvd.nist.gov"
Example: "CVE-YYYY-NNNNN site:nvd.nist.gov"
```

**Extract from results:**
- CVSS Score (v3.1, v3.0, or v2.0)
- Severity rating (CRITICAL/HIGH/MEDIUM/LOW)
- Base score and vector string
- Affected product/versions
- CWE (Common Weakness Enumeration) ID
- Published date and last modified date

**MITRE CVE Database**

```text
Search query: "CVE-{ID} site:cve.mitre.org"
Example: "CVE-YYYY-NNNNN site:cve.mitre.org"
```

**Extract from results:**
- CVE description (official)
- References (links to advisories, patches, exploits)
- CWE classification
- Assigning CNA (CVE Numbering Authority)

**Error Handling:**
- IF no results from NVD → Try MITRE
- IF no results from MITRE → Try NVD alternative URL pattern
- IF both fail → Continue to Step 3 (Go-specific sources)

### Step 3: Search Go-Specific Sources

**Go Vulnerability Database**

```text
Search queries:
1. "CVE-{ID} golang vulnerability"
2. "CVE-{ID} site:github.com/golang/vulndb"
3. "CVE-{ID} site:go.dev/security"
```

**Extract from results:**
- Affected Go package/module (e.g., `<package-path>`)
- Vulnerable version ranges (e.g., `< <version>`)
- Fixed version (e.g., `<version>`)
- Vulnerable functions/symbols
- Import paths

**GitHub Security Advisories (GHSA)**

```text
Search queries:
1. "CVE-{ID} golang GHSA"
2. "CVE-{ID} site:github.com/advisories"
```

**Look for:**
- GHSA identifier (e.g., `GHSA-xxxx-xxxx-xxxx`)
- Severity from GitHub
- Affected versions
- Patched versions
- Workarounds if available

**Decision Point:**
- IF Go-specific info found → High confidence this is Go-related
- IF only general CVE info found → May not be Go-specific, note this
- IF nothing found → Proceed to Step 4

### Step 4: Search for Remediation Intelligence

**Security Advisories**

```text
Search queries:
1. "CVE-{ID} security advisory"
2. "CVE-{ID} golang fix"
3. "CVE-{ID} patch"
```

**Look for:**
- Official vendor security bulletins
- Fix commits on GitHub
- Release notes mentioning the CVE
- Migration guides for breaking changes

**Community Discussions**

```text
Search queries:
1. "CVE-{ID} golang github issue"
2. "CVE-{ID} golang discussion"
```

**Check for:**
- GitHub issues discussing the vulnerability
- Pull requests with fixes
- Community workarounds
- Discussion on golang-nuts or Reddit

**Proof of Concept / Exploits** (for context only)

```text
Search query: "CVE-{ID} exploit poc"
```

**Note:** Only use for understanding attack vectors, not for testing

### Step 5: Handle Search Failures and Limited Results

**If CVE is Very New (e.g., published recently)**

```text
Search alternative queries:
1. "CVE-{ID} disclosure"
2. "CVE-{ID} advisory {YEAR}"
3. "{PACKAGE_NAME} vulnerability {YEAR}"
```

- It may not be listed in the NVD yet (this can take weeks)
- Check vendor security pages directly
- Look for embargo lift dates
- Note: govulncheck may have it via GHSA before NVD

**If Web Searches Return No Results**

Try alternative strategies:

1. **Search by package name** (if known from context):
   ```
   Search: "{package-name} vulnerability {year}"
   Example: "<package-name> vulnerability <year>"
   ```

2. **Search for GHSA aliases**:
   ```
   Search: "GHSA-{pattern} golang"
   ```

3. **Check package repository directly**:
   ```
   Search: "site:github.com/{org}/{repo} security"
   ```

**Decision Point:**
- IF still no results → Proceed to Step 6 (User Input)
- IF partial results → Continue with available data, mark gaps

### Step 6: Request User Input (Fallback)

If automated searches fail: IF `AUTO_APPROVE=yes` → there is no one to prompt; skip straight to "User Response Handling: no" below (return an error to the parent command). This step is never gated to *proceed* automatically — fabricating CVE details is not a safe default, regardless of how much unattended automation the caller wants. IF `AUTO_APPROVE=no` (or unset — the default) → prompt user:

```text
❌ Unable to fetch details for {CVE-ID} from online sources.

Attempted searches:
- NVD: No results
- MITRE: No results  
- Go vulnerability database: No results
- GitHub Security Advisories: No results

Please provide any information you have about this CVE:

1. CVE Description:
   [What vulnerability does this CVE describe?]

2. Affected Go Packages/Modules:
   [e.g., <package-path>, github.com/<org>/<repo>]

3. Vulnerable Version Range:
   [e.g., all versions before <version>, or versions <version-range>]

4. Fixed Version (if known):
   [e.g., <version> or later]

5. Severity (if known):
   [CRITICAL/HIGH/MEDIUM/LOW or CVSS score]

6. References (if any):
   [Links to security advisories, GitHub issues, etc.]

You can provide partial information. Analysis will proceed with whatever details are available.

Would you like to provide CVE details? (yes/no)
```

**User Response Handling:**
- IF yes → Collect information, mark as "User-provided"
- IF no → Return error to parent command (insufficient data to proceed)

### Step 7: Compile Merged Vulnerability Profile

Merge all gathered information — Jira context (Step 1.5, if present) and public sources (Steps 2–6) — into a single profile. Every field records which source(s) populated it.

```json
{
  "cve_id": "CVE-YYYY-NNNNN",
  "aliases": ["GHSA-xxxx-xxxx-xxxx"],
  "severity": {
    "rating": "<CRITICAL|HIGH|MEDIUM|LOW>",
    "cvss_score": "<score>",
    "cvss_vector": "<CVSS vector string>",
    "cvss_source": "<jira|nvd|ghsa — which source this came from>"
  },
  "affected_packages": [
    {
      "name": "<package-name>",
      "vulnerable_versions": "<version-range>",
      "fixed_version": "<fixed-version>",
      "vulnerable_functions": ["<function1>", "<function2>"]
    }
  ],
  "vulnerability_type": "<vulnerability-type>",
  "cwe_id": "CWE-<number>",
  "attack_vector": "<attack-vector>",
  "description": "<vulnerability description>",
  "impact": {
    "confidentiality": "<NONE|LOW|HIGH>",
    "integrity": "<NONE|LOW|HIGH>", 
    "availability": "<NONE|LOW|HIGH>"
  },
  "remediation": {
    "fix_available": true,
    "recommended_action": "<remediation guidance>",
    "workarounds": ["<workaround from Jira description or public advisory>"],
    "fix_target_versions": ["<target versions from Jira target_versions, if any>"],
    "release_note": "<from Jira release_note_text if present>"
  },
  "internal_context": {
    "jira_ticket": "<PROJ-NNNNN or null>",
    "affects_versions": ["<affected versions from Jira>"],
    "previous_analysis_notes": "<any conclusions or analysis captured in Jira description>",
    "priority": "<Jira priority>",
    "status": "<Jira status>"
  },
  "information_sources": [
    {
      "type": "Jira",
      "verified": true,
      "url": "https://redhat.atlassian.net/browse/<PROJ-NNNNN>"
    },
    {
      "type": "NVD",
      "verified": true,
      "url": "https://nvd.nist.gov/vuln/detail/CVE-YYYY-NNNNN"
    },
    {
      "type": "GitHub Security Advisory",
      "verified": true,
      "url": "https://github.com/advisories/GHSA-xxxx-xxxx-xxxx"
    }
  ],
  "information_completeness": "COMPLETE",
  "data_quality": "HIGH",
  "conflicts": [],
  "gaps": []
}
```

`internal_context` and the `Jira` entry in `information_sources` are only populated when a `jira_context` was passed in (Step 1.5); omit them entirely in direct `<CVE-ID>` mode.

**Mark Information Sources:**
- ✓ "Verified from Jira ticket (internal)"
- ✓ "Verified from NVD"
- ✓ "Verified from MITRE"
- ✓ "Verified from Go vulndb"
- ✓ "Verified from GitHub Security Advisory"
- ⚠️ "Based on user-provided information"
- ⚠️ "Inferred from package repository"
- ⚠️ "Partial information - some fields missing"

**Record conflicts** when Jira and public sources disagree:
```json
"conflicts": [
  {
    "field": "cvss_score",
    "jira_value": "7.5",
    "public_value": "6.5",
    "resolution": "Used higher value (7.5) for conservative risk assessment"
  }
]
```

**Assess Information Completeness:**
- **COMPLETE**: All critical fields populated from authoritative sources
- **MOSTLY_COMPLETE**: Core info available, some details missing
- **PARTIAL**: Only basic info (CVE ID, description, rough severity)
- **MINIMAL**: User-provided or very limited data

**Identify Gaps:**
```json
"gaps": [
  "CVSS score not available",
  "Fixed version not confirmed",
  "Vulnerable functions not identified"
]
```

### Step 8: Determine Go Relevance

**Assess if CVE is Go-related:**

**Strong Indicators (HIGH confidence):**
- Found in Go vulnerability database
- GHSA entry mentions Go/Golang
- Affected package is a Go module
- NVD lists Go as affected product

**Weak Indicators (MEDIUM confidence):**
- Generic web framework CVE that might affect Go
- Library with Go bindings
- Transitive dependency through C libraries

**Not Go-related (Exit early):**
- CVE explicitly for other languages (Python, Node.js, etc.)
- OS/kernel vulnerabilities (unless Go runtime affected)
- Hardware vulnerabilities

**Decision Point:**
- IF clearly NOT Go-related → Return "NOT_APPLICABLE" verdict
- IF Go-related → Continue analysis
- IF unclear → Note uncertainty, continue with caution

## Return Value

Return structured data to parent command:

```json
{
  "skill": "cve-intelligence-gathering",
  "status": "success",
  "cve_profile": {
    "cve_id": "CVE-YYYY-NNNNN",
    "severity": "<CRITICAL|HIGH|MEDIUM|LOW>",
    "cvss_score": "<score>",
    "affected_packages": [...],
    "fixed_versions": [...],
    "description": "...",
    "references": [...]
  },
  "information_quality": {
    "completeness": "<COMPLETE|MOSTLY_COMPLETE|PARTIAL|MINIMAL>",
    "sources": ["<source1>", "<source2>", ...],
    "user_provided": "<true|false>",
    "gaps": []
  },
  "go_relevance": {
    "is_go_related": "<true|false>",
    "confidence": "<HIGH|MEDIUM|LOW>",
    "reasoning": "<explanation>"
  }
}
```

## Error Handling

### Invalid CVE Format
```text
Error: Invalid CVE identifier format
Expected: CVE-YYYY-NNNNN
Received: {user-input}
```
**Action:** Return error, do not proceed

### Network/Search Failures
- Try multiple search strategies
- Fall back to alternative sources
- Request user input as last resort
- Document what was attempted

### CVE Not Found Anywhere
```text
Warning: CVE-{ID} not found in any database
Possible reasons:
- CVE is very new (not yet published)
- CVE ID is incorrect
- CVE was disputed/rejected
- Private disclosure not yet public
```
**Action:** Request user input or exit

### Non-Go CVE
```text
Info: CVE-{ID} does not appear to affect Go
Affected platforms: {list}
```
**Action:** Return NOT_APPLICABLE verdict early

## Example: Complete Workflow

```text
Step 1: Validate
✓ CVE-YYYY-NNNNN - Valid format

Step 2: Primary Sources
✓ NVD: Found - CVSS <score>, Severity: <severity>
✓ MITRE: Found - CWE-<number>, References available

Step 3: Go-Specific Sources
✓ Go vulndb: Found - <package-name>
✓ GHSA: Found - GHSA-xxxx-xxxx-xxxx
  - Affected: <package-name> <version-range>
  - Fixed: <fixed-version>
  - Vulnerable functions: <function1>, <function2>

Step 4: Remediation Intelligence
✓ GitHub Advisory: Update to <fixed-version>
✓ Release notes: <release-notes-url>
✓ Fix commit: <commit-url>

Step 5: Not needed - sufficient data

Step 6: Not needed - sufficient data

Step 7: Compile Profile
✓ All fields populated
✓ Information completeness: COMPLETE
✓ Data quality: HIGH
✓ No gaps identified

Step 8: Go Relevance
✓ Is Go-related: YES
✓ Confidence: HIGH
✓ Package: <package-name>

Result: Complete vulnerability profile ready for Phase 2 analysis
```

## Integration with analyze-cve

This skill is called from Phase 1 of the [analyze-cve](../analyze-cve/SKILL.md) skill.

**Input from parent:**
- CVE identifier (from the `<CVE-ID>` argument, or extracted by `jira-cve-extraction` when `--jira=`/`--jql=` was used)
- `jira_context` object from the `jira-cve-extraction` skill _(optional — only present when `--jira=` or `--jql=` was provided)_
- `AUTO_APPROVE` (`yes`/`no`, default `no`) — governs the Step 6 fallback-prompt gating

**Output to parent:**
- `cve_profile` — merged vulnerability profile (Jira internal context + public sources when Jira mode was used; public sources only otherwise)
- `information_quality` — completeness assessment (noting which fields came from which source)
- `conflict_log` — where Jira and public sources disagreed (empty when no Jira context)
- `go_relevance` — Go applicability determination
- Decision on whether to proceed to Phase 2

**Decision Flow:**
```text
IF status = "error" → Exit command
IF go_relevance.is_go_related = false → Generate "Not Applicable" report, exit
IF information_quality.completeness = "MINIMAL" AND user_declined → Exit command
OTHERWISE → Proceed to Phase 2 with profile
```