Docker Image and first iteration

SECURITY.md

@@ -0,0 +1,104 @@
+# 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.