Cora-ai

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The repository includes all development work between releases through regular commits to the main and V1-fixes branches. The commit history shows interim development versions, bug fixes, and feature improvements that are available for review before any formal release. The project uses GitHub branches for collaborative development.
URL: https://github.com/Avtr99/Cora-ai/commits/main/

Repository on GitHub, which uses git. git is distributed.

The project uses Git, which provides a unique commit identifier (SHA) for every commit. Each commit represents a distinct version of the project that can be checked out and deployed. This is a valid and accepted form of unique version identification under the OpenSSF criteria.
URL: https://github.com/Avtr99/Cora-ai/commits/main/

Non-trivial release notes file in repository: https://github.com/Avtr99/Cora-ai/blob/main/CHANGELOG.md.

The project has not made any formal releases yet (CHANGELOG shows "[Unreleased]" section). Since there are no releases intended for end users, this criterion is not applicable. The CHANGELOG.md is maintained and will document vulnerabilities once formal releases begin.
URL: https://github.com/Avtr99/Cora-ai/blob/main/CHANGELOG.md

Non-trivial SECURITY[.md] file found file in repository: https://github.com/Avtr99/Cora-ai/blob/main/SECURITY.md. [osps_do_02_01]

The project uses GitHub Issues as its issue tracker. Individual issues are tracked publicly, can be searched, addressed by URL, and include issue templates for bug reports and feature requests.
URL: https://github.com/Avtr99/Cora-ai/issues

The project is currently a new solo-developed project and has not received any bug reports in the last 2-12 months. Therefore, there are no unacknowledged bug reports. The project maintains a GitHub Issues tracker for bug reporting and will respond to all future bug reports promptly.
URL: https://github.com/Avtr99/Cora-ai/issues

The project has not received any enhancement requests in the last 2-12 months. The project uses GitHub Issues for feature requests and will respond to future enhancement requests promptly.
URL: https://github.com/Avtr99/Cora-ai/issues

GitHub Issues and Discussions serve as a publicly available, searchable archive for all bug reports, enhancement requests, and project responses. Each issue is permanently stored and URL-addressable.
URL: https://github.com/Avtr99/Cora-ai/issues

