Skip to main content

vuls-dictionary

Helm chart for deploying Vuls, an agentless vulnerability scanner for Linux.

How it works

Vuls uses a pre-built SQLite database (vuls-nightly-db) that contains CVE, advisory, and detection data. The database (~7 GB uncompressed) is fetched once via init containers and cached on a PersistentVolume. The vuls server reads it locally at startup, so no outbound network access is needed at scan time.

  1. Init containers pull and decompress the database into /vuls-db/vuls.db
  2. Vuls server starts on port 5515 with a config pointing at the local database
  3. Clients POST their installed package lists and receive vulnerability results

The database is kept on its own PVC, separate from /vuls/results, so database refresh bursts do not consume result-storage headroom. Scan results can be pruned by an init container before the server starts. During migration from older chart versions, legacy /vuls/vuls.db* files are removed from the results PVC to reclaim space.

Components

ComponentDescription
Init containersFetch and decompress the vuls-nightly-db into the PVC
Vuls serverScan server (port 5515) that accepts package lists and returns vulnerability results
Vuls exporterOptional sidecar that reads scan results and pushes them to the Obmondo API via mTLS

Quick start

# values.yaml
vuls2:
enabled: true

vulsServer:
enabled: true

Configuration

Database (vuls2)

ParameterDescriptionDefault
vuls2.enabledFetch the nightly database via init containerstrue
vuls2.image.repositoryDatabase OCI imageghcr.io/vulsio/vuls-nightly-db
vuls2.image.tagDatabase image tag"0"
vuls2.image.pullPolicyImage pull policyIfNotPresent
vuls2.dbPathPath to the decompressed SQLite DB/vuls-db/vuls.db
vuls2.minDbSizeBytesMinimum valid DB size before fetch/decompress is skipped"5368709120"

When enabled, two init containers run before the vuls server starts:

  1. fetch-vuls2-db -- pulls the compressed database via oras
  2. decompress-vuls2-db -- decompresses with zstd

Both init containers skip work if a valid database (>5 GB) already exists on the PVC.

Vuls server

ParameterDescriptionDefault
vulsServer.enabledDeploy the Vuls scan servertrue
vulsServer.image.repositoryVuls server imagevuls/vuls
vulsServer.image.tagVuls server image tagv0.38.6
vulsServer.portListen port5515
vulsServer.resourcesResource requests/limits50m/100m CPU, 256Mi/512Mi
vulsServer.resultsDirDirectory where Vuls writes scan results/vuls/results
vulsServer.databaseStorage.sizePVC size for the vuls2 database25Gi
vulsServer.databaseStorage.accessModeDatabase PVC access modeReadWriteOnce
vulsServer.databaseStorage.storageClassDatabase storage class (empty = default)""
vulsServer.resultsStorage.sizePVC size for scan results15Gi
vulsServer.resultsStorage.accessModeResults PVC access modeReadWriteOnce
vulsServer.resultsStorage.storageClassResults storage class (empty = default)""
vulsServer.resultRetention.enabledPrune old scan result directories at startuptrue
vulsServer.resultRetention.maxAgeDaysDelete result directories older than this many days60

Vuls exporter

Optional sidecar that reads scan result JSON files from the results PVC and pushes them to the Obmondo API using mTLS client certificates.

ParameterDescriptionDefault
vulsExporter.enabledEnable the exporter sidecarfalse
vulsExporter.image.repositoryExporter imageghcr.io/obmondo/vuls-exporter
vulsExporter.image.tagExporter image tag1.0.0-9bd9ca5
vulsExporter.obmondo.urlObmondo API URL""
vulsExporter.intervalPush interval"12h"
vulsExporter.tls.secretNameKubernetes Secret containing TLS client certs""
vulsExporter.tls.certFilePath to client certificate inside the container/etc/ssl/vuls-exporter/tls.crt
vulsExporter.tls.keyFilePath to client key inside the container/etc/ssl/vuls-exporter/tls.key
vulsExporter.tls.caFilePath to CA certificate (optional, omitted if empty)""
vulsExporter.resourcesResource requests/limits20m/50m CPU, 32Mi/64Mi

The TLS secret should contain tls.crt, tls.key, and optionally ca.crt keys. When tls.secretName is empty, TLS is not configured.

Client

Linux hosts run obmondo-security-exporter, a daemon that collects installed packages, sends them to the Vuls server for scanning, and exposes CVE metrics via Prometheus.