MISP Docker Lifecycle Manager helps operate official MISP/misp-docker deployments. Security reports are taken seriously, especially when they affect secret handling, generated configuration, destructive lifecycle operations, or GitHub Actions supply-chain behavior.

This is a small community project. Support and response times are best effort, with no service-level agreement. Normal bugs and help requests belong in public GitHub issues when they can be fully sanitized; suspected vulnerabilities belong in private vulnerability reporting.

Please report suspected vulnerabilities privately through GitHub's private vulnerability reporting or security advisory workflow:

https://github.com/Tuxmint-Open-Source/misp-docker-lifecycle-manager/security/advisories/new

Do not open a public issue for security vulnerabilities.

If GitHub private reporting is unavailable to you, contact the repository owner through their public GitHub profile and ask for a private security-reporting channel. Do not include vulnerability details in the first public contact.

Use the private security path for issues such as:

• command injection or unsafe shell argument handling;
• secrets printed to logs, process arguments, public output, or generated files with unsafe permissions;
• unsafe handling of .env, generated passwords, private keys, or backup artifacts;
• reset, restore, update, or rollback behavior that can unexpectedly affect resources outside the selected deployment scope;
• generated Docker Compose or environment configuration that weakens security unexpectedly;
• GitHub Actions, release, dependency, or supply-chain issues that could affect users;
• vulnerabilities in validation/reporting workflows that could expose private deployment details.

Use public issues for non-sensitive topics such as:

• documentation typos or unclear wording;
• feature requests;
• public-safe bug reports with sanitized examples;
• compatibility questions that do not include private deployment details;
• validation failures with secrets and private infrastructure removed.

For public-safe reproducible bug reports, use the anonymous SOS report guide in docs/sos-report.md. If an SOS report cannot be safely anonymized, use the private security-reporting path instead.

Never include the following in public issues, pull requests, comments, screenshots, or logs:

• passwords, tokens, API keys, private keys, generated secrets, or .env contents;
• private hostnames, internal domains, private IPs, VM IDs, topology, or access paths;
• raw logs that may contain secrets or deployment details;
• database dumps, backup contents, generated configuration archives, or full .installer-state.json contents.

Use sanitized examples such as:

misp.example.com
admin@example.com
/opt/misp-docker
[REDACTED]

A good private security report includes:

• affected version, tag, or commit;
• affected workflow, such as install, update, backup, restore, rollback, reset, login, or GitHub Actions;
• a concise impact summary;
• sanitized reproduction steps;
• expected behavior;
• actual behavior;
• whether the issue appears exploitable remotely, locally, or only with operator privileges;
• any suggested fix, if known.

This is a small open-source project. Maintainers will make a best-effort attempt to:

1. acknowledge a clear report;
2. confirm whether it affects supported versions;
3. prepare a private or public fix path as appropriate;
4. publish a public advisory or release note when disclosure is appropriate.

Response times are best effort and may vary.

Please give maintainers reasonable time to investigate and fix confirmed vulnerabilities before public disclosure.

If a report affects upstream MISP/misp-docker or MISP itself rather than this lifecycle manager, maintainers may ask you to report the issue to the relevant upstream project.

• Contributing
• Code of Conduct
• Security model
• Anonymous SOS reports
• Support matrix