Files

master c58a236d70 Doctor plugin checks: implement health check classes and documentation

Implement remediation-aware health checks across all Doctor plugin modules
(Agent, Attestor, Auth, BinaryAnalysis, Compliance, Crypto, Environment,
EvidenceLocker, Notify, Observability, Operations, Policy, Postgres, Release,
Scanner, Storage, Vex) and their backing library counterparts (AI, Attestation,
Authority, Core, Cryptography, Database, Docker, Integration, Notify,
Observability, Security, ServiceGraph, Sources, Verification).

Each check now emits structured remediation metadata (severity, category,
runbook links, and fix suggestions) consumed by the Doctor dashboard
remediation panel.

Also adds:
- docs/doctor/articles/ knowledge base for check explanations
- Advisory AI search seed and allowlist updates for doctor content
- Sprint plan for doctor checks documentation

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

2026-03-27 12:28:00 +02:00

2.8 KiB

Raw Blame History

checkId, plugin, severity, tags

checkId

plugin

severity

Audit Logging

What It Checks

Validates that audit logging is enabled and properly configured for security events. The check inspects configuration under Audit:*, Security:Audit:*, and Logging:Audit:* sections:

Setting	Expected	Issue if not met
`Enabled`	`true`	Audit logging explicitly disabled or not configured
`LogAuthenticationEvents`	`true`	Authentication events not being logged
`LogAdministrativeEvents`	`true`	Admin actions not being logged
`Destination`	Non-empty	Audit log destination not configured

The check also reads LogAccessEvents (data access logging) for reporting, but does not flag it as an issue since it defaults to false and is optional.

If audit logging is explicitly disabled (Enabled: false), the check warns and recommends enabling it. If Enabled is not set at all, it flags this as a potential gap.

Why It Matters

Audit logging is a compliance requirement for security frameworks (SOC 2, ISO 27001, FedRAMP). Without audit logs:

Authentication failures and brute-force attempts go undetected.
Administrative actions (user creation, permission changes, policy modifications) are untraceable.
Incident response has no forensic evidence.
Release decisions and approval workflows cannot be reconstructed.

Stella Ops is a release control plane where every decision must be auditable. Missing audit logs undermine the core value proposition.

Common Causes

Audit logging disabled in configuration
Audit logging configuration not found (never explicitly enabled)
Authentication event logging turned off
Administrative event logging turned off
Audit log destination not configured (logs go nowhere)

How to Fix

Docker Compose

Add audit configuration to environment variables:

environment:
  Audit__Enabled: "true"
  Audit__LogAuthenticationEvents: "true"
  Audit__LogAdministrativeEvents: "true"
  Audit__LogAccessEvents: "true"
  Audit__Destination: "database"

Bare Metal / systemd

Edit appsettings.json:

{
  "Audit": {
    "Enabled": true,
    "LogAuthenticationEvents": true,
    "LogAccessEvents": true,
    "LogAdministrativeEvents": true,
    "Destination": "database"
  }
}

Restart the service:

sudo systemctl restart stellaops-platform

Kubernetes / Helm

Set in Helm values:

audit:
  enabled: true
  logAuthenticationEvents: true
  logAccessEvents: true
  logAdministrativeEvents: true
  destination: "database"

Verification

stella doctor run --check check.security.audit.logging

check.security.secrets — ensures audit log credentials are not exposed
check.core.config.loaded — audit logging depends on configuration being loaded

2.8 KiB Raw Blame History