xav-portfolio/SECURITY.md

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.