Installed OSS CVE Response¶
admin devops
What Nullus does when a CVE is published for the OSS a stack installed (GitLab · Harbor · Argo CD · Keycloak …), and what the stack operator should do about it. It is not a single screen but a flow across the Image Vulnerabilities tab, Notification Channels and the Version Upgrade tab (Stack List).
This is a different promise from Nullus's own images
"A fixable CRITICAL gets a patch release within 24 hours" is the promise for the images Nullus builds itself (API · Web · Jenkins · SonarScanner). The OSS a stack installs are upstream images that Nullus does not rebuild — so they follow the deadlines below, which separate notice from delivering a verified upgrade.
What is scanned¶
If the stack includes the image scanner (Trivy), Nullus scans every image running in the stack
namespace plus the cluster-wide components the stack uses (cert-manager · metrics-server · External
Secrets). It scans once right after install and then every 24 hours (STACK_IMAGE_RESCAN_INTERVAL) —
CVEs published after install show up only on a rescan. When the API restarts, it first scans the stacks
whose last scan is older than the interval.
The results are on the Image Vulnerabilities tab of the stack detail. A row can carry two markers.
| Marker | Meaning |
|---|---|
| Exposed | The image is reachable from outside the cluster — through the gateway (HTTPRoute → Service → pod), or behind a LoadBalancer or NodePort Service (including the stack gateway's Envoy). Hover to see the hosts |
| Shared | A cluster-wide component outside the stack namespace. If the stack reused one that was already in the cluster, patching it is the cluster administrator's job; Nullus only reports it |
A stack without the scanner has no detection
For a stack where Trivy was not selected, the Image Vulnerabilities tab says "Trivy is not selected for this stack, so installed images are not scanned" — that does not mean there are no vulnerabilities. Include Trivy in production stacks.
When you are notified¶
When a rescan finds a fixable CRITICAL that has not been reported yet, Nullus sends one
stack_cve_found per stack to the notification channels.
- Its severity is
criticalif any of them is in an exposed image, otherwisewarning - The message carries up to five CVEs (package installed version → fixed version · image · exposed host); the rest are only counted
- The first notice for a stack reports everything there now at once, labelled as the first notice — for a new stack, what was there at install time; for a stack installed before this event existed, its current state
- A CVE already reported for a stack is not sent for it again — even if one image's scan failed in between and then came back, or a channel failed to deliver (the failure stays in the delivery history)
- HIGH and unfixable vulnerabilities are not sent — see them on the Image Vulnerabilities tab
Channels created before this event existed do not receive it automatically. Edit the channel and tick the event.
Grades and deadlines¶
The machine grades each finding by fix availability · severity · exposure, and a person reviews A and B once more (is the package actually used, is there a known exploit, is there a mitigation).
| Grade | Condition | Notice | Verified upgrade |
|---|---|---|---|
| A | CRITICAL · fix available · exposed | Within 24 hours (critical) |
Within 7 days, or a published mitigation |
| B | CRITICAL · fix available · internal | Within 24 hours (warning) |
Within 30 days or the next regular release, whichever is sooner |
| C | HIGH · fix available | On screen | When template default versions are raised each quarter |
| D | No fix available | On screen | The deadlines above, counted from when a fix appears |
Deadlines count from when the CVE was first reported for the stack. If one is missed, the reason and the next
target date go into the ### Security section of the Nullus release notes.
What to do when you get one¶
- Open the stack from the notice and check which image and which host on the Image Vulnerabilities tab
- Decide whether the package is actually used and whether a mitigation exists (turn the feature off · block the path at the gateway)
- Open the Version Upgrade tab. If a verified upgrade fixes CVEs found in this stack, the row shows Fixes N CVE(s) found in this stack and the dialog lists them
- If there is no verified upgrade, apply a mitigation and watch the
### Securitysection of the Nullus release notes
Verified upgrades exist only for Argo CD for now
Only paths rehearsed on a real cluster can run. Other tools are upgraded through a Nullus release that raises the template default version (a new install) or a documented procedure.
Air-gapped installs¶
Air-gapped installs run the same scan. Images are pulled from the internal registry the bundle pushed
to (the host of NULLUS_HELM_OCI_REGISTRY), and the vulnerability DB is the one imported with the
bundle. So the Image Vulnerabilities tab shows "Air-gapped install — scanned with the vulnerability
DB imported with the bundle" — CVEs published after that import appear only after the next bundle
import.
Notices cannot leave the network, so an email channel through an internal SMTP relay is the
practical choice. The release notes of the air-gap bundle carry Nullus's assessment in ### Security.
Limitations¶
- Exposure is judged from HTTPRoutes and LoadBalancer · NodePort Services. An Ingress added by hand that points at a ClusterIP Service is not seen
- Shared components are found by release label in fixed namespaces (cert-manager · kube-system · external-secrets). A reused one in another namespace, or without that label (a distribution's metrics-server add-on, for example), is not scanned
- There is no direct way yet from a CVE row on the Image Vulnerabilities tab to the upgrade that fixes it — check the Version Upgrade tab