Wardex Foundry welcomes contributions that deepen the risk analysis dimension of the lab. Contributions that add tooling complexity without adding a corresponding risk narrative are out of scope.
A good contribution answers at least one of these questions:
- What new risk can a practitioner identify with this change?
- What new evidence can a practitioner collect?
- What new control can the Wardex gate validate?
| Type | Welcome? | Notes |
|---|---|---|
| New scenario (v1 + v2 + threat model entry) | Yes | Must follow scenario template (see SPEC.md) |
| New Wardex gate rule | Yes | Must include test case |
| Improved audit evidence scripts | Yes | Must be POSIX-compatible |
| Documentation corrections | Yes | Docs PR; no CI gate required |
| New component (e.g., Elasticsearch, Redis) | Discuss first | Open an issue before implementing |
| Tutorial-style how-to guides | No | Out of scope; refer to scenario template |
| Replacing existing components with alternatives | No | Stability of the lab environment is a priority |
- Fork the repository
- Create a branch:
git checkout -b feat/scenario-04-no-tls-vault - Make changes following the scenario template
- Run pre-commit hooks:
./scripts/hooks/install-hooks.sh - Commit with Conventional Commits format
- Open a PR targeting
develop - Fill in the PR template (scenario description, threat model entry, evidence screenshot)
- Wait for CI and maintainer review
This project follows a simplified Gitflow:
main<- stable, tagged releases onlydevelop<- integration branch, always deployablefeature/*<- new scenarios, components, or integrationsfix/*<- bug fixes on existing scenarios or infrastructuredocs/*<- documentation-only changes (no infra impact)chore/*<- dependency updates, CI changes, tooling
All commits must follow Conventional Commits v1.0.0.
This project follows the Contributor Covenant v2.1. All contributors are expected to uphold its standards.