Skip to content

Security: devx/sprout

Security

SECURITY.md

Security Policy

Supported Versions

Sprout is still in the planning and early implementation stage. Until tagged releases exist, security support applies to the default development branch and the most recent unpublished baseline in this repository.

Reporting a Vulnerability

Please do not open public issues for security vulnerabilities.

Use one of these private channels instead:

  • a GitHub private vulnerability report or security advisory, if the repository host supports it
  • your existing private maintainer or support channel for this repository

If neither option is available, contact the project maintainers through a private channel before sharing technical details.

Include:

  • a clear description of the issue
  • affected component or path
  • reproduction steps or proof of concept
  • expected impact
  • suggested mitigation, if known

Disclosure Expectations

  • We will acknowledge receipt as quickly as practical.
  • We will validate impact before public disclosure.
  • We will coordinate a fix and release notes before broad publication when possible.

Security Baseline

Sprout is being designed around these default expectations:

  • human authentication through OIDC-compatible identity providers
  • workload identity and mTLS between services and site agents, with SPIFFE-compatible patterns preferred
  • no long-lived hardware or third-party credentials stored directly in the core data model
  • external secrets integration for BMC credentials, signing keys, and service tokens
  • immutable or append-oriented audit records for sensitive actions
  • signed or attestable artifacts for provisioning workflows where feasible

Out of Scope for the Core Platform

Sprout is not intended to become:

  • a secrets manager
  • a general-purpose endpoint management system
  • a patch or repository management stack
  • a replacement for enterprise identity providers

Responsible Hardening Priorities

Security work should prioritize:

  1. authentication and authorization boundaries
  2. site-agent trust bootstrap and transport security
  3. protection of hardware control paths such as BMC operations
  4. workflow provenance, auditability, and evidence retention
  5. secure handling of boot artifacts and node metadata

Security Review Expectations for Contributors

Changes should call out security impact when they modify:

  • authentication or session handling
  • authorization rules
  • secrets usage or secret references
  • BMC, provisioning, or remote-execution paths
  • audit and evidence pipelines
  • agent registration or site trust bootstrap

There aren’t any published security advisories