Security fixes are applied to the latest version of the project available on the default branch.

Older commits, forks, and locally modified copies are not actively supported.

Compatibility with a particular RedCheck report schema does not imply that all older versions of the parser receive security fixes.

Do not disclose a suspected vulnerability in a public issue, discussion, pull request, XML fixture, generated workbook, log, or screenshot.

Use GitHub private vulnerability reporting if the repository provides the "Report a vulnerability" option.

If private vulnerability reporting is unavailable, open a public issue titled:

[Security] Request for private reporting channel

Do not include vulnerability details in that issue. The maintainer will provide an appropriate private communication method.

A useful private report should contain:

• a concise description of the vulnerability;
• the affected project version or commit;
• the affected Python and dependency versions;
• the affected RedCheck schema or report format, if relevant;
• minimal reproduction steps;
• the potential security impact;
• a minimal synthetic XML example;
• suggested remediation, if known.

Do not submit real RedCheck reports, vulnerability scan results, customer data, organization names, internal hostnames, real infrastructure addresses, credentials, private keys, or generated workbooks containing real data.

This is a small independently maintained project without a guaranteed service level agreement.

The maintainer will make a reasonable effort to:

1. acknowledge a complete report;
2. reproduce and assess the issue using synthetic data;
3. determine the affected versions and report formats;
4. prepare a fix or mitigation where appropriate;
5. add a regression test;
6. coordinate disclosure after a fix is available.

Examples of relevant security issues include:

• unsafe XML processing;
• XML external entity processing;
• excessive entity expansion or resource consumption;
• arbitrary file read or write;
• path traversal;
• command injection;
• unsafe temporary-file handling;
• spreadsheet formula injection in generated workbooks;
• unintended disclosure of report contents;
• a vulnerable dependency with a practical impact on the parser.

Incorrect parsing or formatting without a security impact should normally be reported using the bug-report issue template.

All reports and proof-of-concept files must use synthetic or fully anonymized data.

Use reserved or fictional values such as:

192.0.2.10
192.0.2.20
server-01.example
example-organization

A reproduction file should contain only the minimum XML structure needed to demonstrate the issue.

Generated workbooks containing proof-of-concept formulas or payloads must not be opened on systems that contain valuable or sensitive data.

A dependency advisory alone may not demonstrate that this project is exploitable.

Reports should explain, where possible:

• which dependency and version are affected;
• whether the vulnerable code path is used;
• how the issue affects this parser;
• which safe upgrade or mitigation is available.