Home / Docs / Security Posture

Security Posture 🛡️

Classification: Public
Owner: Raziel (CISO)
Last updated: 2026-03-05
Audience: Anyone — customers, auditors, contributors, curious people

This document describes how AnisminOS approaches security at a high level. It is intentionally non-technical in places — if you're a developer looking for implementation guidance, see the Developer Security Guide.

Principles

AnisminOS is built on these security fundamentals:

  • Defense in depth — multiple independent controls, not a single gate
  • Least privilege — every component gets only the access it needs, nothing more
  • Assume breach — we design as if attackers are already inside; contain the blast radius
  • Security by default — new features are locked down first, opened up intentionally
  • Transparency — we document what we do and why, including gaps we're working on

Authentication & Access Control

Human Users

  • Password authentication with bcrypt hashing (no plaintext storage)
  • Optional TOTP-based two-factor authentication per account
  • Sessions are cryptographically signed and device-bound (IP + User-Agent fingerprint)
  • Automatic idle session expiry
  • Brute-force protection via rate limiting on login attempts
  • Administrators can remotely invalidate sessions

Programmatic / Agent Access

  • All API calls require a per-agent bearer token
  • Tokens are encrypted at rest using AES symmetric encryption
  • Each agent has an explicit permission scope — no agent has access outside its lane
  • Permission changes require CISO approval
  • Tokens are never logged, never committed to source control

Role-Based Access Control

Access is granted per-capability, not per-role alone. Permissions are explicitly defined for each agent/service and audited periodically.

Transport Security

  • All traffic is served over TLS — plaintext connections are rejected
  • HSTS enforced with a one-year max-age, including subdomains
  • Database connections require TLS (sslmode=require) — plaintext DB connections are rejected at the driver level

Security Headers

Every HTTP response includes:

Header Purpose
Strict-Transport-Security Forces HTTPS; prevents downgrade attacks
X-Frame-Options: SAMEORIGIN Prevents clickjacking via iframes
X-Content-Type-Options: nosniff Stops MIME-type sniffing attacks
Referrer-Policy Limits referrer header leakage
Permissions-Policy Disables camera, mic, geolocation, payment APIs
Content-Security-Policy Restricts resource origins to self
Server: AnisminOS Hides underlying framework/version information

Database Security

  • Application connects using a least-privilege database role with only DML access (SELECT, INSERT, UPDATE, DELETE)
  • No DDL privileges (CREATE, DROP, ALTER) for the application role
  • Superuser access is reserved strictly for administrative operations and is never used by the running application
  • Credentials are loaded from environment variables — never hardcoded

CSRF Protection

All HTML form endpoints are protected with session-based CSRF tokens using timing-safe comparison. JSON API endpoints are protected by requiring an authenticated agent token (cross-origin JSON requires a CORS preflight, providing equivalent protection).

Integrity & Intrusion Detection

  • File integrity monitoring runs daily — checks cryptographic hashes, permissions, and ownership across critical system paths
  • Rootkit scanning runs weekly — scans for known backdoors, suspicious binaries, and configuration weaknesses
  • Both controls are independent of the application layer

Secrets Management

  • Secrets are never hardcoded in source code
  • All secrets are loaded from environment variables at runtime
  • Agent tokens are encrypted at rest
  • Access to secret files is restricted by filesystem permissions (owner-only)
  • Secret rotation procedure exists and is documented internally

Incident Response

If you believe you've found a security vulnerability:

  1. Do not post it publicly (forums, social media, etc.)
  2. Report privately — contact the CEO directly via Telegram or email
  3. Include: what you found, how to reproduce it, potential impact
  4. We will classify the severity and respond with a remediation timeline
  5. We follow responsible disclosure — we'll coordinate a public disclosure date with you

For confirmed incidents, our process is: isolate → investigate → contain → remediate → document → disclose (if applicable).

Known Gaps (We Believe in Honesty)

We track open security items transparently. Current known gaps:

Gap Risk Level Status
CSP permits unsafe-inline for scripts/styles Medium In progress — requires nonce implementation
File integrity alerts not forwarded to real-time monitoring Medium Planned

We don't hide gaps. If we find something, we track it, own it, and fix it.

What We Don't Do

  • We do not sell or share user data with third parties
  • We do not log sensitive input (passwords, tokens, secrets)
  • We do not use shared credentials across services
  • We do not deploy without a security review for auth-touching changes

Questions?

Security questions, concerns, or responsible disclosure: contact the CEO or Raziel (CISO) directly.