# Machine-Readable Security Data (SBOM, VEX, GPG)

TuxCare provides machine-readable security data and verification tooling for ELS for Libraries:

• SBOM (Software Bill of Materials) — package composition and dependency inventory in SPDX and CycloneDX formats
• VEX (Vulnerability Exploitability eXchange) — exploitability status for known CVEs in CycloneDX VEX format
• Package signatures (GPG) — detached OpenPGP signatures to verify each artifact's authenticity and integrity
• Integrity violation logging — detecting and retaining integrity-check failures for administrator review

Released fixes are available via tuxcare.com/cve-tracker and security.tuxcare.com.

# Software Bill of Materials (SBOM)

Each package built by TuxCare ships with an SBOM that lists its components, versions, and dependency relationships. SBOMs are provided in industry-standard formats — SPDX and CycloneDX — so they can be consumed by any SBOM-aware scanner or supply-chain tool.

TuxCare generates an SBOM for every package it builds, across all ELS for Libraries ecosystems (Java, JavaScript, Python, PHP, .NET). SBOMs are published to TuxCare Nexus and require credentials. Direct browse repositories are currently available for:

• Java - els-java-sbom
• Python - els_python_sbom
• JavaScript - els-js-sbom

For PHP, .NET, and other ecosystems, reach out to sales@tuxcare.com to check SBOM availability.

# Vulnerability Exploitability eXchange (VEX)

TuxCare publishes VEX as CycloneDX VEX documents, distributed alongside each package version and updated with every release. A VEX document tells you which known CVEs actually affect a given artifact version and which don't, so scanner results stay focused on real exposure.

Feeds are published per ecosystem:

• Java - els_lang_java
• Python - els_lang_python — Python releases iterate as X.Y.Z.postN+tuxcare (e.g. 2021.10.8.post2+tuxcare), not -tuxcare.N
• JavaScript - els_lang_javascript
• PHP - els_lang_php — PHP releases iterate as -pN+tuxcare (e.g. 5.2.28-p1+tuxcare), not -tuxcare.N
• .NET - els_lang_dotnet

Each entry links one CVE to one artifact version and carries a status:

• exploitable — the CVE affects this artifact version and has not yet been patched in this release.
• resolved — the CVE has been patched through a TuxCare release.

Each VEX document reports the CVEs that directly affect the artifact. The feed covers every supported base version and every released -tuxcare.N iteration, so the entry count reflects these combinations rather than the number of unique CVEs. When checking coverage, filter to the artifact versions you actually use — usually the latest -tuxcare.N iteration of your chosen base version. Earlier iterations remain in the feed for historical completeness but aren't relevant once you've adopted a newer release.

# Package Signature Verification (GPG)

Every package TuxCare builds is signed with a detached OpenPGP signature so you can confirm, before installing or updating, that the artifact was produced by TuxCare and has not been altered in transit. The signature is published as a separate .asc file in TuxCare Nexus and is created with TuxCare's signing key (SHA-256 detached signature).

A successful verification proves two things about the artifact:

• Authenticity — it was signed by TuxCare's private key.
• Integrity — its bytes match exactly what was signed; no tampering or corruption occurred.

A failed verification is an integrity violation: the artifact must be treated as untrusted and not installed. Do not work around a failed check by re-downloading over an insecure channel or skipping verification — investigate the source instead.

# Where Signatures Are Published

Signature files are published to TuxCare Nexus and require the same credentials as the package repositories. The repository the .asc lives in varies by ecosystem: Java publishes it alongside the SBOM, JavaScript uses a dedicated signatures repository, PHP uses the els_php_raw_custom1 raw repository, and Python publishes it next to each package in the els_python package repository. See the per-ecosystem steps under Verify a Package for the precise repository and path.

# Obtain the TuxCare Public Key

To verify a signature you first need TuxCare's public signing key. Obtain the key from your TuxCare account, or request it from sales@tuxcare.com or your TuxCare support contact.

Once you have the key file (for example, tuxcare-els-public.asc), import it into your keyring:

gpg --import tuxcare-els-public.asc

Confirm it imported by listing the keys in your keyring:

gpg --list-keys

# Verify a Package

The verification procedure is the same for every ELS for Libraries ecosystem (Java, JavaScript, Python, PHP, .NET): obtain the exact published artifact, download its detached .asc signature from TuxCare Nexus, and run gpg --verify. Select your ecosystem below.

If gpg reports BAD signature, or cannot find the matching public key, treat the artifact as an integrity violation: stop the installation and re-obtain the package and signature from TuxCare over a trusted channel.

# Integrity Violation Events

An integrity violation is any event where an artifact obtained from TuxCare — or the channel it was retrieved over — fails a verification check, indicating the package may not be authentic or may have been altered in transit. The package manager already blocks such an operation (the install or update stops), but by default the only trace is the command's exit code and whatever scrolled past in the terminal. To align with the EU Cyber Resilience Act (CRA), these events should be treated as security-relevant and retained in a dedicated log so a system administrator can review them regardless of when or how the update was triggered.

# What Counts as an Integrity Violation

The ELS for Libraries delivery model is a set of per-ecosystem registries hosted on TuxCare Nexus (an npm registry for JavaScript, a PyPI-compatible index for Python, a Maven repository for Java, a Composer repository for PHP, and a NuGet feed for .NET), served exclusively over HTTPS, plus a detached GPG signature published alongside each artifact. Select your ecosystem for the integrity checks — and therefore the violation types — that apply to it:

# Capturing Integrity Violations in a Dedicated Log

Because these checks run inside the package manager (npm, pip, mvn, composer, dotnet) or gpg, their outcome lives only in the command's exit code and console output. To retain violations for later review — as CRA expects — run the install or verification inside a wrapper that writes the result to a dedicated log, separate from ordinary build output. Doing this in a CI job or an install/deploy script guarantees the event is captured no matter who triggered the update or whether anyone was watching the terminal.

#!/usr/bin/env bash
set -o pipefail
LOG=/var/log/tuxcare-integrity.log

if mvn -C clean install; then
  logger -t tuxcare-integrity -p authpriv.info "OK: mvn build"
else
  rc=$?
  msg="INTEGRITY VIOLATION: mvn build (exit ${rc})"
  echo "$(date -u +%FT%TZ) ${msg}" | tee -a "$LOG"
  logger -t tuxcare-integrity -p authpriv.err "${msg}"
  exit 1
fi

logger hands the event to journald/rsyslog under the tuxcare-integrity tag. To route these events into their own file, add an rsyslog rule:

# /etc/rsyslog.d/30-tuxcare-integrity.conf
:programname, isequal, "tuxcare-integrity"   /var/log/tuxcare-integrity.log
& stop

Reload rsyslog afterwards (systemctl restart rsyslog). To review the captured events through journald instead of a file:

journalctl -t tuxcare-integrity