Handle Vulnerability Disclosures

Vulnerability disclosures are inevitable. Open source dependency maintainer discovers security flaw and publishes CVE. Security researcher reports vulnerability through responsible disclosure program. Internal security testing uncovers weakness. Regardless of source, disclosure triggers urgent workflow: assess impact, determine status, communicate to customers, plan remediation, track to resolution.

The difference between professional and amateur vulnerability handling isn't whether vulnerabilities occur—they always do. It's response speed, communication clarity, and systematic follow-through. Customers evaluate vendors partly on how they handle security problems. Transparent, rapid, systematic vulnerability response builds trust. Delayed, defensive, or chaotic response destroys it. SBOMs and VEX documents enable the professional response customers expect.

Disclosure Triggers

Multiple events can trigger vulnerability disclosure handling workflow:

External CVE publication: NVD publishes CVE affecting open source component you use. OSV database updates with vulnerability in ecosystem package. GitHub Security Advisories adds entry for dependency in your project. External disclosure is most common trigger.

Security researcher report: Researcher contacts you through responsible disclosure program reporting vulnerability in your product or its dependencies. Report may be private advance notice before public disclosure, or may be discovered vulnerability not yet widely known.

Internal security testing: Your security team's penetration testing, code audits, or security research discovers vulnerability in component you use or code you wrote. Internal discovery gives control over disclosure timing but still requires response.

Vendor notification: Vendor whose component you use notifies customers of security issue. Vendor may provide VEX document explaining impact, or may send generic advisory requiring you to assess your specific exposure.

Customer inquiry: Customer asks "Are you affected by CVE-2024-1234?" Customer's own security team noticed vulnerability in component you list in SBOM, wants confirmation about your exposure before taking action.

Initial Assessment Phase

When disclosure occurs, rapid initial assessment determines urgency and required response.

Step 1: Identify Affected Components

Query SBOM repository:

# Search SBOMs for component mentioned in CVE
curl "https://sbom-api.example.com/search?purl=pkg:maven/com.example/vulnerable-lib&version_range=1.0.0-1.2.5" \
  | jq '.affected_products[]'

# Returns list of your products containing vulnerable component version

SBOM inventory transforms "is our product affected?" from multi-day investigation to seconds-long database query. Know immediately which products, which versions, which deployment scenarios involve vulnerable component.

Manual fallback: If SBOM coverage is incomplete, manual investigation required. Check dependency manifests, search codebases, inspect deployed artifacts. Far slower than SBOM query but necessary if inventory gaps exist.

Step 2: Determine Actual Exploitability

Vulnerability existing in component you use doesn't automatically mean your product is exploitable. Context matters.

Code path analysis: Is vulnerable code actually reachable in your application? Library contains vulnerable function, but do you call that function? If vulnerable code path is unused, impact may be negligible.

# Example: Determine if vulnerable code path is used
def analyze_exploitability(component, cve_details):
    """Assess whether CVE affects product given component usage"""

    vulnerable_functions = cve_details['vulnerable_functions']
    product_usage = analyze_component_usage(component)

    reachable = []
    for func in vulnerable_functions:
        if func in product_usage['called_functions']:
            reachable.append(func)

    if len(reachable) == 0:
        return {
            'status': 'not_affected',
            'justification': 'vulnerable_code_not_in_execute_path',
            'detail': 'Product does not invoke vulnerable functions'
        }
    else:
        return {
            'status': 'under_investigation',
            'reachable_functions': reachable,
            'requires_further_analysis': True
        }

Configuration dependencies: Does vulnerability require specific configuration that doesn't apply to your deployment? SQL injection in database driver that only affects specific connection parameters you don't use. Configuration analysis may reveal "affected but not exploitable in our deployment."

Environmental factors: Does vulnerability require attacker access you don't provide? Remote code execution requiring authenticated admin access, but your product doesn't expose that interface publicly. Defense-in-depth measures may mitigate exploitation even if vulnerability theoretically affects you.

Vendor VEX documents: If you use vendor components, check whether vendor published VEX document. Vendor may have already analyzed impact and published not_affected determination with justification. Trust vendor assessment if credible, verify if uncertain.

Step 3: Severity Assessment

Not all vulnerabilities demand same urgency. Prioritize response based on actual risk to your products and customers.

CVSS score consideration: Base CVSS score provides starting point. Critical (9.0+) and High (7.0-8.9) severity warrant immediate attention. Medium (4.0-6.9) requires timely response. Low (0.1-3.9) can be addressed in normal maintenance.

Environmental scoring: Adjust CVSS base score for your specific environment. Vulnerability rated Critical in general but requires configuration you don't use might be Medium in your context. Vulnerability rated Medium but affects internet-facing authentication might be Critical in your deployment.

Exploitation context: Is exploit publicly available? Is exploitation actively occurring in wild? Available exploit elevates urgency—attackers can act immediately. Theoretical vulnerability with no known exploit provides more response time.

Customer exposure: How many customers are affected? Are affected deployments internet-facing or internal? High customer impact and public exposure justify weekend emergency response. Limited impact allows normal business hours handling.

