Overview
When a vulnerability affects open source software, there are two parallel worlds to consider. The community project publishes versions and advisories. Enterprise Linux vendors such as Red Hat, Debian, Ubuntu, and SUSE maintain their own vendor builds, often with forks, backports, and internal versioning that do not match community version numbers. Balbix follows the vendor’s advisory for those vendor builds. This avoids false positives and mismatches that arise when community guidance and vendor packaging diverge.
What this means in practice
For community-maintained packages, Balbix uses the community disclosures.
For vendor-maintained Enterprise Linux packages, Balbix relies on the specific vendor advisory. Vendor packaging can split one upstream component into several packages or change names and versions, so the set of affected packages may differ from the community list.
For example, if Red Hat marks a package as affected, Balbix will tag exposure based on Red Hat’s advisory even if NVD lists only the upstream project or has incomplete CPE (Common Platform Enumeration) coverage. Balbix will bring in fix information when the vendor publishes it for the vendor package.
Why names and versions may not match between the community and vendor-maintained packages
Vendor builds can:
Use internal versioning that is not comparable to community releases.
Split functionality across differently named packages.
Backport fixes without bumping to the community’s latest version.
Because of this, a CVE that targets an upstream library may surface in Balbix under one or more vendor package names that do not look like the upstream name or version.
Example: CVE-2025-43964 and Red Hat’s packages
Upstream guidance ties CVE-2025-43964 to LibRaw before 0.21.4. Red Hat’s advisory treats the impact in the context of its vendor packages. In this case, Red Hat flags libraw1394 as affected. NVD may show a CPE for libraw and none for libraw1394. Balbix aligns with Red Hat for RHEL systems, so the exposure appears on the vendor package Red Hat marks as affected. Balbix will add remediation status when Red Hat publishes the fix for that vendor package.
How remediation is determined
Remediation for vendor builds is based on the vendor’s own fixed package release or backport. Upgrading only the upstream project to a community version that NVD recommends is not considered a fix on a vendor distribution unless the vendor has shipped that fix or an equivalent backport in the vendor package.
What you will see in Balbix
Exposure tags follow the vendor package names on Enterprise Linux systems.
You may see exposure on a package that has a different name than the upstream project.
Fix availability updates when the vendor publishes a fixed build or backport.
Rationale
Vendor advisories are the source of truth for vendor distributions. NVD is useful but can be incomplete or out of sync with vendor packaging. Aligning with the vendor avoids inconsistent tagging and misleading fix guidance on enterprise systems.
Scope
This policy applies to vendor-maintained builds on Red Hat Enterprise Linux, Debian, Ubuntu, SUSE, and similar distributions. It does not change how Balbix handles community packages on non-vendor systems.