63 lines
3.2 KiB
Markdown
63 lines
3.2 KiB
Markdown
# Security policy
|
|
|
|
This project handles blockchain signing, transaction construction and memo helpers. Please report suspected security issues responsibly.
|
|
|
|
## Supported version
|
|
|
|
Security review targets the active `main` branch and the latest published npm version when applicable. Do not hand-maintain a version number here; the repository version is defined by `package.json` and the published version is defined by the npm registry.
|
|
|
|
## What to report
|
|
|
|
Please report issues such as:
|
|
|
|
- private-key exposure or unsafe key handling in SDK code;
|
|
- transaction serialization or signing errors;
|
|
- asset amount precision or rounding errors that affect signed transactions;
|
|
- memo encryption/decryption vulnerabilities beyond known legacy-format limitations;
|
|
- JSON-RPC response handling issues that can mislead applications;
|
|
- package distribution, build artifact or dependency supply-chain risks;
|
|
- browser bundle issues that materially affect key safety.
|
|
|
|
Do not include real private keys, seed phrases or account secrets in reports.
|
|
|
|
## Known architectural limitations
|
|
|
|
Some risks are protocol or application-boundary limitations rather than direct SDK bugs. They are still important, but they may require documentation, application controls or future protocol-compatible designs rather than immediate SDK changes.
|
|
|
|
Known categories include:
|
|
|
|
- public RPC endpoints are untrusted unless the application chooses and secures them;
|
|
- Nexus Layer 2 data is indexed/query data, not Layer 1 consensus truth;
|
|
- browser signing is high risk without wallet/user-controlled signing flows;
|
|
- legacy encrypted memo format should not be treated as modern authenticated encryption;
|
|
- password-derived keys from legacy login semantics are not a modern password KDF.
|
|
|
|
See [`architecture/SECURITY_ARCHITECTURE.md`](./architecture/SECURITY_ARCHITECTURE.md) for the project security architecture.
|
|
|
|
## Reporting channel
|
|
|
|
If the hosting platform provides a private security advisory or confidential issue workflow for this repository, use that first.
|
|
|
|
If no private workflow is available, contact the maintainers through the repository's normal project channels and request a private security contact before sharing exploit details.
|
|
|
|
Do not open a public issue containing exploit details, live private keys or instructions that could immediately harm users.
|
|
|
|
## Maintainer handling expectations
|
|
|
|
Maintainers should:
|
|
|
|
1. acknowledge receipt when possible;
|
|
2. classify whether the report is an implementation bug, architectural weakness, accepted protocol limitation, application concern or operational recommendation;
|
|
3. reproduce with tests or a minimal proof where safe;
|
|
4. decide whether a fix, documentation update, release advisory or no-code clarification is appropriate;
|
|
5. avoid publishing exploit details until users have a reasonable mitigation path.
|
|
|
|
## Release guidance
|
|
|
|
Before publishing a security-sensitive release, maintainers should run the side-effect-free release preflight:
|
|
|
|
```bash
|
|
npm run release:check
|
|
```
|
|
|
|
For npm publication, also perform dependency/security audit and package-content review in an environment where audit tooling is available. `release:check` includes runtime CSP scanning and a packed-package consumer smoke test, but it does not replace maintainer review of generated artifacts or release provenance.
|