Use GitHub private vulnerability reporting to report a suspected vulnerability. This opens a private Security Advisory with the maintainers.

Do not open a public issue, pull request, or discussion for a vulnerability. N2API does not publish a personal email address for security reports.

Provide only the minimum sanitized information needed to reproduce and assess the issue:

• The affected N2API version, image tag, or commit SHA.
• The affected component and deployment mode.
• A concise impact description and expected security boundary.
• Minimal, deterministic reproduction steps using synthetic accounts and data.
• Sanitized error codes, HTTP status codes, and relevant configuration key names without their values.
• Any temporary coordination or disclosure constraints.

Replace sensitive values with obvious placeholders before submitting the report. Verify the final advisory text and every attachment after redaction.

Do not submit or attach:

• Administrator passwords, client API keys, provider API keys, or proxy credentials.
• OAuth access tokens, refresh tokens, ID tokens, authorization callback codes, code verifiers, or complete callback URLs.
• Session cookies, browser storage, encryption secrets, previous encryption keys, or database connection strings.
• PostgreSQL dumps, backup archives, restored records, or complete database listings.
• Complete request or response bodies, complete headers, raw upstream errors, packet captures containing credentials, or production logs that have not been reviewed and sanitized.

Use synthetic fixtures where possible. If a secret was exposed during testing, revoke or rotate it outside the report workflow.

Maintainers will coordinate triage, remediation, and disclosure inside the private advisory. Reports for any currently deployed version are welcome; affected and fixed versions will be recorded in the advisory after assessment. Do not publish details before maintainers confirm that operators have a safe upgrade path.

Security fixes must follow the same test, migration, image evidence, and release gates as other changes. See the release checklist.

N2API accepts bounded _FILE alternatives for the database URL, administrator password, encryption secret and previous-key JSON, OAuth client secret, and metrics bearer token. A direct value and its _FILE alternative must not both be set. Secret files must be regular files, not symlinks, pipes, or directories; reads are capped at 64 KiB and remove at most one trailing LF or CRLF. Startup errors identify only the configuration key and failure class, not the path or secret content.

The release Compose secret overrides mount only declared files under /run/secrets. Keep source files owner-readable, outside the repository and backup archives, and never attach them to advisories or CI artifacts.

The Security workflow runs on changes to main, pull requests, merge queue checks, a weekly schedule, and manual dispatch. It performs these source and dependency checks:

• CodeQL analyzes Go and JavaScript/TypeScript with the security-extended query suite and uploads SARIF results. Repository rules determine which CodeQL alert severities block a merge.
• govulncheck blocks reachable Go vulnerabilities.
• bun audit --audit-level=high blocks HIGH and CRITICAL frontend dependency vulnerabilities.
• Trivy blocks HIGH and CRITICAL image vulnerabilities when the report names a non-empty fixed version. Unfixed findings remain visible in retained evidence but do not block publication.
• Stable Image Security re-scans the latest GitHub Release digest for both supported platforms every week and on manual dispatch without rebuilding, retagging, publishing packages, or creating issues.
• actionlint and the pinned-dependency policy reject malformed workflows and external Actions that are not pinned to complete commit SHAs.

Temporary scanner exceptions live in security/exceptions.json. Every entry must use one exact scanner-specific CVE, package, or rule identifier, name an owner and reason, and include RFC 3339 creation and expiry timestamps. Wildcard, duplicate, future-dated, expired, and longer-than-30-day exceptions are rejected. Invalid registries, scanner failures, and malformed reports fail closed. Resolve the finding and remove the exception before its expiry; do not renew an exception in place merely to keep a check green.