WAF++ WAF++
Back to WAF++ Homepage

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

Voraussetzungen

  • Git und ein GitHub-Account

  • Grundkenntnisse in AsciiDoc (für Narrative-Seiten)

  • YAML-Kenntnisse (für Controls)

  • Lokal: Python 3.10+ und wafpass für Control-Tests

Erste Schritte

  1. Repository forken auf GitHub

  2. Branch erstellen – Namenskonvention: feat/WAF-COST-110, fix/WAF-SOV-020-typo, docs/pillar-cost-glossary

  3. Änderungen vornehmen (siehe Abschnitte unten)

  4. Lokal testen (für Controls: wafpass check)

  5. Pull Request öffnen mit dem Issue als Referenz


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ündetrationale erklärt das Risiko, nicht nur die Regel

  • Praxisnahexample.compliant und example.non_compliant sind echtes Terraform

Ablauf

  1. Auf GitHub prüfen, ob ein ähnliches Control bereits existiert oder diskutiert wird (Issues / Discussions).

  2. Control-ID vergeben: nächste freie Nummer im Pillar (z.B. WAF-COST-110). Nummern werden nicht wiederverwendet.

  3. YAML-Datei anlegen nach Control-Schema:

    # Ablageort
    modules/controls/controls/WAF-COST-110.yml
  4. Checks lokal gegen Fixture-Terraform testen:

    wafpass check ./tests/fixtures/ --controls WAF-COST-110 --verbose
  5. 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
  6. 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.compliant und example.non_compliant vorhanden

  • regulatory_mapping sofern applicable befüllt

  • Narrative-Seite angelegt und in references.narrative verlinkt

  • wafpass check gegen 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

modules/pillar-{NAME}/pages/controls/WAF-{PILLAR}-{NNN}.adoc

Best Practice

modules/pillar-{NAME}/pages/best-practices/bp-{slug}.adoc

Fallbeispiel (Case Study)

modules/pillar-{NAME}/pages/case-studies/case-{slug}.adoc

Pillar-Hauptseiten (definition, scope, etc.)

modules/pillar-{NAME}/pages/{name}.adoc

Konventionen

  • Sprache: Deutsch

  • Seitenattribute: immer = Titel und :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:

  1. RFC-Issue öffnen mit Label rfc – Beschreibung der Änderung und Begründung

  2. Kommentarphase – mindestens 14 Tage offen für Community-Feedback

  3. TSC-Entscheidung – dokumentiert im Issue-Kommentar

  4. Implementierung – im Branch rfc/NNN-beschreibung, dann PR gegen main

Breaking Changes erhalten immer eine Migrations-Notiz in der Changelog-Seite.


Versionierung und Releases

WAF++ verwendet semantische Versionierung (MAJOR.MINOR.PATCH):

Versionstyp Auslöser

MAJOR

Inkompatible Schema-Änderungen, Pillar-Umstrukturierung, Control-IDs werden retired

MINOR

Neue Controls, neue Narrative-Seiten, neue Best Practices

PATCH

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