The Lupaxa Project is committed to building secure, reliable, and trustworthy open-source software. This document outlines our security principles, architecture, processes, and the responsible disclosure policy for reporting vulnerabilities.

Security is a fundamental part of all Lupaxa tooling and services.

We follow a Security by Design approach based on:

• Least privilege
• Minimal trust boundaries
• Secure defaults
• Separation of duties
• Auditable automation
• Secure development lifecycle (SDL) practices

Our goal is a secure ecosystem where contributors, users, and automated systems interact safely.

The Lupaxa Project employs a layered security architecture across infrastructure, automation, and development workflows.

To limit blast radius and maintain strong separation, we use:

• Multiple GitHub organisations (tooling, libraries, infrastructure, private repos)
• Strictly partitioned privileges across organisations
• No shared secrets or cross-organisation trust relationships
• Scoped permissions on all automation and API tokens

Security responsibilities and decision-making are aligned with the organisation-wide governance model:

• Governance
• Maintainers

These documents describe who is responsible for security-related decisions and how changes to security posture are approved across Lupaxa repositories.

All repositories enforce:

• Protected master branches
• Verified status checks
• Require-review policies
• Mandatory code review for dependency updates
• Reusable hardened workflows across organisations
• No secrets available to forked PRs

Our workflows implement defence-in-depth:

• SHA-pinned third-party actions
• Permission minimisation (token and job-level)
• Restricted trigger conditions
• Guardrails for forked PRs
• Slug/ref validation to protect from spoofing
• Secure notifications that avoid leaking metadata
• Reusable workflows for consistent security enforcement

We maintain strict control of our supply chain:

• Mandatory review of all dependency updates
• Dependabot monitoring across all repos
• No introduction of dynamic code execution dependencies without approval
• Licence scanning for new dependencies
• Integrity checks and reproducible builds where possible

• No secrets are stored in source control
• Secrets are scoped per repo and use minimal privilege
• Automated rotation for short-lived tokens
• No plaintext secrets in automation logs
• Secrets never exposed to untrusted workflows
• Strong separation between public and private repositories

All contributors are expected to follow:

• Prefer safe, explicit patterns
• Validate all input and external data
• Avoid unnecessary complexity, implicit behaviour, or side effects
• Use modern secure language features (e.g., Python 3.13, strict typing, safe defaults)

Every change must undergo review, including:

• Dependency updates
• Security-relevant code paths
• Configuration changes
• GitHub Actions or workflow updates
• Documentation that affects operational behaviour

We employ:

• Ruff for linting
• Mypy for type-checking
• Pytest for tests
• Security-focused CI gating
• Automated test coverage for core logic

If a security issue is suspected, observed, or confirmed, we follow the structured incident response workflow below.

All incidents are classified into severity levels:

• Critical: Active exploitation or remote unauthenticated impact
• High: Privilege escalation or major information exposure
• Medium: Limited-scope exposure or misuse potential
• Low: Hardening gaps, misconfigurations, or informational issues

Depending on severity:

• Disable affected workflows
• Revoke exposed tokens
• Quarantine affected infrastructure
• Freeze releases or merges
• Patch vulnerable components

• Apply fixes or remove compromised components
• Rebuild from trusted sources
• Rotate keys/tokens
• Validate via testing and review
• Resume normal operations

We conduct a blameless review covering:

• What happened
• How it happened
• How it was detected
• Why controls permitted it
• Improvements for prevention

A summary may be published for transparency if appropriate.

We greatly appreciate responsible disclosures from the security community.

If you discover a vulnerability:

Please email us directly: security@thelupaxaproject.org

Include:

• A clear description of the vulnerability
• Steps to reproduce
• Potential impact
• Any proof-of-concept or logs
• Whether the issue is public or privately disclosed

Do not create a public GitHub issue.

This protects users from premature exposure.

We aim to:

• Acknowledge within 48 hours
• Provide an initial assessment within 5 working days
• Deliver a remediation plan shortly after triage
• Coordinate public disclosure (if applicable) once a fix is available

All contributors should:

• Use 2FA on GitHub
• Avoid committing secrets
• Use signed commits wherever possible
• Keep dependencies updated locally
• Run tests before pushing
• Follow coding standards and review expectations

While we take security extremely seriously, The Lupaxa Project provides software "as-is" with no warranties.

Users deploying our tools in production are responsible for:

• Hardening their environment
• Managing secrets
• Performing their own security assessments
• Ensuring compliance with organisational or regulatory requirements

For all security enquiries, disclosures, or concerns:

Email: security@thelupaxaproject.org

© The Lupaxa Project.
Where exploration meets precision.
Where the untamed meets the engineered.