Vulnerability policy

How RigFabTech fixes vulnerabilities in what it ships, and how you can check an image yourself.

Deadlines

Days are calendar days. A known-exploited vulnerability is fixed first, whatever its severity, within 7 days. Its clock starts as below: when RigFabTech learns of it in its own code, and when a fix is available upstream in anything else. The KEV catalog's due date is your deadline, not RigFabTech's: CISA's BOD 26-04, which replaced BOD 22-01, counts it from the day CISA adds the vulnerability, whether or not a fix exists, and sets it by how exposed your own systems are.

Severity is:

• for a finding in an image, the one Grype, the scanner, reports
• for a vulnerability reported to RigFabTech, its CVSS rating

A vulnerability is fixed when a RigFabTech release that contains the fix is available to you. That holds on each minor that still gets security fixes under the support policy.

When the clock starts

• Code RigFabTech writes: when RigFabTech learns of the vulnerability.
• Known-exploited vulnerabilities in anything else, such as a package, a toolchain or an upstream image: when the upstream project releases a fixed version on the release series RigFabTech ships.
• Other vulnerabilities in images RigFabTech builds: when RigFabTech learns of the vulnerability.
• Third-party images, such as PostgreSQL or the CloudNativePG images: when the upstream project releases a fixed version on the release series RigFabTech ships.

A release series is the version line a component is pinned to, such as Python 3.14 or Node.js 24. A fix only in a newer series is a planned upgrade, not a pending fix. A fixed Go or other toolchain doesn't count until the upstream project ships a release built with it.

What a release won't ship

RigFabTech scans every image it builds, and SeaweedFS, which rft-base bundles, when it's built. The image isn't published while it has any of these:

• A known-exploited vulnerability, fixed or not.
• A Critical or High vulnerability that has a fix, in what RigFabTech adds to the upstream images it builds on.
• A Critical or High vulnerability that has a fix, taken from an upstream image, when the newest upstream release in the same release series no longer has it.
• An executable or shared library in what RigFabTech adds that nothing accounts for. See Unaccounted-for binaries.

There are no exceptions: a finding is fixed, not waived. Other findings, findings that appear after the scan, and third-party images such as PostgreSQL and Valkey follow the deadlines above.

Unaccounted-for binaries

A binary the scanner can't identify would otherwise leave no trace in the SBOM or the scan. So every executable or shared library in what RigFabTech adds must be accounted for by either:

• a package in the image's SBOM, or
• a component the image declares, with its CPE and every file it ships, in a CycloneDX build SBOM at /usr/share/sbom/<name>.cdx.json.

What RigFabTech adds is every layer past the base image. The base image is the upstream image, at the digest the build's provenance records, whose layers start the image's. Without one, as in an image built from scratch, what RigFabTech adds is the whole image.

SBOMs

Each image carries its CycloneDX SBOM as a signed attestation in the registry, so your own scanner can read exactly what it holds. To read it and check RigFabTech's signature with the public key from the portal:

cosign verify-attestation --key rft-app-signing.pub --insecure-ignore-tlog=true --type cyclonedx \
  registry.rigfab.com/rft/apps/<PRODUCT>/<IMAGE>@<DIGEST> | jq -r .payload | base64 -d | jq .predicate > sbom.cdx.json

RigFabTech writes nothing to a public transparency log, hence --insecure-ignore-tlog=true.

VEX

Beside its SBOM, each image carries a signed OpenVEX document that tells your scanner what RigFabTech knows about the image's findings:

• not_affected: RigFabTech checked the finding and the image can't be exploited through it, for the reason given in its justification or impact_statement.
• affected: the image is affected; its action_statement says what to do until the fix ships.
• fixed: the finding is fixed in this image.
• under_investigation: a known-exploited, or Critical or High with a fix, finding the scanner reported when the image was released, which RigFabTech fixes within the deadlines above, typically once the upstream release series ships its fix.

Read it with RigFabTech's signature checked, then give it to your scanner:

cosign verify-attestation --key rft-app-signing.pub --insecure-ignore-tlog=true --type openvex \
  registry.rigfab.com/rft/apps/<PRODUCT>/<IMAGE>@<DIGEST> | jq -r .payload | base64 -d | jq .predicate > image.openvex.json
grype registry.rigfab.com/rft/apps/<PRODUCT>/<IMAGE>@<DIGEST> --vex image.openvex.json
trivy image --vex image.openvex.json --show-suppressed registry.rigfab.com/rft/apps/<PRODUCT>/<IMAGE>@<DIGEST>

Both scanners drop not_affected and fixed findings and leave the rest as they are. The document names the image by digest, so it applies to that image wherever you mirror it.

Security advisories

RigFabTech publishes an advisory for each vulnerability it fixes in its own code once the fixed release is available. It publishes it:

• on the advisories page
• in a JSON Feed and an RSS feed
• as a CSAF 2.0 document, the machine-readable format CISA recommends. A CSAF tool such as csaf_downloader, or your vulnerability management system, finds it from provider-metadata.json.
• by email to your technical contacts

Report a vulnerability

Email security@rigfab.com with:

• the platform version
• what you found
• how to reproduce it

RigFabTech acknowledges a report within 2 business days. Keep it private until the advisory is published, or for 90 days.