70 lines
2.5 KiB
Markdown
Executable File
70 lines
2.5 KiB
Markdown
Executable File
# Security Policy
|
|
|
|
## Overview
|
|
|
|
Security is a first-class implementation concern in Frosty Deno. The gateway
|
|
fails closed around durable state, governance, and config encryption; redacts
|
|
secrets before they reach the browser; and keeps its runtime permissions
|
|
intentionally narrow.
|
|
|
|
The detailed implementation model is documented in
|
|
[docs/concepts/security-model.md](docs/concepts/security-model.md). The full
|
|
dependency inventory and SBOM are documented in
|
|
[docs/reference/sbom.md](docs/reference/sbom.md).
|
|
|
|
## Supported versions
|
|
|
|
The current checked-in gateway version is `0.9.0`. The repository does not
|
|
publish a richer tagged release matrix, so the support statement is
|
|
intentionally conservative.
|
|
|
|
| Version line | Supported |
|
|
| ------------------------------------- | --------------------------------------- |
|
|
| `0.9.x` | Yes |
|
|
| Earlier or untagged historical states | No support commitment published in-repo |
|
|
|
|
## Reporting a vulnerability
|
|
|
|
Do not open a public GitHub issue for a security vulnerability.
|
|
|
|
Use a private channel instead:
|
|
|
|
1. If the repository is hosted on GitHub with security advisories enabled, use
|
|
the repository's **Security** tab and choose **Report a vulnerability**.
|
|
2. If that private advisory flow is unavailable in the hosting environment,
|
|
contact the maintainers through a private maintainer channel rather than a
|
|
public issue.
|
|
|
|
No dedicated security email address is defined in the checked-in repository
|
|
files, so this document intentionally does not invent one.
|
|
|
|
Include the following in your report:
|
|
|
|
- a clear description of the issue and why it matters
|
|
- affected routes, components, or integrations
|
|
- reproduction steps, including required configuration
|
|
- the version or commit you tested
|
|
- any logs, payloads, or proof-of-concept details that help reproduce the issue
|
|
safely
|
|
|
|
## Disclosure process
|
|
|
|
The intended process is:
|
|
|
|
1. Acknowledge the report privately.
|
|
2. Reproduce the issue and assess scope and severity.
|
|
3. Prepare a fix and matching regression coverage.
|
|
4. Release or publish the remediation.
|
|
5. Coordinate public disclosure after a fix exists.
|
|
|
|
## Dependency security
|
|
|
|
The checked-in SBOM and the repository-local SBOM generator are the source of
|
|
truth for dependency inventory:
|
|
|
|
- [docs/reference/sbom.md](docs/reference/sbom.md)
|
|
- [docs/reference/sbom/sbom.cyclonedx.json](docs/reference/sbom/sbom.cyclonedx.json)
|
|
- `scripts/generate_sbom.ts`
|
|
|
|
Recommended follow-up scans are documented in the SBOM itself.
|