[ en | ru ]

We take the security of Nanolaba Readme Generator (NRG) seriously. This document describes how to report vulnerabilities and what you can expect from us in return.

Security fixes are issued for the latest stable release. Older releases do not receive backports.

If you are running an older version, please upgrade before reporting — the issue may already be fixed on the current release.

Please do NOT open a public GitHub issue, pull request, or discussion for security reports. Public disclosure before a fix is available puts every user at risk.

Send the report by email to nrg@nanolaba.com with the subject prefixed [SECURITY]. If you would like the report encrypted, ask in the first message and we will exchange a PGP key out of band.

A useful report contains, at minimum:

• NRG version, distribution (CLI / Maven plugin / GitHub Action / library), Java version, and operating system.
• A clear description of the vulnerability and its impact (what an attacker can do).
• Step-by-step reproduction: a minimal .src.md template, command line, or code snippet that demonstrates the issue.
• Any proof-of-concept, logs, stack traces, or screenshots that help us reproduce.
• Whether the vulnerability is already known to third parties, and any deadline you have in mind for public disclosure.

A working proof-of-concept is not required, but it dramatically speeds up triage.

After we receive your report:

1. Acknowledgement — within 3 working days we confirm receipt and assign an internal tracker.
2. Triage — within 10 working days we evaluate severity and either confirm or refute the vulnerability with our reasoning.
3. Fix — for confirmed vulnerabilities we develop and test a patch privately. Timeline depends on severity (typically days for critical, weeks for low-severity).
4. Coordinated disclosure — we publish a release containing the fix together with a security advisory crediting the reporter (unless you ask for anonymity). We agree on the disclosure date with the reporter beforehand.

We will keep you informed throughout the process. If progress stalls, expect at least a status update every two weeks.

We follow coordinated disclosure: we ask reporters to give us a reasonable window to ship a fix before going public. The window is usually 90 days from initial report, shorter for low-severity issues, longer for complex ones — always negotiated, never unilaterally extended.

After the fix ships we publish a GitHub Security Advisory and request a CVE if applicable.

In scope: vulnerabilities in NRG itself — the core library, the CLI, the Maven plugin, and the GitHub Action distribution. In particular, we are interested in:

• Bypasses of the --allow-exec / <allowExec> opt-in for the ${widget:exec} widget (running external commands without the user opting in).
• Bypasses of nrg.allowRemoteImports for ${widget:import(url=...)} (fetching remote content when the user has not enabled remote imports).
• Bypasses of sha256 integrity pinning for remote imports.
• Path-traversal or arbitrary-file-read vulnerabilities via the path parameter of ${widget:import} or ${widget:fileTree}.
• Code injection / arbitrary code execution via crafted source templates loaded from untrusted input.
• Regex denial-of-service (ReDoS) in the rendering pipeline triggered by reasonably-sized input.
• Vulnerabilities in NRG-published artifacts on Maven Central or in the published GitHub Action.

Out of scope:

• Issues in third-party dependencies — please report those upstream. We will pick up dependency fixes in regular releases.
• Behaviour that follows directly from a user choosing to enable an opt-in feature — e.g. running ${widget:exec} after passing --allow-exec, or fetching a remote URL after setting nrg.allowRemoteImports=true. The opt-ins exist precisely so this does not happen by default.
• Vulnerabilities exploitable only by an attacker who already controls the source template author's machine.
• The content of generated .md files when the source template was authored by the attacker — generated output is, by design, whatever the template said it should be.
• Issues in projects that merely use NRG — those belong in the respective project's tracker, not here.

We will not pursue legal action against security researchers who:

• Make a good-faith effort to avoid privacy violations, data destruction, and service disruption.
• Do not exploit a vulnerability beyond the minimum necessary to demonstrate it.
• Give us a reasonable time to respond before any public disclosure.
• Do not attack third parties or NRG users.

We credit reporters who help us improve NRG's security in the corresponding release notes and GitHub Security Advisories — unless you prefer to remain anonymous, just let us know.

For non-security questions, please use the channels listed in CONTRIBUTING.md.