SECURITY.md documents the vulnerability reporting process via GitHub Security Advisories (https://github.com/Avtr99/Cora-ai/security/advisories/new), which serves as the security contact channel. Response commitment: 5 business days. [osps_vm_02_01]

The SECURITY.md policy explicitly instructs users to report vulnerabilities privately using GitHub Security Advisories, which keeps the information private until coordinated disclosure.
URL: https://github.com/Avtr99/Cora-ai/blob/main/SECURITY.md

The project has not received any private vulnerability reports in the last 6 months. The SECURITY.md policy commits to responding within 5 business days if a vulnerability report is submitted.
URL: https://github.com/Avtr99/Cora-ai/blob/main/SECURITY.md

The project includes an automated build system via GitHub Actions CI and Docker Compose. The CI workflow automatically rebuilds the frontend (npm run build), runs Python tests, and builds a Docker image on every push/PR. For local deployment, docker-compose up -d --build rebuilds the entire stack from source. Python backend is interpreted and installed via pip, while the React frontend is built with Vite.
URL: https://github.com/Avtr99/Cora-ai/blob/main/.github/workflows/ci.yml

The project uses standard, common tools: pip for Python dependencies, npm for frontend dependencies, Vite for frontend building, and Docker/Docker Compose for containerized builds. These are widely-used industry-standard tools.
URL: https://github.com/Avtr99/Cora-ai/blob/main/docker-compose.yml

All build tools used are FLOSS: pip (Python package installer), npm/Vite (Node.js ecosystem, MIT/BSD licensed), Docker Engine (Apache 2.0), and GitHub Actions runners. No proprietary build tools are required to build or deploy the software.
URL: https://github.com/Avtr99/Cora-ai/blob/main/requirements.txt

The project uses pytest as its automated test suite. The pytest.ini configuration file defines test discovery, markers, and async test settings. Tests are located in the tests/ directory. The CI workflow runs pytest automatically on every push and pull request. The README and CONTRIBUTING.md document how to run tests.
URL: https://github.com/Avtr99/Cora-ai/blob/main/pytest.ini

Tests are invocable via the standard pytest command for Python. The frontend uses npm run test (vitest) for JavaScript/TypeScript tests. Both are standard invocation patterns for their respective languages and are documented in the CI workflow.
URL: https://github.com/Avtr99/Cora-ai/blob/main/CONTRIBUTING.md

GitHub Actions CI is implemented and runs on every push to main and every pull request. It includes Python linting/tests, frontend lint/build, and Docker image build. The CI ensures that new or changed code is automatically tested when integrated.
URL: https://github.com/Avtr99/Cora-ai/blob/main/.github/workflows/ci.yml

CONTRIBUTING.md states: "Write or update tests as appropriate" as part of the change submission process. This establishes an informal policy that tests should be added when major new functionality is introduced.
URL: https://github.com/Avtr99/Cora-ai/blob/main/CONTRIBUTING.md

The project includes tests in the tests/ directory that correspond to implemented functionality (e.g., test_query_rewriter.py, test_metadata_extractor.py). Recent development includes test files for new components. As the project matures, this practice will continue to be enforced.
URL: https://github.com/Avtr99/Cora-ai/tree/main/tests

CONTRIBUTING.md documents the expectation that contributors write or update tests as appropriate when making changes. This serves as documentation of the test-adding policy within the contribution guidelines.
URL: https://github.com/Avtr99/Cora-ai/blob/main/CONTRIBUTING.md

The project uses ruff for Python linting (configured in pre-commit and CI) and eslint with TypeScript recommended rules for the frontend. TypeScript is configured with recommended compiler checks. These tools identify code quality issues and common mistakes.
URL: https://github.com/Avtr99/Cora-ai/blob/main/.pre-commit-config.yaml

The CI workflow runs ruff and eslint; ruff errors are enforced (CI would fail). The pre-commit hook runs ruff --fix automatically. While eslint has some rules configured as warnings (e.g., react-refresh), the project actively addresses linting issues and does not allow ruff errors in CI.
URL: https://github.com/Avtr99/Cora-ai/blob/main/.github/workflows/ci.yml

The project demonstrates knowledge of secure design principles through its implementation:

• Economy of mechanism: modular, pluggable architecture
• Fail-safe defaults: API key protection disabled by default unless configured
• Complete mediation: security middleware validates all protected paths
• Least privilege: middleware uses minimal permissions
• Limited attack surface: path validation, input sanitization, and security headers
• Input validation: query sanitization, path traversal prevention, filename sanitization
• PII redaction and HMAC-hashed user IDs for privacy
  URL: https://github.com/Avtr99/Cora-ai/blob/main/src/api/middleware/security.py

The project demonstrates awareness of common vulnerabilities:

• Path traversal prevention (validate_path, sanitize_filename)
• XSS prevention (security headers, HTML sanitization via nh3)
• Timing attack prevention (secrets.compare_digest, hashlib.compare_digest)
• Input validation and injection prevention (query sanitization)
• Information disclosure prevention (sanitize_error_message)
• IDOR prevention (JWT-based user authentication)
  URL: https://github.com/Avtr99/Cora-ai/blob/main/src/utils/security.py

The project uses standard, publicly published and peer-reviewed cryptographic algorithms:

• SHA-256 for hashing (NIST-approved)
• HMAC-SHA256 for message authentication
• HS256 (HMAC-SHA-256) for JWT signing
• Python's standard libraries (hashlib, hmac, secrets, jwt)
  URL: https://github.com/Avtr99/Cora-ai/blob/main/src/memory/memory_security.py

The project does not re-implement cryptographic primitives. It uses well-established libraries:

• Python's standard library (hashlib, hmac, secrets) for hashing and random generation
• PyJWT library for JWT operations
• Python secrets module for cryptographically secure API key generation
  URL: https://github.com/Avtr99/Cora-ai/blob/main/src/api/middleware/security.py

All cryptographic functionality uses FLOSS libraries: Python's hashlib, hmac, and secrets modules are open-source, and PyJWT is MIT-licensed. No proprietary cryptographic components are required.
URL: https://github.com/Avtr99/Cora-ai/blob/main/src/memory/memory_security.py

Our JWT tokens use HS256. We enforce that JWT_SECRET_KEY must be at least 32 bytes long before any token is created or decoded, matching the 256-bit minimum recommended for HS256. The validation is implemented in src/api/auth/token_utils.py and is covered by unit tests in tests/test_token_utils.py.

The project does not use broken or deprecated cryptographic algorithms such as MD4, MD5, single DES, RC4, or Dual_EC_DRBG. All hashing uses SHA-256, and JWT uses HS256.
URL: https://github.com/Avtr99/Cora-ai/blob/main/src/config.py

The project uses SHA-256 and HMAC-SHA-256, which do not have known serious weaknesses. It does not use SHA-1 for security-critical operations or CBC mode in SSH.
URL: https://github.com/Avtr99/Cora-ai/blob/main/src/memory/memory_security.py

The project does not implement its own key agreement protocols or TLS termination. It is a self-hosted application that runs behind a reverse proxy (e.g., Nginx, Caddy, or cloud load balancer) which handles TLS. HTTPS is used by GitHub for the repository. The project itself does not manage session key agreements.
URL: https://github.com/Avtr99/Cora-ai/blob/main/docker-compose.yml

The project does not store user passwords. It uses high-entropy API keys (256-bit random tokens) and JWT tokens for authentication. User IDs are anonymized via HMAC-SHA256, not stored as passwords.
URL: https://github.com/Avtr99/Cora-ai/blob/main/src/api/middleware/security.py

The project uses Python's secrets module for generating API keys and other security-sensitive random values. The secrets module is specifically designed to be cryptographically secure. For hashing, it uses standard hashlib functions.
URL: https://github.com/Avtr99/Cora-ai/blob/main/src/api/middleware/security.py

Distribution channels use HTTPS exclusively. [osps_br_03_02]

The project does not retrieve cryptographic hashes over HTTP. Dependencies are installed via pip from PyPI over HTTPS with hash verification (pip install --require-hashes). Docker base images are pinned by SHA256 digest. GitHub Actions artifacts are downloaded over HTTPS. No unsigned hashes are retrieved over insecure channels.
URL: https://github.com/Avtr99/Cora-ai/blob/main/Dockerfile

We use Dependabot security updates (.github/dependabot.yml) for pip, npm, GitHub Actions, and Docker. Our lock files (requirements-core.lock, requirements-ingestion.lock, requirements-ci.lock) are hash-pinned with uv pip compile --generate-hashes and installed in CI with pip install --require-hashes. We verified all 127 GHSA/PYSEC IDs previously reported by Scorecard are patched in the current lock files (e.g., aiohttp>=3.14.1, cryptography>=48.0.1, urllib3>=2.7.0, requests>=2.34.2, starlette>=1.3.1). The remaining two OSV findings are in dev-only packages (diskcache via datasets, ragas) with no upstream patched version available and are tracked as accepted risk.

Critical and high-severity transitive dependencies are pinned to patched minimum versions in requirements-core.txt (see security pin section). Dependabot is configured to open security PRs immediately. CI enforces hash verification. No critical vulnerabilities currently affect production lock files; OSV verification confirms all reported critical/high severity issues in the current resolved dependencies are fixed. The remaining dev-only findings are not exploitable in the production runtime image.

.gitignore excludes all secret file patterns (.env, .env.*, *.pem, *.key, *.p12, .pfx, secrets.json, credentials.json, app_settings.json, service-account.json). A gitleaks pre-commit hook (configured in .pre-commit-config.yaml) scans every commit for leaked API keys, tokens, and credentials before they enter git history. The .env.example file documents required environment variables without containing real values. [osps_br_07_01]

We use GitHub's built-in CodeQL scanning for SAST on every push and pull request to main. This is configured in the repository's security settings and runs independently of the main CI workflow. CodeQL analyzes Python, JavaScript/TypeScript, and other code for security vulnerabilities and code quality issues. We intentionally do not run Bandit in CI because CodeQL already covers the static analysis requirements and Bandit produces false positives for our codebase (JWT token types like "access"/"bearer", Docker binding to 0.0.0.0, etc.).

GitHub CodeQL's default security query suite covers common vulnerabilities including SQL injection, hardcoded secrets, unsafe deserialization, XSS, and insecure cryptographic practices. Our CI also includes npm audit --audit-level=high for frontend dependencies and Dependabot security updates for all ecosystems. Python code is analyzed by CodeQL on every commit.

We use GitHub CodeQL for static analysis. All medium/high severity findings are triaged in the Security tab. Currently open alerts are false positives: SHA-256 is intentional for API key comparison (high-entropy tokens, not passwords), and the API key generator intentionally prints the key to stdout for operator configuration. These have been dismissed with justification. No exploitable medium/high severity issues remain unaddressed

We use GitHub CodeQL for static analysis. It runs automatically on every push and pull request to main through GitHub's built-in code scanning. The CI workflow comment at [d:/Cora ai/.github/workflows/ci.yml](cci:4://file://d:/Cora ai/.github/workflows/ci.yml:0:0-0:0) confirms this: "SAST (CodeQL) runs independently via GitHub's built-in scanning

The project does not produce software in memory-unsafe languages such as C or C++. The codebase is primarily Python and JavaScript/TypeScript, which are memory-safe. Therefore, this criterion is not applicable.

We run pytest as our test suite, which executes Python code with assert statements enabled by default. The CI runs pytest without the -O flag, so assertions are active during testing. This satisfies the criterion for testing with assertions enabled.

The project does not currently run dedicated dynamic analysis tools, so no vulnerabilities have been discovered through dynamic analysis. The criterion is not applicable at this time.
URL: https://github.com/Avtr99/Cora-ai/blob/main/SECURITY.md