SECURITY.md

Rama main · réplica de lectura del repositorio original.

# Security Policy

## Supported Versions

Security fixes are provided for the latest public release line.

## Reporting a Vulnerability

Please do not open a public issue for suspected vulnerabilities.

Use the repository's [private vulnerability reporting](https://github.com/bailinghub/bailinghub/security/advisories/new) channel. Security-sensitive reports should remain private while they are triaged and a fix or coordinated disclosure is prepared. Maintainers will coordinate disclosure with the reporter after triage; reporter credit is preserved unless anonymity is requested.

Include:

- affected version or commit;
- deployment mode;
- reproduction steps;
- impact assessment;
- any relevant logs with secrets removed.

We aim to acknowledge reports within 3 business days. This project does not currently operate a paid bug bounty program.

## Security Baseline

- Do not commit `config.json`, `.env`, database passwords, model API keys, executor tokens, webhook secrets, or object-storage credentials.
- Production deployments should set `BAILING_ENV=production` and inject secrets through environment variables or a secret manager.
- `BAILING_TOKEN` is the root secret for machine-admin access and derived HMAC credentials. Production or non-loopback listeners require an explicit non-placeholder token of at least 24 characters. Only loopback-bound development mode may run without it.
- Docker Compose intentionally has no default `BAILING_TOKEN`. Generate one with `openssl rand -hex 32`, persist it in a local `.env` or secret manager, and rotate it if it may have been exposed.
- Business tools must verify `X-Bailing-Signature` and must perform their own authorization using `X-Bailing-On-Behalf-Of`.
- High-risk tools should use `risk=high`, `x-agent-capability.approval.required`, or parameter-level confirmation rules.

## Private release denylist

Public source audits include generic checks for private keys, personal access tokens, and local user paths. Deployment-specific exact text must not be added to repository scripts, tests, comments, or examples.

Maintainers can supply deployment-specific markers at audit time through either:

- `BAILING_PUBLIC_DENYLIST_JSON`: a JSON array of exact strings, intended for a protected CI secret;
- `BAILING_PUBLIC_DENYLIST_FILE`: an absolute path to a JSON array stored outside the repository, preferred for local release rehearsals.

For example, a protected test environment may set `BAILING_PUBLIC_DENYLIST_JSON='["DEPLOYMENT_ONLY_MARKER_ALPHA_42"]'`. Audit failures report only the marker index and never echo its value. The external file path is rejected when it resolves inside the repository.

## DOCX dependency assurance

Core and its bundled console use a reproducible library-only Mammoth distribution. It retains the original parsing sources and license while removing the unused command-line interface and its `argparse → sprintf-js` dependency chain. The previous time-limited exception for [GHSA-hp3w-g68c-fv3c](https://github.com/advisories/GHSA-hp3w-g68c-fv3c) is retired; no dependency finding is currently excepted.

`npm run audit:deps` requires zero raw findings, verifies the vendored source/archive, and separately queries direct advisories under the original upstream `mammoth` name and version. Registry failure, changed source/distribution, any finding or a reintroduced CLI dependency blocks the gate. See [DOCX source and audit policy](docs/DOCX_DEPENDENCY.en.md) ([中文](docs/DOCX_DEPENDENCY.md)) for reproduction, compatibility tests and the npm/Docker/source-export boundaries. This is not a general document-safety certification or an assertion that upstream sprintf-js is patched.

## Project stewardship and security coordination

BailingHub Core is independently maintained. It is not hosted by a foundation
and has no designated external open-source steward or external CRA stewardship
arrangement. The repository maintainer identified in [GOVERNANCE.md](GOVERNANCE.md)
is responsible for security triage and coordination through the private
vulnerability reporting channel above.

The Apache-2.0 license permits use in business products and paid services. This
statement does not assert that all possible downstream uses are outside the EU Cyber Resilience Act (CRA), and does
not claim legal compliance, certification, or participation in another
organization's stewardship framework. Downstream products and deployments must
assess their own roles and obligations.

For reliable evidence of active exploitation or a compromise of project
infrastructure, use the same private reporting channel and identify the incident
and urgency. Maintainers should follow the coordination steps in
[CONTRIBUTING.md](CONTRIBUTING.md). The project has no separately staffed emergency
hotline or guaranteed incident-response time.