radix-vulnerability-scanner

Introduction

radix-vulnerability-scanner scans Docker images defined in RadixDeployment CRDs for vulnerabilities, and stores the results in a database. Scanning is triggered whenever new RadixDeployment resources are created or updated, and on a schedule defined by a cron spec. Only images in active RadixDeployments are scanned. Once an image is scanned, it will not be rescanned before the age of the last scan exceeds a certain threshold (defaults to 24 hours).

Installation

radix-vulnerability-scanner installation is handled by Flux using Radix Flux. Flux prerequisites is bootstrapped with Terraforms Vulnerability Scanner module (in each environment)

Azure Resources

radix-vulnerability-scanner stores scan results in a SQL Server database. The database and schema is deployed using Github actions.

Database Permissions

The user configured for connecting to the SQL Server must be member of the radixwriter database role and authenticates with managed identity using Azure ActiveDirectoryDefault profile.

• Run the Vulnerability Scanner Terraform module in each environment to set up Managed Identities.
• Take a note of any changed CLIENT-IDs:
  • radix-id-vulnerability-scan-admin-<ENV> must be added in ./.github/workflows/build-push.yml in this project
  • radix-id-vulnerability-scan-github-<ENV> must be added in ./.github/workflows/deploy-database.yml in this project
  • radix-id-vulnerability-scan-reader-<ENV> must be added in Radixconfig.yaml file for each environment in https://github.com/equinor/radix-vulnerability-scanner-api
  • radix-id-vulnerability-scan-writer-<ENV> must be added in VULNERABILITY_SCANNER_SQL_CLIENT_ID in https://github.com/equinor/radix-flux/blob/master/clusters/development/postBuild.yaml
  • Check #54 for special considerations to deploy roles and external users.

Configuration

Command line arguments

Name	Type	Required	Description	Default
full-sync-cron-spec	string	No	Cron spec defining how often all images should be scheduled for scan	"0 0 * * *"
app-name-exclude-list	string | list	No	Comma separated list of Radix application names to exclude from scanning	""
workers	number	No	Number of concurrent workers to scan images	1
db-server	string	Yes	Name/URL of the SQL Server where scan results are stored	""
db-database	string	Yes	Name of the SQL Server database where scan results are stored	""
vulnerability-scan-timeout	string	No	Context timeout for each image scan	"5m"
vulnerability-rescan-age	string	No	Defines the minimum age of an image scan before a new scan is performed. An image is not scanned if the age of the last scan is less than this value	"24h"
docker-config-file	string	No	Path to docker file with auths for accessing private image repositories	""
kube-config-file	string	No	Path to Kubernetes config file used for accessing K8s API server. InClusterConfig is used if this file is omitted	""

Every command line argument can be specified as an environment variable by prefixing it with RVS_, capitalizing it, and replicaing hyphens (-) with underscores (_), e.g. full-sync-cron-spec becomes RVS_FULL_SYNC_CRON_SPEC.

Development Process

The radix-vulnerability-scanner project follows a trunk-based development approach.

🔁 Workflow

• External contributors should:

  • Fork the repository
  • Create a feature branch in their fork

• Maintainers may create feature branches directly in the main repository.

✅ Merging Changes

All changes must be merged into the main branch using pull requests with squash commits.

The squash commit message must follow the Conventional Commits specification.

Release Process

Merging a pull request into main triggers the Prepare release pull request workflow.
This workflow analyzes the commit messages to determine whether the version number should be bumped — and if so, whether it's a major, minor, or patch change.

It then creates two pull requests:

• one for the new stable version (e.g. 1.2.3), and
• one for a pre-release version where -rc.[number] is appended (e.g. 1.2.3-rc.1).

---

Merging either of these pull requests triggers the Create releases and tags workflow.
This workflow reads the version stored in version.txt, creates a GitHub release, and tags it accordingly.

The new tag triggers the Build and deploy Docker and Helm workflow, which:

• builds and pushes a new container image and Helm chart to ghcr.io, and
• uploads the Helm chart as an artifact to the corresponding GitHub release.

Contribution

Want to contribute? Read our contributing guidelines

Generating mocks

We use gomock to generate mocks used in unit test. You need to regenerate mocks if you make changes to any of the interface types used by the application.

make mocks

Debugging locally

Create a copy of .env.template and name it .env. Set variables to allow local debugging. This file is ignored by git.

Security

This is how we handle security issues