aSPARK-policy
Aus PDFs werden durchsetzbare Regeln. Markdown erklärt die Standards, eine policy.yaml aktiviert sie, und jeder aSPARK-Agent konsumiert dieselbe Policy.
Aus PDFs werden durchsetzbare Regeln.
Markdown erklärt die Standards, eine policy.yaml aktiviert sie, und jeder aSPARK-Agent konsumiert dieselbe Policy — keine duplizierten Prompts, keine Custom-Agenten.
Adoption = ein git submodule nach .spark/policy. Kein Python, kein Tooling zum Betreiben.
Hierarchische Vererbung — vorhersehbar statt interpretiert
| Case | Behavior |
|---|---|
| Skalar auf zwei Ebenen | spezifischere Ebene gewinnt |
| Listen | gemerged (!override ersetzt) |
| final: true | gesperrt — tiefere Ebenen dürfen nur verschärfen |
Corporate → Business Unit → Department → Projekt. final existiert für den Compliance-Fall: eine regulierte Organisation garantiert, dass eine Regel in jedem Projekt gilt — ohne jedes einzeln zu auditieren.
Ein Projekt kombiniert Packs über mehrere Achsen — Compliance, Sprache, Framework, Cloud, Architektur, Plattform. Auf Platte nach Kategorie gruppiert, im Import aber immer flach: aspark:owasp, nie aspark:compliance/owasp. Eigene Packs laufen unter company:.
Externe Standards — je einer pro regulierter Branche: Payment (PCI-DSS v4.0), Automotive-Cybersecurity (UN R155 / CSMS), plus die branchenübergreifenden OWASP und ISO 27001.
MISRA liegt auf der Sprach-Achse neben Java — nicht in einem Branchen-Topf. Ein Coding-Standard für sicherheitskritisches C/C++ ist genau das: ein Coding-Standard, kein Industriesegment.
Speisen den Developer direkt; react schaltet zusätzlich die bestehende ux-Lens scharf.
Binden an den Engineering Manager. Eine cloud-Lens in Core gibt es noch nicht — bis dahin sind es schlichte Constraints.
Engineering Manager und Reviewer — ebenfalls noch ohne eigene Lens.
Die Achse für Plattform-Standards ist im Katalog angelegt. SAP ist das erste Pack auf dieser Achse.
Zwei Sorten Pack — und nur eine darf gesperrt werden
| Sorte | final? | Beispiele |
|---|---|---|
| universal | ja | owasp · iso27001 · pci-dss · un-r155 |
| baseline | nie | java · misra · spring · react · aws · azure |
Der Unterschied entscheidet, was gesperrt werden darf. Die OWASP Top 10 sind ein Fakt der Branche — eine Konzernebene darf sie final setzen. Ein Baseline-Pack, das Java 21 festnagelt, ist dagegen ein Default, kein Standard: jede Organisation hat eigene Konventionen, also ist eine Baseline ein Gerüst zum Verschärfen — nie eine Sperre.
Ehrlich zum Umfang: Die Packs sind aSPARKs eigene, zusammenfassende Interpretation der Standards — sie geben keinen lizenzierten Regeltext wieder. UN R155 ist bewusst auf der öffentlichen UN-Regelung verankert, nicht auf der kostenpflichtigen ISO/SAE 21434. Ein Pack ist kein Zertifizierungsartefakt: weder eine QSA-Bewertung noch eine Typgenehmigung.
Policies werden zu Quality-Gates statt Beratungsdokumenten — und jede Verletzung nennt Policy und Regel, aus der sie stammt. Das macht den Trail auditierbar.
Ehrlicher Status: aSPARK-policy ist mit v0.2.0 einsetzbar — Format, JSON-Schemas, Regel-Anatomie (id/severity/scope/check) und 11 Packs stehen und werden per git submodule adoptiert, ohne Python und ohne Tooling. Was noch fehlt, ist die maschinelle Durchsetzung: validate-CLI und /charter-Bindung. Die Policy ist heute lesbar, vererbbar und auditierbar — aber ein Agent zieht sie noch nicht automatisch heran.
Jedes Produkt hat eine Verantwortung und stabile Schnittstellen. Eine Schwäche in einem darf nie Änderungen in einem anderen erzwingen.
Passt das zu Ihrem Lieferprozess?
Beginnen Sie mit Core auf einem Pilotprojekt. Workflow, Wissensgraph und Policy-Packs liegen offen auf GitHub.