Only the latest release on the main branch receives security fixes. Older branches are not patched.

This policy covers security vulnerabilities in the StellarKraal codebase and its deployed services.

The following are not eligible for reports under this policy:

• Vulnerabilities in third-party services (Stellar network protocol, Soroban runtime, AWS managed services, Freighter wallet)
• Issues requiring physical access to infrastructure
• Social engineering attacks against team members
• Denial-of-service attacks against the testnet deployment
• Findings from automated scanners without a demonstrated impact or proof-of-concept
• Missing security headers on non-sensitive static assets (e.g., images, fonts)
• Rate limiting on public, non-authenticated endpoints
• Self-XSS requiring full control of the victim's browser
• Vulnerabilities already publicly known and reported (CVEs without a new exploit vector)
• Issues in outdated browser versions or unsupported operating systems

Do not open a public GitHub issue for security vulnerabilities. Public disclosure before a fix is deployed may put users at risk.

We ask that you follow responsible disclosure and give us the opportunity to address the issue before making it public.

Use GitHub's private vulnerability reporting to submit a report confidentially. This is the fastest path to triage and ensures coordinated disclosure.

Send a report to security@stellarkraal.example.com with the subject line: [SECURITY] <brief description>.

Include in your report:

• Summary: A concise description of the vulnerability and its potential impact.
• Steps to reproduce: Detailed reproduction steps or a proof-of-concept (PoC).
• Affected component(s): Backend API, frontend, smart contract, infrastructure, or a dependency.
• Severity estimate: Your assessment of the impact (Critical, High, Medium, Low).
• Suggested mitigation (optional): If you have a proposed fix or workaround.

If you prefer to encrypt your report, contact security@stellarkraal.example.com to request our PGP public key. We will reply with the key and fingerprint for verification. Do not send the vulnerability details until you have confirmed the correct key.

Note: PGP-encrypted reports are welcome but not required. GitHub Private Advisories provide end-to-end confidentiality without requiring key exchange.

We are committed to handling reports promptly. The following timelines are targets, not guarantees.

We will keep you informed of progress throughout the process. If you have not received an acknowledgment within 48 hours, please follow up via email. Our team is small, and reports may occasionally be missed.

If a fix requires more time than the above targets (e.g., due to complexity of the smart contract upgrade process), we will communicate an updated timeline and work with you to agree on a disclosure date.

We classify vulnerabilities using the following framework:

We consider security research conducted in good faith to be a valuable contribution to the security of StellarKraal. To encourage responsible disclosure, we commit to the following:

• We will not pursue civil or criminal action against researchers who discover and report vulnerabilities in accordance with this policy.
• We will not suspend or terminate any accounts used for research, provided the research did not cause harm to users or the protocol.
• We will work with you to understand and resolve the issue before public disclosure.
• We ask that you:
  • Do not access, modify, or delete user data beyond what is necessary to demonstrate the vulnerability.
  • Do not disrupt the production service or perform attacks that affect availability for real users. Use the testnet deployment for testing.
  • Do not exploit a vulnerability for personal gain or to harm users.
  • Notify us promptly if you inadvertently access data you did not intend to access.

This safe harbour does not apply to actions that violate applicable law beyond what is strictly necessary to demonstrate the vulnerability.

There is currently no paid bug bounty program. We do publicly acknowledge researchers who responsibly disclose valid vulnerabilities — with their permission — in our CHANGELOG.md and release notes.

We follow coordinated disclosure:

1. Reporter submits the vulnerability privately.
2. We acknowledge receipt and begin triage.
3. We develop and test a fix.
4. We deploy the fix to production.
5. We agree on a disclosure date with the reporter (typically 7–14 days after deployment).
6. The vulnerability is disclosed publicly via a GitHub Security Advisory and CHANGELOG.md entry.

Please allow us the response timeline above before publishing your findings. If we are unable to reach an agreement on a disclosure timeline, we ask that you give us at least 90 days from the date of the initial report before public disclosure.

The following practices are in place to protect the StellarKraal codebase:

• Dependabot monitors backend/, frontend/, and contracts/stellarkraal/ weekly for vulnerable dependencies. See docs/guides/dependabot.md.
• npm audit runs every Monday via the npm-audit workflow and fails on high or critical severity findings.
• Secret scanning via Gitleaks and GitHub's push protection prevents accidental secret commits. See docs/SECURITY_SCANNING.md.
• JWT-based authentication for all API routes. See docs/adr/ADR-002-jwt-auth.md.
• Soroban contract audits are documented in docs/security/contract-audit.md.
• Secrets management: All secrets are stored in environment variables. See docs/security/secrets-rotation.md for rotation procedures.
• Audit logs: Admin and state-changing operations are logged to AUDIT_LOG_DIR for forensic analysis.