Security

Design

• Least privilege on servers: the inventory user has a minimal, read-only sudoers, and host key fingerprints are pinned at enrolment.
• Short-lived SSH certificates signed by the OpenBao CA instead of per-server keys.
• Secrets by reference: the database only stores references. Values live in OpenBao or are encrypted with AES-256-GCM.
• Separation of duties: the API does not run Ansible or Trivy; the worker cannot read the credential vault; the gateway never receives the application’s secrets.
• Sessions: httpOnly and Secure cookie with CSRF protection, TOTP MFA mandatory for administrators and recent re-authentication for sensitive actions.
• Auditing of user actions.

Deployment best practices

• Put a TLS proxy in front of the web UI and the gateway, and use an https public URL.
• Keep the master keys off the server and never in the same backup as the database.
• Store the OpenBao initialisation material off the server and delete it from there.

Reporting a vulnerability

Summary of the security policy (SECURITY.md) that will ship with the code:

• Supported versions: only the latest release receives security fixes.
• How to report: never in a public issue. Use the repository’s private vulnerability reporting (once public) or email [email protected].
• What to include: affected version, component, steps to reproduce, impact and, if available, a proof of concept.
• Target timelines: acknowledgement within 72 hours, initial assessment within 7 days, and a fix with coordinated disclosure within 90 days.
• Out of scope: insecure self-hosted configurations, attacks requiring administrator access, volumetric DoS, social engineering and already-public dependency vulnerabilities with no InfraWard-specific impact.
• Credit: with your permission, you will be credited in the release notes and the security advisory.