Skip to content

Security: dromara/lamp-cloud

Security

SECURITY.md

Security Policy

Thanks for helping keep lamp-cloud and the wider dromara ecosystem secure.

Reporting a vulnerability

Please do not open a public issue, discussion, or pull request that describes a suspected vulnerability — that gives attackers a head-start before a fix lands.

Use one of these private channels instead:

  1. GitHub's Private Vulnerability Reporting (preferred). Open a private security advisory at https://github.com/dromara/lamp-cloud/security/advisories/new. GitHub automatically routes it to the maintainers, keeps the discussion private until you and the maintainers agree to publish, and (optionally) assigns a CVE on publish.

  2. Email. If GitHub PVR is unavailable to you for any reason, email the project lead directly. Maintainers should add the preferred email here when they configure the policy.

What to include

A good report contains:

  • A clear description of the vulnerability and its impact.
  • Steps to reproduce against a specific commit SHA or release tag.
  • Affected code locations (file:line) where useful.
  • A suggested fix or mitigation if you have one.
  • Whether you'd like credit in the published advisory and, if so, under what name.

Scope and supported versions

lamp-cloud is a Spring Cloud microservice / SaaS development platform. The maintainers support security fixes on the latest minor release. Older releases will not generally receive backports.

In-scope vulnerability classes include:

  • Authentication / authorization bypass
  • Tenant-isolation flaws (cross-tenant data access)
  • Server-side request forgery (SSRF), command injection, path traversal
  • SQL injection in ORM / dynamic-SQL paths
  • Insecure deserialization
  • Cryptographic misuse in stored secrets / credentials

Out-of-scope:

  • Findings against intentionally trusted-admin features (config that the framework explicitly delegates to the integrator).
  • Issues that require an attacker to already have full database / server access.
  • Best-practice complaints without a concrete impact (e.g. "this header should be set", "TLS version should be raised").

Process

After you submit:

  1. A maintainer will acknowledge receipt within roughly 1 week.
  2. We'll triage the report: confirm severity, scope, and reproducibility.
  3. We'll work with you on a fix and a coordinated disclosure timeline (typically up to 90 days, longer if the fix is structural).
  4. On publication, we credit you in the advisory unless you ask not to be credited.

Hall of fame

Reporters who have helped harden lamp-cloud via responsible disclosure will be listed here once the corresponding advisory is published.


This policy is suggested via GitHub's "Suggest a security policy" workflow. Maintainers can edit any section freely; the most important thing is that a private reporting channel exists so researchers can submit findings responsibly.

There aren't any published security advisories