K-Guard

GitHub requires 2FA as of March 2023.

GitHub requires explicit manual permission assignment when adding new direct collaborators to the repository. External users are restricted to Read and Fork access by default and cannot modify the authoritative repository without an approved Pull Request.

Branch protection rules are enabled on the main branch, enforcing Pull Request reviews and preventing direct commits.Branch protection rules are strictly enforced on the primary branch via GitHub Settings. Direct commits are rejected; all changes must be proposed, reviewed, and merged through Pull Requests.

GitHub natively prevents the deletion of the repository's default branch. Additionally, the configured branch protection rules explicitly block any deletion attempts on the primary branch by any user.

The project's GitHub Actions CI/CD pipeline relies on strictly bound and sanitized native contexts (e.g., github.sha). It does not dynamically evaluate or execute untrusted external metadata, such as raw Pull Request titles or branch names, within unescaped shell blocks, effectively preventing command injection vulnerabilities.

The project utilizes GitHub Actions, which by default isolates repository secrets. Workflows triggered by Pull Requests from untrusted external forks do not have access to sensitive CI/CD credentials or environment secrets, preventing unauthorized asset exfiltration.

Project URLs use HTTPS exclusively.

Distribution channels use HTTPS exclusively.

The repository enforces a strict .gitignore policy that explicitly excludes .env configuration files, local SQLite databases, and private SSH keys (such as CI_CD_SSH_KEY) from version control. Additionally, GitHub Secret Scanning is active on the repository to automatically detect and prevent the accidental commit of unencrypted credentials.

The project maintains a comprehensive README.md at the root of the repository. It includes clear user guides detailing basic functionality, prerequisite requirements, deployment instructions (via Docker/K3s), and how to navigate the SRE observability and security dashboards.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/KamouloxPelvis/K-Guard/blob/main/SECURITY.md.

GitHub supports public discussions on proposed changes (via pull requests) and usage obstacles (via issues).

The repository includes a dedicated CONTRIBUTING.md file (and/or a section in the README.md) that explicitly outlines the contribution process. It covers how to open issues, submit Pull Requests, and the required code review workflow before merging.

The MIT license for the repository contents is approved by the Open Source Initiative (OSI).

All released software assets, including the built Docker container images and GitHub release archives, are strictly distributed under the same OSI-approved MIT License as the project's source code.

License file found in repository.

The project's LICENSE file is maintained at the root of the source code repository. It is automatically packaged into all distributed release archives and included within the Docker container images, ensuring the license text is always present alongside the release assets.

Repository is publicly available on GitHub.

Repository git metadata is publicly available on GitHub.

The source code repository explicitly tracks direct language dependencies using standard package management manifests. The Python backend utilizes requirements.txt, and the Vue.js frontend relies on package.json, ensuring reproducible builds and enabling automated vulnerability scanning.

The K-Guard project is developed and maintained within a single unified repository (monorepo) that contains the frontend, backend, and infrastructure code. Therefore, this multiple-repository criterion does not apply.

The repository strictly contains source code and configuration manifests. A comprehensive .gitignore file ensures that generated executable artifacts, compiled binaries (e.g., pycache/, dist/), and Docker image layers are excluded from version control. Executable artifacts are dynamically built via the CI/CD pipeline and pushed to a dedicated container registry (GHCR).

The repository is strictly limited to transparent, human-readable source code and configuration files (e.g., Python, TypeScript, YAML, Bash). No unreviewable, opaque binary artifacts or compiled libraries are committed to the version control system, ensuring all code changes can be fully audited.

The project maintains a dedicated SECURITY.md file at the root of the repository. It explicitly provides the security contacts and outlines the responsible disclosure process for reporting potential vulnerabilities to the maintainers.

As this is an obsolete criterion, modern CI/CD environments natively handle this risk. The repository's GitHub Actions workflows strictly utilize safe, built-in context variables (e.g., github.ref_name) and avoid unsafe shell interpolations with raw branch names.