Governance & Contribution
WAF++ ist ein offenes Community-Projekt. Diese Seite beschreibt, wie Entscheidungen getroffen werden und wie du konkret beitragen kannst – ob als Control-Autor, Reviewer oder Pillar-Maintainer.
Governance-Modell
WAF++ orientiert sich an etablierten Open-Source-Governance-Modellen (angelehnt an CNCF und OpenSSF).
| Rolle | Verantwortung |
|---|---|
Technical Steering Committee (TSC) |
Technische Ausrichtung, Breaking Changes, Pillar-Struktur, Schema-Änderungen. Entscheidungen per Konsens, bei Uneinigkeit per Mehrheitsvotum. |
Pillar Maintainer |
Verantwortlich für alle Controls und Narrative-Seiten eines Pillars. Review und Merge von Control-PRs. Mindestens ein Maintainer pro aktivem Pillar. |
Contributor |
Reicht Controls, Korrekturen, Narrative-Seiten oder Best Practices per Pull Request ein. Kein formaler Onboarding-Prozess erforderlich. |
User Advisory Group |
Bringt Praxisperspektive aus Projekten, Betrieben und Audits ein. Kein Merge-Recht, aber Veto-Option bei Controls mit direkten Compliance-Auswirkungen. |
Alle Entscheidungen werden öffentlich auf GitHub diskutiert und dokumentiert. Es gibt keine privaten Entscheidungskanäle.
Beitragen – Schnellstart
Neues Control beitragen
Controls sind der Kern des Frameworks. Ein gutes Control ist:
-
Normativ – sagt "MUST", nicht "sollte"
-
Testbar – hat mindestens einen automatisierten Check (
automated: true) -
Begründet –
rationaleerklärt das Risiko, nicht nur die Regel -
Praxisnah –
example.compliantundexample.non_compliantsind echtes Terraform
Ablauf
-
Auf GitHub prüfen, ob ein ähnliches Control bereits existiert oder diskutiert wird (Issues / Discussions).
-
Control-ID vergeben: nächste freie Nummer im Pillar (z.B.
WAF-COST-110). Nummern werden nicht wiederverwendet. -
YAML-Datei anlegen nach Control-Schema:
# Ablageort modules/controls/controls/WAF-COST-110.yml -
Checks lokal gegen Fixture-Terraform testen:
wafpass check ./tests/fixtures/ --controls WAF-COST-110 --verbose -
Narrative-Seite anlegen (Deutsch):
# Für Cost-Controls: modules/pillar-cost/pages/controls/WAF-COST-110.adoc # Für Sovereign-Controls: modules/pillar-sovereign/pages/controls/WAF-SOV-NNN.adoc -
Pull Request öffnen – Titel:
feat: add WAF-COST-110 – [kurzer Titel]
Checkliste für Control-PRs
-
YAML-Datei in
modules/controls/controls/angelegt -
Alle Pflichtfelder befüllt (
id,title,pillar,status,severity,category,description,rationale,checks) -
Mindestens ein Check mit
automated: true -
example.compliantundexample.non_compliantvorhanden -
regulatory_mappingsofern applicable befüllt -
Narrative-Seite angelegt und in
references.narrativeverlinkt -
wafpass checkgegen Fixture läuft ohne Fehler -
Maturity-Levels (alle 5) befüllt
Narrative-Seiten beitragen
Narrative-Seiten sind die menschenlesbare Erklärung hinter den Controls. Sie werden in Deutsch verfasst (AsciiDoc).
Ablageorte
| Seitentyp | Pfad |
|---|---|
Control-Detailseite |
|
Best Practice |
|
Fallbeispiel (Case Study) |
|
Pillar-Hauptseiten (definition, scope, etc.) |
|
Konventionen
-
Sprache: Deutsch
-
Seitenattribute: immer
= Titelund:description:setzen -
Cross-References: immer als Antora-xref (
xref:module:page.adoc[Text]), keine relativen Pfade -
Code-Beispiele: immer mit
[source,lang]und-----Blöcken -
Tabellen:
[cols=…, options="header"]für konsistentes Rendering
Issues und Discussions
| Kanal | Verwendung |
|---|---|
GitHub Issues |
Konkrete Bugs, fehlerhafte Controls, broken Links, falsche Assertions. Bitte Control-ID im Titel nennen. |
GitHub Discussions |
Konzeptdiskussionen, neue Pillar-Ideen, Feedback zu Maturity-Levels, Fragen zur Anwendung |
Pull Requests |
Alle Code- und Dokumentationsänderungen. Jeder PR sollte ein Issue referenzieren. |
Issue-Vorlage für neue Controls
## Control-Vorschlag: WAF-\{PILLAR}-\{NNN}
**Pillar:** Cost / Sovereign / Security / ...
**Severity:** critical / high / medium / low
**Kategorie:** (z.B. tagging, egress, encryption)
### Problem / Risiko
[Welches Risiko wird derzeit nicht durch bestehende Controls abgedeckt?]
### Vorgeschlagene Anforderung
[Was soll das Control fordern? Normativ formulieren: "All resources MUST ..."]
### Automated Check möglich?
[ ] Ja – über Terraform-Assertions
[ ] Nein – manueller Review erforderlich
### Regulatorische Relevanz
[GDPR / BSI C5 / ISO 27001 / FinOps / keiner]
RFC-Prozess (Schema-Änderungen)
Änderungen am Control-Schema oder an Pillar-Strukturen, die Breaking Changes darstellen, durchlaufen einen RFC-Prozess:
-
RFC-Issue öffnen mit Label
rfc– Beschreibung der Änderung und Begründung -
Kommentarphase – mindestens 14 Tage offen für Community-Feedback
-
TSC-Entscheidung – dokumentiert im Issue-Kommentar
-
Implementierung – im Branch
rfc/NNN-beschreibung, dann PR gegenmain
Breaking Changes erhalten immer eine Migrations-Notiz in der Changelog-Seite.
Versionierung und Releases
WAF++ verwendet semantische Versionierung (MAJOR.MINOR.PATCH):
| Versionstyp | Auslöser |
|---|---|
|
Inkompatible Schema-Änderungen, Pillar-Umstrukturierung, Control-IDs werden retired |
|
Neue Controls, neue Narrative-Seiten, neue Best Practices |
|
Korrekturen in Assertions, Tipp- und Formulierungsfehler, Link-Fixes |
Releases werden als GitHub Releases mit Changelog veröffentlicht. Control-IDs sind stabil über Minor-Versionen hinweg – eine einmal vergebene ID wird nicht wiederverwendet.
Weiterführende Seiten
-
Control-Schema Referenz – vollständige YAML-Dokumentation für Control-Autoren
-
WAF++ PASS – CLI – Controls lokal testen
-
Assessment-Methodik – Controls im Einsatz
-
Roadmap – was als nächstes kommt