corvus

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.

Development happens in the public Git repository between releases: every change is a pull request with its own commits and CI results (https://github.com/corvus-gateway/corvus/pulls?q=is%3Apr), merged to main before being tagged in a release. The repository contains interim versions, not only final releases.

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

Every release has a unique version identifier: a Git tag (e.g. v1.0.0), a GitHub Release, and the matching container image tag (ghcr.io/corvus-gateway/gateway:1.0.0). The version is also embedded in the binary and shown in the admin console.

Each release is identified by a Git tag (v1.0.0): https://github.com/corvus-gateway/corvus/tags. Pushing a v* tag triggers the release workflow that builds, tests, signs and publishes the image.

Each release has hand-written release notes on GitHub Releases summarising highlights, installation and upgrade steps, and image/verification details (not a git log): https://github.com/corvus-gateway/corvus/releases/tag/v1.0.0

N/A: no publicly known vulnerabilities (CVE or similar) have been reported or fixed in Corvus itself so far. When one is fixed, it will be listed in the release notes and published as a GitHub security advisory, as stated in SECURITY.md.

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

GitHub Issues is used to track individual bugs and enhancement requests: https://github.com/corvus-gateway/corvus/issues

The project was published recently and has not yet received bug reports from users; all reports submitted via GitHub Issues are acknowledged by the maintainer.

The project was published recently and has not yet received enhancement requests; all requests submitted via GitHub Issues are answered by the maintainer.

All reports and responses are kept in GitHub Issues, which is public and searchable (including closed issues): https://github.com/corvus-gateway/corvus/issues?q=is%3Aissue

The vulnerability reporting process is published in SECURITY.md (also shown in the repository's Security tab): https://github.com/corvus-gateway/corvus/blob/main/SECURITY.md

Private reports are sent through GitHub private vulnerability reporting, which is enabled for the repository and described in SECURITY.md; reports are visible only to the maintainers: https://github.com/corvus-gateway/corvus/security/advisories/new

No vulnerability reports have been received in the last 6 months. SECURITY.md commits to an initial acknowledgement within 7 days, well within the 14-day requirement.

A working, automated build is provided: docker build -f deploy/Dockerfile . rebuilds the complete image from source (admin UI with npm, control plane with Go, OpenResty from signature-verified sources). Parts build with npm --prefix web run build and go build ./control/... (CONTRIBUTING.md). The same build runs in CI and in the release workflow.

Only common build tools are used: Docker (BuildKit), the standard Go toolchain, npm with Vite, and the standard OpenResty/nginx configure-make build.

Builds with FLOSS tools only: Go, Node.js/npm, Vite, GCC/make on Alpine Linux, Docker Engine/BuildKit.

Automated tests are in the repository under Apache-2.0: Go unit and fuzz tests (go test ./control/...) and an integration suite against a running gateway (deploy/dev/itest.sh). How to run them is documented in CONTRIBUTING.md (https://github.com/corvus-gateway/corvus/blob/main/CONTRIBUTING.md#development-setup) and in .github/workflows/ci.yml.

The Go test suite runs with the standard go test ./... command; the integration suite is a single script, deploy/dev/itest.sh.

Unit tests cover the rules engine and validation, authentication (sessions, MFA, password hashing), the configuration compiler, managed-rule signature verification and the NPM import; gateway behaviour (proxying, TLS, security rules, rate limits, access queue, logging) is covered by the integration suite.

GitHub Actions runs the tests on every pull request and push to main (.github/workflows/ci.yml, security.yml, CodeQL); merging to main requires the go, web and lua checks to pass.

CONTRIBUTING.md states that new functionality must come with automated tests: https://github.com/corvus-gateway/corvus/blob/main/CONTRIBUTING.md#pull-requests

Recent changes added tests with them, e.g. bcrypt password hashing (TestHtpasswdHashIsBcrypt) and fuzz targets for IP lists, rule regexes and bundle signatures (FuzzIPList, FuzzRuleRegex, FuzzVerify).

Documented in CONTRIBUTING.md "Pull requests": https://github.com/corvus-gateway/corvus/blob/main/CONTRIBUTING.md#pull-requests

go vet for Go, TypeScript in strict mode (tsc as part of the web build), luac -p for Lua, all run in CI; CodeQL runs on every change.

CI fails on vet and TypeScript errors, and pull requests cannot be merged until the checks pass.

TypeScript strict: true, go vet, and the CodeQL security-extended query suite.

The maintainer applies secure design principles: least privilege (unprivileged container user, optional read-only hardened variant with all capabilities dropped), fail-safe defaults (admin console on a separate port with a network allowlist, setup token for first admin), complete mediation (every API call authenticated and authorised by role, CSRF protection), and validated atomic configuration deploys with rollback.

The maintainer knows the common vulnerability classes for this kind of software (injection into generated configuration, path traversal, XSS, CSRF, SSRF, authentication bypass) and mitigates them: every value rendered into nginx configuration is validated, imports are confined to a configured directory, no shell execution with user input, output encoding in React, and CodeQL findings are triaged.

Only published algorithms are used: TLS 1.2/1.3, bcrypt for passwords, SHA-256, HMAC (TOTP, RFC 6238) and Ed25519 for managed-rule bundle signatures.

Cryptography uses the Go standard library, golang.org/x/crypto and OpenSSL via OpenResty; no cryptographic primitives are implemented by the project.

All cryptographic functionality is provided by FLOSS libraries (Go standard library, golang.org/x/crypto, OpenSSL).

Ed25519 (128-bit security) for bundle signatures, ECDSA P-256 keys for certificates (Let's Encrypt and the default certificate), TLS 1.2+ with ECDHE and AES-GCM/ChaCha20 suites, 160-bit TOTP secrets.

No broken algorithms are used for security. HMAC-SHA1 is used only for TOTP codes as specified by RFC 6238 for authenticator compatibility; HMAC-SHA1 is not considered broken.

No algorithms or modes with known serious weaknesses are used (no MD5, RC4, DES, CBC-only suites or TLS < 1.2).

The gateway allows only ECDHE cipher suites with TLS 1.2/1.3, and the admin console uses Go TLS defaults (ECDHE), so all connections have perfect forward secrecy.

Administrator and access-list passwords are stored as bcrypt hashes (salted, iterated).

Session tokens, API tokens, setup tokens, TOTP secrets and recovery codes are generated with crypto/rand.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

No hashes are retrieved over HTTP; images are pulled over HTTPS from ghcr.io by digest-verified tags and are signed with Sigstore cosign.

There are no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days. govulncheck, npm audit, Trivy and Dependabot run in CI.

Critical vulnerabilities are fixed rapidly; dependency vulnerabilities are detected by Dependabot, govulncheck, npm audit and Trivy and fixed before release.

The repository contains no valid private credentials; GitHub secret scanning with push protection is enabled.

CodeQL (Go, JavaScript/TypeScript, Actions; security-extended suite), go vet, govulncheck and Trivy run on every change before release.

CodeQL security-extended queries look for common vulnerabilities (injection, path traversal, XSS, unsafe deserialization, etc.).

All medium and higher severity findings are fixed or dismissed with a written justification after review.

Static analysis runs on every pull request and push to main, and on a weekly schedule.

Go fuzz tests (FuzzIPList, FuzzRuleRegex, FuzzVerify) and the integration suite (deploy/dev/itest.sh) that drives a running gateway are run before each release.

The project is written in memory-safe languages (Go, TypeScript, Lua).

Tests run with the Go race detector (go test -race) and Go runtime bounds checks enabled.

All medium and higher severity issues found by dynamic analysis are fixed before release.