Skip to content

Security Policy

Introduction

Salesforce orgs contain critical data, so we are very serious regarding the security around the use of sfdx-hardis locally or from CI/CD servers.

Supported Versions

Always use the latest sfdx-hardis version to be up to date with security updates.

Supply Chain Security

Continuous Scanning

All development and release workflows contain security checks using Trivy

  • Scan npm package files
  • Scan docker images

Some exceptions has been added in .trivyignore config file, with comments explaining why these CVE are not risky within sfdx-hardis usage.

You can find security scan results and SBOM (Software Build Of Materials) in CycloneDX and SPDX formats in the artifacts of release workflows or directly at the end of the Release notes.

Security artifacts screenshot

Dependencies

We are using dependabot to keep dependencies up to date.

Releases

  • Each release is created using GitHub Release workflows, which are protected by a GitHub Environment requiring at least one manual approval from maintainers (using MFA-protected GitHub Account).
  • NPM Trusted publishers is configured to restrict publishing rights to this specific GitHub action workflow: the low-expiration NPM token used is stored in GitHub Secrets and cannot be used outside of this repository (MFA is also enabled on the NPM account).

Architecture

  • Authentication between sfdx-hardis and Salesforce orgs are performed using a Connect App created during configuration. Each connection requires 2 secured environment variables: one with the connected app Client Id, and one used to decrypt "on the fly" an encrypted self-signed certificate stored in the repository.
  • There is no embedded telemetry: sfdx-hardis maintainers have 0 information about sfdx-hardis command line usage, and it is by design.

Reporting a Vulnerability

In case of detected vulnerability, please write directly to Nicolas Vuillamy on LinkedIn