Status Determination

Based on analysis, determine vulnerability status per VEX framework.

Not Affected

Component is present in product but vulnerability doesn't apply due to usage patterns, configuration, or environmental factors.

Justification categories:

vulnerable_code_not_present: Component version in SBOM contains vulnerability, but specific affected code wasn't actually included in build (tree-shaking, dead code elimination).

vulnerable_code_not_in_execute_path: Vulnerable code exists but is never invoked by product functionality.

vulnerable_code_cannot_be_controlled_by_adversary: Vulnerable code executes but attacker cannot influence its inputs or trigger exploitation conditions.

inline_mitigations_already_exist: Product includes compensating controls rendering vulnerability unexploitable (input validation, sandboxing, privilege restrictions).

Example VEX snippet:

{
  "vulnerability": {
    "id": "CVE-2024-1234"
  },
  "products": [
    {
      "id": "product-api-v2.3.0"
    }
  ],
  "status": "not_affected",
  "justification": "vulnerable_code_not_in_execute_path",
  "impactStatement": "Product includes component-x version 1.2.3 which contains CVE-2024-1234 in the advanced querying module. Product does not use the advanced querying module—only basic query functionality is invoked. The vulnerable code path is not reachable through any product feature or API endpoint."
}

Affected

Vulnerability affects product and is exploitable. Remediation required.

Action statements:

{
  "vulnerability": {
    "id": "CVE-2024-5678"
  },
  "products": [
    {
      "id": "product-web-v1.5.2"
    }
  ],
  "status": "affected",
  "actionStatement": "Upgrade to product-web v1.5.3 which includes patched component-y version 3.4.1. Alternatively, apply workaround configuration to disable vulnerable feature (see KB-2024-001).",
  "actionStatementTimestamp": "2024-01-20T14:30:00Z"
}

Affected status requires clear communication about remediation path and timeline. Customers need to know how to protect themselves.

Fixed

Vulnerability previously affected product but has been remediated in newer version.

{
  "vulnerability": {
    "id": "CVE-2024-9999"
  },
  "products": [
    {
      "id": "product-api-v2.2.0"
    }
  ],
  "status": "fixed",
  "detail": "Fixed in product-api v2.3.0 released 2024-01-15. Upgrade to v2.3.0 or later to remediate CVE-2024-9999."
}

Fixed status provides clear upgrade path while acknowledging older versions remain vulnerable.

Under Investigation

Initial assessment incomplete. Requires deeper analysis before definitive determination.

{
  "vulnerability": {
    "id": "CVE-2024-3456"
  },
  "products": [
    {
      "id": "product-mobile-v4.1.0"
    }
  ],
  "status": "under_investigation",
  "detail": "Evaluating impact of CVE-2024-3456 on product-mobile. Initial analysis indicates affected component is present. Determining exploitability in product context. Expect status update by 2024-01-22."
}

Under investigation acknowledges awareness and communicates timeline for definitive answer. Better than silence leaving customers wondering.

Communication Workflow

Vulnerability response requires coordinated communication to multiple audiences.

Internal Communication

Security team alert: Notify security team immediately when vulnerability affects products. Security team coordinates response, assesses priority, allocates resources.

Engineering team notification: Alert development teams owning affected products. Engineers assess exploitability, implement fixes, prepare releases.

Product management briefing: Inform product management about impact on product roadmaps, release schedules, customer communications.

Executive escalation: Critical vulnerabilities warrant executive awareness. CISO and relevant VPs should know about high-severity, high-impact situations.

Customer Communication

Proactive notification: Don't wait for customers to ask. When vulnerability affects your products, notify customers promptly with status assessment.

Communication channels:

• Security advisories page on website
• Email to registered security contacts
• Customer portal notifications
• RSS/Atom feed for automated monitoring
• GitHub Security Advisories (for open source projects)

Communication content:

Subject: Security Advisory: CVE-2024-1234 Impact Assessment

Date: 2024-01-20

Product Security Team

CVE-2024-1234 Vulnerability Assessment

Summary:
CVE-2024-1234 affecting component-x has been published. We have assessed
impact on our products.

Affected Products:
- Product API v2.2.0 and earlier: AFFECTED
- Product Web v1.5.0-1.5.2: AFFECTED
- Product Mobile v4.x: NOT AFFECTED (does not use component-x)

Recommended Actions:
- Product API customers: Upgrade to v2.3.0 (released today) which includes
  patched component-x v1.3.0
- Product Web customers: Upgrade to v1.5.3 (releasing January 22) or apply
  workaround in KB-2024-001

Severity: HIGH (CVSS 8.2)

VEX Documents:
Detailed vulnerability status for all products available at:
https://security.example.com/vex/CVE-2024-1234

Questions:
Contact security@example.com

Updates:
Subscribe to security advisories at https://security.example.com/advisories

Update cadence: Provide updates even if status hasn't changed. "Still investigating, expect update by DATE" is better than silence.

Remediation Planning

Affected status requires remediation plan and execution.

Option 1: Upgrade Vulnerable Component

Simplest path: Update dependency to patched version. component-x@1.2.3 (vulnerable) to component-x@1.3.0 (patched).

