# Security Policy

## Reporting a Vulnerability

Please report suspected vulnerabilities privately. Do not open a public issue
for an unpatched security problem.

Send a concise report to **`security@ntbx.io`**.

Include the affected area, reproduction steps, potential impact, and any
suggested mitigation. Avoid including secrets or personal data unless they are
required to explain the issue. No response-time or remediation-time guarantee
is currently offered.

## Supported Versions

This project is an initial scaffold and has no released or supported versions
yet. Define the supported release policy here before the first public
deployment.

## Engineering Security Baseline

The following requirements apply as the Dockerized Django application is
built. They are implementation guardrails, not claims that the corresponding
components already exist.

### Django Settings

- Read `SECRET_KEY`, database credentials, allowed hosts, and other
  environment-specific values from environment variables or a deployment
  secret store.
- Keep debug mode disabled outside local development.
- Configure allowed hosts and trusted CSRF origins explicitly for each deployed
  environment.
- Enable secure cookie, HTTPS redirect, HSTS, and proxy SSL settings as
  appropriate for the production hosting topology.
- Preserve Django's CSRF, escaping, password validation, and clickjacking
  protections unless an exception is documented and reviewed.

### Containers

- Pin base image versions and rebuild images regularly for security updates.
- Run the application as a non-root user where practical.
- Keep images minimal and exclude source-control metadata, local environment
  files, caches, and development-only artifacts with `.dockerignore`.
- Do not publish database or internal service ports unless a documented
  environment requires it.
- Keep development conveniences separate from production configuration.

### Secrets and Dependencies

- Never commit secrets, API keys, private keys, production credentials, or
  populated `.env` files.
- Use separate credentials for local development, tests, staging, and
  production.
- Pin application dependencies with the selected package manager's lock or
  constraints mechanism.
- Review dependency updates and use automated vulnerability scanning when CI is
  introduced.
- Rotate any credential immediately if it is exposed, including exposure in
  version-control history.

### Authentication and Authorization

- Prefer Django's built-in authentication and password hashing facilities.
- Protect administrative routes with strong credentials and restrict access
  further at the network or identity layer where the deployment supports it.
- Enforce authorization checks server-side for every protected action. Do not
  rely on hidden UI controls.
- Add rate limiting or equivalent abuse protection for authentication and
  public write endpoints when those endpoints are introduced.

### Uploads and User-Controlled Content

- Treat filenames, metadata, form fields, URL parameters, and uploaded files as
  untrusted input.
- Validate upload size and content type, generate storage-safe filenames, and
  keep uploaded files outside executable application paths.
- Do not render user-controlled HTML as safe unless it has been sanitized by an
  explicitly selected and tested mechanism.
- Store and serve media according to the chosen deployment platform's security
  model.

### Database and Logging

- Use least-privilege database credentials and avoid exposing the database
  directly to the public internet.
- Back up production data and test the restore procedure once a production
  database exists.
- Do not log passwords, secret values, authentication tokens, or unnecessary
  personal data.
- Record security-relevant failures with enough context to investigate them
  without leaking sensitive information.

### Production Deployment

- Serve the application over HTTPS.
- Keep production debug tooling disabled.
- Apply migrations deliberately during deployment and maintain a rollback or
  recovery plan for risky changes.
- Monitor application errors, suspicious authentication activity, and
  dependency vulnerabilities once operational tooling is selected.
- Document the deployment-specific security configuration before the first
  public release.