feat(seal): add vendor support for language file detection.

[DmitriyLewen]

Description

This PR adds support for detecting vulnerabilities in packages provided by Seal Security, a third-party vendor that distributes patched versions of open source packages with their own vulnerability advisories.

Seal Security packages are identified by specific naming patterns (e.g., seal-django, @seal-security/ejs, sealsecurity.io/github.com/...) and maintain a separate advisory database. When Trivy detects a Seal Security package, it now queries the vendor-specific advisory bucket (e.g., seal pip::) instead of the standard ecosystem bucket (e.g., pip::).

Changes

• Added vendor abstraction (pkg/detector/library/vendor.go): Introduced a Vendor interface and vendor registry system to support third-party security vendors
• Implemented Seal Security vendor (pkg/detector/library/vendors/seal/seal.go): Added pattern matching for Seal Security packages across multiple ecosystems:
  • Python (pip): Packages prefixed with seal- (e.g., seal-requests)
  • Node (npm): Packages under @seal-security/ namespace (e.g., @seal-security/ejs)
  • Go: Packages prefixed with sealsecurity.io/ (e.g., sealsecurity.io/github.com/Masterminds/goutils)
  • Java (Maven): Packages with seal.sp1. or seal.sp2. groupId prefix (e.g., seal.sp1.org.eclipse.jetty:jetty-http)
• Updated driver logic (pkg/detector/library/driver.go:116): Modified DetectVulnerabilities to resolve advisory prefix based on vendor matching
• Added comprehensive tests:
  • Unit tests for Seal vendor matching logic covering all supported ecosystems and edge cases
  • Integration test demonstrating end-to-end vulnerability detection for Seal packages
  • Test fixtures for Seal advisory data

Related PRs

• feat(seal): add languages support trivy-db#603

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).