Analysis_Tools

🏷️ Badge & Modal System Reference

Overview

This comprehensive reference documents the complete badge and modal system for CVE analysis, organized into distinct categories serving different data scopes and user workflows. The system uses a consolidated modal architecture where related functionality is grouped into cohesive user experiences rather than scattered individual notifications.

System Organization:

📊 Reference Guide

Table Structure

Each table uses consistent columns to describe badge/modal functionality:

Column Description
Badge Name The visual badge text and modal category
Granular Check Specific condition or data analysis performed
Tooltip or Tab Content Example Tooltip text (hover) vs Tab content (click/view)
Root Cause Owner Who addresses the underlying issue
Dev Handled Processing status (✅ Automated, ❌ Manual, ℹ️ Informational)
Audiences Target stakeholders (👤 Users, 🔧 Developers, 🗃️ Data Providers)

🎯 Modal vs Individual Badge Logic

Modal Badges (Consolidated Experience):

Individual Badges (Immediate Visibility):

👥 Audience Icons

🔍 Badge/Modal Analysis by Category

PLATFORM ENTRY BADGES (Row-Scoped Data)

Table 1: JSON Generation Rules Badge/Modal 🟡

Badge Name Granular Check Tooltip or Tab Content Example Root Cause Owner Dev Handled Audiences
⚙️ JSON Generation Rules Unified modal with up to 3 tabs Tooltip: “JSON Generation Rules detected - Wildcard Generation + Update Pattern Detection (5 transformation(s)). Click for detailed examples.” Tool Development ✅ 👤🔧
→ Tab 1: All Versions Pattern defaultStatus with no versions OR version: “” OR lessThanOrEqual: “” Tab Content: INPUT/OUTPUT JSON transformations showing “defaultStatus: ‘affected’” → CPE base string with vulnerable: true Tool Development ✅ 👤🔧
→ Tab 2: Wildcard Generation Wildcard patterns in version fields expand to ranges Tab Content: INPUT/OUTPUT JSON showing “version: ‘2.’” → “versionStartIncluding: ‘2.0’, versionEndExcluding: ‘3.0’”* Tool Development ✅ 👤🔧
→ Tab 3: Update Pattern Detection Version strings with update patterns normalize Tab Content: INPUT/OUTPUT JSON showing “version: ‘3.3 Patch 1’” → “version: ‘3.3’, update: ‘patch1’” Tool Development ✅ 👤🔧

Table 2: Supporting Information Badge/Modal ⚫

Badge Name Granular Check Tooltip or Tab Content Example Root Cause Owner Dev Handled Audiences
⚫ Supporting Information Unified modal with up to 4 tabs Tooltip: “Supporting Information available - Versions Array Details + CPE Base Strings Searched (3 item(s)). Click for detailed technical insights and debugging information.” Tool Development ℹ️ 👤🔧
→ Tab 1: Versions Array Details CVE Affected CPES Data + Versions Array Structure Tab Content: Formatted display of “2 CPEs detected” with expandable CPE list + “5 version entries” with structured version array Tool Development ℹ️ 👤🔧
→ Tab 2: CPE Base Strings Searched CPE base string processing (used/culled counts) Tab Content: “3 used, 1 culled” with expandable lists showing used CPE strings vs culled ones with reasons Tool Development ℹ️ 👤🔧
→ Tab 3: Data Transformations Source to CPE transformations (curation + unicode) Tab Content: Table showing original→transformed pairs like “MongoDB Inc” → “mongodb”, “Café Server” → “Cafe Server” Tool Development ✅ 👤🔧
→ Tab 4: API Results CPE API query results and error tracking Tab Content: “5 successful, 2 errors” with expandable error details showing specific CPE strings and API error messages Tool Development ℹ️ 👤🔧

Table 3: Source Data Concerns Badge/Modal 🟪

Architecture: Source data concerns use curated platform data with sophisticated skip logic to prevent duplicate issue detection. Two primary problem domains: #1 CPE Base String Determination (vendor/product/platform identification) and #2 Version Parsing and CPE-AS Generation (version processing and match generation).

Badge Name Granular Check Tooltip or Tab Content Example Root Cause Owner Dev Handled Audiences
🟪 🔍 Source Data Concerns (X) Unified modal with dynamic tabs Tooltip: “Source data quality issues detected 5 issues: Placeholder Data, Version Text Patterns Click to view detailed LINT analysis” External Source ❌ 👤🔧🗃️
→ Tab 1: Placeholder Data Detected CPE fields (vendor/product/platforms) + version fields with placeholder values Tab Content: Problem/Data/Resolution format showing detected placeholder patterns and replacement guidance External Source ❌ 👤🗃️
→ Tab 2: Text Comparators Version fields with text-based range indicators Tab Content: Temporal/range pattern analysis with CVE JSON syntax recommendations External Source ❌ 👤🗃️
→ Tab 3: Comparator Patterns Version and CPE fields containing mathematical operators Tab Content: Shows detected operators with syntax guidance for proper range representation External Source ❌ 👤🗃️
→ Tab 4: Whitespace Issues Leading/trailing/excessive whitespace in fields Tab Content: Before/after field content comparison with cleanup guidance External Source ❌ 👤🗃️
→ Tab 5: Invalid Characters Version fields with non-allowed character sets Tab Content: Character validation using allow-list (a-zA-Z0-9-_:.+()~) with examples* External Source ❌ 👤🗃️
→ Tab 6: Version Granularity Inconsistent version part counts within platform groups Tab Content: Base version group analysis showing mixed granularity patterns External Source ❌ 👤🗃️
→ Tab 7: Overlapping Ranges Version ranges with semantic conflicts Tab Content: Range overlap analysis (identical/partial/nested) with consolidation guidance External Source ❌ 👤🗃️
→ Tab 8: All Versions Patterns Version fields containing “all versions” text patterns Tab Content: Pattern analysis showing “all versions” → “” standardization guidance* External Source ❌ 👤🗃️
→ Tab 9: Bloat Text Detection CPE and version fields with redundant/bloat text Tab Content: Vendor redundancy and version prefix removal analysis with examples External Source ❌ 👤🗃️

