Contributing

Contributing to MalGuard

MalGuard accepts defensive-security contributions through reviewed pull requests. We welcome genuine, independent developers who want to improve documentation, accessibility, harmless synthetic regression tests, and transparent security guidance. No previous involvement with MalGuard is required.

Engineering contribution areas

We are looking for thoughtful contributors, not inflated star counts or promotional posts. These are areas where well-scoped pull requests can help. They are contribution interests, not paid job vacancies.

• Windows / systems: review file provenance, signatures, archive parsing, and clear limitations in security reports.
• Testing / quality: write reproducible tests with harmless synthetic fixtures; improve regression coverage without disabling safety checks.
• Web / accessibility: improve performance, mobile layout, keyboard accessibility, and honest product documentation.
• Technical writing: document Windows contributor setup, focused tests, and transparent result interpretation.

Start by reviewing the public source repository, research guides, and current help-wanted issues. For a first contribution, propose a small change and submit a pull request. Maintainers review the change before merge; contributors do not need write or administrator access.

We may separately discuss longer-term collaboration when there is a strong mutual fit, but there is no promised role, compensation, equity or project success. Do not send identity documents or sensitive personal data in a public issue.

Start with a small, real task

• Improve the Windows contributor quickstart
• Document how to run one focused test
• Clarify unsigned Windows preview verification
• Improve sanitized bug report guidance

Read the contributor quickstart before opening a pull request. All proposed contributions are reviewed and no issue guarantees acceptance, payment, or code-signing approval.

Safety requirements

• Do not commit, upload, download, or execute real malware.
• Use harmless synthetic fixtures for security tests.
• Do not add secrets, API tokens, private keys, certificates, PFX files, credentials, or personal data.
• Do not weaken fail-closed behavior to make a test pass.
• Do not introduce hidden network access, telemetry, installers, or update behavior.
• Do not bypass release provenance, integrity, update, or code-signing controls.

Development workflow

1. Create a branch from the current main.
2. Make the smallest reviewable change.
3. Add or update tests for security-sensitive behavior.
4. Run node tests/run-all.js and relevant platform tests.
5. Open a pull request.
6. Require review and green CI before merge.

Security-sensitive build, workflow, installer, updater, isolation, and signing changes require especially careful review.

Maintainer security

Maintainers must use multi-factor authentication for repository access. Release approval and code-signing approval are separate responsibilities even when one maintainer temporarily holds both roles.