JVN fetcher does not consider CPE deprecation status

[kotakanbe]

What did you do? (required. The issue will be closed when not provided.)

Investigated JVN fetcher implementation and found that it does not consider CPE deprecation status.

What did you expect to happen?

JVN fetcher should handle CPE deprecation status appropriately, similar to NVD CPE Dictionary.

What happened instead?

JVN fetcher extracts CPEs from JVNDB vulnerability RSS feeds (Affected Configurations) and registers all of them as non-deprecated.

• Current Output

// fetcher/jvn/jvn.go
for c, t := range cpeURIs {
    fetched.CPEs = append(fetched.CPEs, models.FetchedCPE{...})
}
// fetched.Deprecated is always empty

https://github.com/vulsio/go-cpe-dictionary/blob/master/fetcher/jvn/jvn.go#L52-L57

Problem

Data Source	Source Type	Deprecation Considered
NVD CPE Dictionary	Official CPE Dictionary	✅ Yes
NVD CPE Match	CVE Affected Configurations	❌ No
JVN	JVNDB Affected Configurations	❌ No
Vuls	vuls.json	❌ No (manually defined)

JVN does not provide a CPE Dictionary, so there is no way to determine deprecation status for CPEs fetched from JVN.

Possible Solutions

1. Cross-reference with NVD CPE Dictionary - Only register JVN CPEs that exist in NVD CPE Dictionary (and use NVD's deprecation status)
2. Mark JVN CPEs as "unknown" deprecation status - Requires schema changes
3. Accept current behavior - Document that JVN CPEs do not have deprecation information

Related

• #XX (CPEs from NVD CPE Match are incorrectly registered as non-deprecated)

Configuration (MUST fill this out):

• Go version (go version):

• Go environment (go env):

• go-cpe-dictionary environment:

Hash : ____

• command:

go-cpe-dictionary fetch jvn

[kotakanbe]

Proposed Solution

Use Vendor + Product level to determine deprecation status instead of full CPE URI.

Rationale

1. When NVD CPE Dictionary marks CPEs as deprecated, it's usually due to Vendor or Product name changes (e.g., apache_software_foundation → apache)
2. It's rare for individual versions to be deprecated while the Vendor/Product remains active
3. CPEs from JVN or CPE Match using old Vendor/Product names should be treated as deprecated

Implementation

The CPE#DeprecatedVendorProducts key already exists in Redis, which stores deprecated Vendor/Product pairs.

We can leverage this by modifying IsDeprecated to check both:

1. Full CPE URI match (existing behavior)
2. Vendor/Product match against DeprecatedVendorProducts

func (r *RedisDriver) IsDeprecated(cpeURI string) (bool, error) {
    ctx := context.Background()
    
    // 1. Check full CPE URI match
    result, err := r.conn.SIsMember(ctx, deprecatedCPEsKey, cpeURI).Result()
    if err != nil && err != redis.Nil {
        return false, err
    }
    if result {
        return true, nil
    }
    
    // 2. Check Vendor/Product match
    // Extract vendor and product from cpeURI
    vendorProduct := fmt.Sprintf("%s##%s", vendor, product)
    return r.conn.SIsMember(ctx, deprecatedVPListKey, vendorProduct).Result()
}

This approach would:

• Mark CPEs from JVN/CPE Match as deprecated if their Vendor/Product is deprecated in NVD CPE Dictionary
• Reduce noise from old/renamed vendor names without needing to match exact CPE URIs
• Work without requiring JVN to provide deprecation information

[kotakanbe]

related: #259