Considerations:

• Is patch available? Not all vulnerabilities get patches quickly.
• Is patch compatible? Upgrade might introduce breaking changes requiring application updates.
• Testing requirements? Regression testing needed before deploying upgrade.
• Rollout timeline? Emergency change or scheduled maintenance?

Option 2: Replace Component

If patched version unavailable or incompatible, replace vulnerable component with alternative.

Evaluation:

• Identify functionally equivalent alternatives
• Assess migration effort (API compatibility, feature parity)
• Evaluate alternative component security posture
• Estimate timeline (may be weeks for complex migrations)

Option 3: Apply Workaround

Temporary mitigation while permanent fix is developed.

Examples:

• Disable vulnerable feature via configuration
• Add input validation preventing exploitation
• Deploy WAF rules blocking attack patterns
• Restrict network access to affected components

Communication: Document workarounds clearly. Customers need step-by-step instructions including verification procedures.

Option 4: Accept Risk (Rare)

In exceptional cases, temporarily accept vulnerability risk with explicit approval and compensating controls.

Criteria:

• Exploitation requires conditions that don't exist in deployment environment
• Impact is minimal (information disclosure of non-sensitive data)
• Remediation cost is disproportionate to risk
• Compensating controls adequately reduce risk
• Time-limited acceptance with scheduled remediation

Governance: Risk acceptance requires approval from security leadership and documentation in risk register.

Timeline Targets

Different severities warrant different response timelines.

Critical/High severity, actively exploited:

• Initial assessment: Within 4 hours of disclosure
• Customer communication: Within 24 hours
• Fix availability: Within 72 hours (emergency process)
• Customer deployment: Urgent (coordinate with customers)

Critical/High severity, no known exploitation:

• Initial assessment: Within 24 hours
• Customer communication: Within 48 hours
• Fix availability: Within 7 days
• Customer deployment: High priority, scheduled maintenance

Medium severity:

• Initial assessment: Within 72 hours
• Customer communication: Within 7 days
• Fix availability: Within 30 days
• Customer deployment: Normal maintenance window

Low severity:

• Initial assessment: Within 7 days
• Customer communication: Within 30 days
• Fix availability: Next scheduled release
• Customer deployment: Routine update process

Adjust timelines based on organizational context, but establish clear expectations and measure adherence.

Tracking and Metrics

Systematic tracking demonstrates response effectiveness and identifies process improvements.

Vulnerability response metrics:

Time to assessment: Hours/days from disclosure to definitive status determination. Target: under 24 hours for high/critical, under 72 hours for medium.

Time to customer communication: Hours/days from disclosure to customer notification. Target: under 48 hours for high/critical regardless of status.

Time to fix availability: Days from affected determination to patch release. Target: under 7 days for high/critical, under 30 days for medium.

Communication completeness: Percentage of affected customers notified. Target: 100% via automated notification systems.

VEX publication rate: Percentage of vulnerability assessments documented in machine-readable VEX. Target: 100% for all assessed vulnerabilities.

False negative rate: Vulnerabilities customers discover that you didn't identify through SBOM analysis. Indicates SBOM coverage or analysis gaps. Target: under 5%.

Common Disclosure Handling Mistakes

Mistake: Delayed customer communication Vulnerability affects product but team waits until fix is ready before notifying customers. Customers discover vulnerability independently, feel uninformed by vendor.

Prevention: Communicate early, even with preliminary assessment. "We're investigating CVE-X affecting component we use. Expect definitive status by DATE."

Mistake: Overly defensive communication Downplaying severity, emphasizing why vulnerability is "not really a problem," blaming upstream maintainers. Customers perceive as defensive and untrustworthy.

Prevention: Transparent, factual communication. Acknowledge impact, explain assessment clearly, provide actionable guidance.

Mistake: Inconsistent customer communication Some customers notified via email, others miss notification. No systematic tracking of who received what information.

Prevention: Automated notification system ensuring all customers of affected products receive advisories. Track delivery and provide self-service access to historical advisories.

Mistake: No VEX documentation Assessment performed, customers notified, but no machine-readable VEX published. Customers manually parsing email advisories, cannot automate vulnerability tracking.

Prevention: Publish VEX documents for all vulnerability assessments. Machine-readable format enables customer automation and demonstrates systematic process.

Integration with Incident Response

Severe vulnerabilities may trigger full incident response processes.

Activation criteria:

• Critical vulnerability with confirmed exploitation of customer deployments
• Data breach resulting from vulnerability exploitation
• Widespread customer impact requiring coordinated response
• Regulatory reporting obligations triggered

Incident response integration: Vulnerability disclosure handling team coordinates with incident response team. Shared communication channels, coordinated customer messaging, unified remediation strategy.

Post-incident review: After severe vulnerability incidents, conduct retrospective analyzing response effectiveness, identifying process gaps, implementing improvements.

Next Steps

• Enable rapid assessment through Generate SBOMs
• Document status via Publish VEX
• Communicate to customers using Distribute to Customers
• Learn from real scenarios in Use Cases - Incident Response