Skip to main content

Security Hygiene

Frameworks, practices, and procedures​

Cadence maintains basic project health and security with contribution controls, automated CI gates, and vulnerability monitoring. Across all cadence-workflow projects:

  • Contribution controls: every commit needs a Developer Certificate of Origin sign-off. Organization members can instead satisfy the requirement with a GPG-signed commit. PR titles must follow Conventional Commits, and branch protection requires approving reviews, with force pushes blocked. The CODEOWNERS file lists all maintainers as owners of the whole repository. The cadence-workflow GitHub organization requires two-factor authentication for all members.
  • Static analysis: make lint runs in CI on every PR via ci-checks.yml. It runs go vet -copylocks, revive with the repository's revive.toml, and nilaway scoped to the type mapper packages. The project does not use golangci-lint or staticcheck.
  • Vulnerability scanning: Cadence uses Snyk to scan dependencies for known CVEs, check licenses, scan container images, and analyze the Go source (Snyk Code). It also opens remediation pull requests. The project disabled GitHub's Dependabot because its default alerting threshold was too noisy. Snyk is currently tuned to raise PRs only for critical-severity vulnerabilities.
  • Vulnerability disclosure: security issues are reported privately through GitHub Security Advisories under the project's security policy. Security fixes are backported to releases from the last two years.

Within the cadence-workflow/cadence repository:

  • Dependency freshness: the fresh-go-deps-check workflow blocks pull requests that pin a Go module dependency published too recently. This reduces exposure to compromised or unvetted releases that land right after publication.

Cadence does not currently run govulncheck, CodeQL, or OpenSSF Scorecard in CI, and does not publish an SBOM. These are known gaps and are not on the roadmap today.

Evaluating feature risk if unmaintained​

The project has no formal, documented process for deciding which features become a security risk if they go unmaintained. Maintainers handle this case by case, through review during PR discussion and through deprecation notices in RELEASES.md when a feature or configuration path is phased out. A more structured process, such as explicitly flagging experimental config options and legacy persistence or authorization paths, is a candidate for future work alongside the AuthN and AuthZ hardening described on Cloud Native Security Tenets.