📋 Implementation Reference: See documentation/source_data_concerns_enhanced_table.md for comprehensive field mappings, exact modal text, data structures, skip logic rules, and code locations.

Table 4: Individual Platform Entry Badges (Non-Modal)

Badge Name Granular Check Tooltip or Tab Content Example Root Cause Owner Dev Handled Audiences
🟢 Confirmed Mappings: X Verified CPE base string mappings available Tooltip: “Confirmed CPE mappings available (3): cpe:2.3:a:mongodb:compass:::::::: Less specific mappings filtered out: cpe:2.3:a:mongodb:::::::::”* Tool Development ✅ 👤🔧
🔴 git versionType git versionType with version ranges (CRITICAL) Tooltip: “CRITICAL: CPE Range Matching Logic does not currently support git versionTypes Detected in version range context” Tool Development ❌ 👤🔧
🟡 git versionType git versionType without version ranges Tooltip: “Versioning based on the git versionType is not advised for CPE Names, consider non-git versioning.” Tool Development ❌ 👤🔧
🔴 CVE Affects Product No Versions No version information + not modal-only case Tooltip: “No versions detected!” (or detailed version check information) Tool Development ℹ️ 👤
🟡 Has Version Changes Version changes/fixes processed Tooltip: “Versions array contains change history information requiring special handling” Tool Development ✅ 👤🔧

CPE BASE STRING BADGES (CPE Base String-Scoped Data)

Table 5: CPE Reference & Provenance Badges/Modals 📋

Badge Name Granular Check Tooltip or Tab Content Example Audiences
📋 CPE Base String References (X) CPE provenance reference data modal Tooltip: “CPE Base String References: 57 references found from NVD CPE API Click for detailed reference information” 👤
→ Dynamic Tabs by Reference Type Reference data organized by type (Vendor, Product, Project, Version, etc.) Tab Content: Each reference type gets its own tab showing URLs with frequency counts, compact display format, and external link functionality 👤

Table 6: CPE Analysis & Confirmation Badges/Modals 📈

Badge Name Granular Check Tooltip or Tab Content Example Root Cause Owner Dev Handled Audiences
📈 Sorting Priority Context Multi-tab CPE analysis modal Tooltip: “Sorting Priority Context available - Statistics + Searches + Versions (4 item(s)). Click for detailed CPE analysis and matching insights.” Tool Development ℹ️ 👤🔧
→ Tab 1: Confirmed Mapping Verified CPE base string mapping by moderators Tab Content: “✓ Confirmed Mapping - This CPE Base String has been verified as a Confirmed Mapping by CPE Moderators” Tool Development ✅ 👤🔧
→ Tab 2: CPE Statistics Statistical analysis of CPE name matches Tab Content: “CPE Base String –> CPE Name Matches (X entries)” with detailed match statistics and filtering information Tool Development ℹ️ 👤🔧
→ Tab 3: Relevant Searches CPE base string search patterns and results Tab Content: Search query analysis showing patterns like “vendor:product” with match counts and relevance scores Tool Development ℹ️ 👤🔧
→ Tab 4: Version Processing Version-specific CPE processing details Tab Content: Version analysis showing processing rules, transformations, and match generation details Tool Development ℹ️ 👤🔧

🎯 Key Implementation Notes

Tooltip vs Tab Content Distinction

Audience-Specific Value

👤 For Tool Users:

🔧 For Tool Developers:

🗃️ For Source Data Providers:

Architecture Notes

CPE Base String References Modal Technical Details

Implementation Approach:

Data Structure:

{
  "Vendor": {
    "total_freq": 134,
    "refs": [
      {"url": "https://example.com/vendor-page", "count": 33},
      {"url": "https://another-vendor-link.com", "count": 25}
    ]
  },
  "Product": {
    "total_freq": 89,
    "refs": [
      {"url": "https://product-page.com", "count": 44}
    ]
  }
}

Tab Generation Process:

  1. Reference Type Sorting: Predefined order (Vendor → Project → Product → Version → ChangeLog → Change Log → Advisory → Unknown)
  2. Frequency-Based Secondary Sort: Within same priority level, sort by total frequency
  3. Dynamic Tab Creation: Each reference type with data gets its own tab
  4. Content Generation: generateReferenceTabContent() creates compact URL displays with frequency badges

Bootstrap Integration:

⚙️ Technical Implementation Details

The badge system uses a two-tier detection approach implemented in the is_modal_only_case() function:

Tier 1 - Modal-Only Detection:

Tier 2 - Complex Cases:

Vulnerable Flag Logic Implementation

The vulnerable flag determination follows a consistent pattern across the system:

// Centralized vulnerability determination (mirrors Python logic)
window.determineVulnerability = function(status) {
    return status === 'affected';
};

// Usage in CPE match generation
const isVulnerable = window.determineVulnerability(versionInfo.status);

Key Pattern: status === 'affected' → vulnerable: true mapping ensures consistent vulnerability assessment across all processing components.

Real CVE Pattern Examples

The system has been validated against production CVE data:

CVE-2024-20515 - Version Granularity Detection:

CVE-1337-99997 - Version Text Patterns:

Overlapping Ranges Detection:

System Architecture Files

JavaScript Components:

Python Components:

Template Integration:

This reference documents the complete badge/modal system implementation as currently deployed.