Sealed Packages Naming Conventions
When we remediate a package, we offer two naming conventions:
Original Alternative: Retain the original package name and simply update the version.
Renamed Alternative: Change both the package name and version to indicate the package is a fork created by Seal Security.
This choice allows flexibility depending on whether the customer wants to have the original package name or not in their Software Bill of Materials (SBOM).
Java
$groupId:$artifactId
$version+sp$X
seal.sp$X.$groupId:$artifactId
$version
(removes +sp$X; +sp999 may be added as sentinel in fixed events)
Javascript
$name
$version-sp$X
@seal-security/$name
$version-sp$X
Javascript (scoped)
@$scope/$name
$version-sp$X
@seal-security/$seal-$name
$version-sp$X
Python
$name
$version+sp$X
seal-$name
$version+sp$X
Ruby
$name
$version.0.1.sp$X
seal-$name
$version.0.1.sp$X
Debian
$name
$version+sp$X
seal-$name
$version+sp$X
RPM
$name
$version+sp$X
seal-$name
$version+sp$X
Alpine
$name
$version-r$REV
seal-$name
$version-r$REV
In rare cases, a vulnerability can't be fully patched without affecting some edge cases. These instances are uncommon, and most customers don't encounter them. However, we can't freely release these versions on the platform, as customers need to be informed about potential side effects and should thoroughly test the updated version.
We manually enable the use of private versions to ensure customers are aware of possible implications. Private versions are identifiable by a pN suffix in their version number. For instance, if the public version is [email protected], the private version would be labeled [email protected] or [email protected], etc.
Last updated
