Eine Sicherheitsschulungs-App mit absichtlichen Schwachstellen ändern, ohne ihre Übungsaufgaben zu beschädigen

## Gewollte Übungsaufgaben von zufälligen Schwachstellen unterscheiden Behandeln Sie eine absichtlich verwundbare Schulungsanwendung anders als eine gewöhnliche Produktionsanwendung. Manche unsicheren Verhaltensweisen sind bewusst gestaltete Lehrinhalte, andere Schwächen hingegen unbeabsichtigte Fehler. - Stellen Sie vor einer Änderung fest, ob das betroffene Verhalten zu einer vorgesehenen Übungsaufgabe, zur unterstützenden Infrastruktur oder zu einer unbeabsichtigten Schwachstelle gehört. - Entfernen, schwächen oder ergänzen Sie das Verhalten einer Übungsaufgabe nicht allein aufgrund eines automatisierten Vorschlags. - Neue Schwachstellen und neue Übungsaufgaben erfordern die Genehmigung der Verantwortlichen und eine klare Dokumentation. - Vergewissern Sie sich, dass eine vorgeschlagene Übungsaufgabe klar abgegrenzt, lösbar, funktionsfähig und für die Lernziele geeignet ist. - Bewahren Sie Hinweise, Metadaten und Lösungswege der Übungsaufgabe sowie sicherheitsrelevante Kommentare, die nicht offensichtliche Absichten erläutern. - Prüfen Sie generierten Code kritisch. Beitragende und Prüfende bleiben für Korrektheit, Sicherheit und pädagogischen Wert verantwortlich. Wenn die Absicht unklar ist, verfolgen Sie den Ausführungspfad, die Tests, die Metadaten der Übungsaufgabe und die gespiegelten Korrekturartefakte, bevor Sie über die nötigen Änderungen entscheiden. ## Eine Änderung planen, die genau ein Problem löst Ermitteln Sie zunächst die betreffende Komponente, verfolgen Sie ihren Datenfluss und suchen Sie nach etablierten Umsetzungs- und Testmustern. 1. Bestimmen Sie das einzelne Problem, das die Änderung lösen soll. 2. Ermitteln Sie die von diesem Problem betroffenen Server-, Client-, API-, Daten-, Vorlagen-, Konfigurations- und Übungsaufgabenartefakte. 3. Suchen Sie nach ähnlichem Code und folgen Sie den aktuellen Mustern des Repositorys. 4. Prüfen Sie vor der Umsetzung die Auswirkungen auf die Sicherheit. 5. Schlagen Sie Tests vor, die das vorgesehene Verhalten von Rückschritten unterscheiden. 6. Halten Sie unzusammenhängende Bereinigungen und belanglose Änderungen aus demselben Beitrag heraus. Stimmen Sie sich mit den Verantwortlichen ab, bevor Sie Übungsaufgaben erstellen, die Architektur ändern oder das Abhängigkeitsmodell anpassen. Prüfen Sie jede Paketaktualisierung anhand aller relevanten Abhängigkeitsbeschreibungen und Laufzeitversionsbereiche. Fügen Sie keine spekulativen Konfigurationsoptionen oder Abhängigkeiten ohne nachgewiesenen Bedarf und Belege für die Kompatibilität hinzu. Arbeiten Sie von dem durch das Repository vorgegebenen Integrationszweig aus in einem klar eingegrenzten Entwicklungszweig. Verweisen Sie auf den betreffenden Vorgang und beschränken Sie den Beitrag auf einen einzigen zusammenhängenden Zweck. ## KI-Füllstoff entfernen und den Linter bestehen Bereinigen Sie automatisiert erzeugte Ausgaben vor der Prüfung. Entfernen Sie weitschweifige Kommentare, die offensichtlichen Code nur wiederholen, allgemeine Platzhalter, übermäßige Dokumentationszeichenketten für einfache Funktionen, sich wiederholende Erklärungen, Debug-Protokolle und andere generierte Rückstände. Bewahren Sie Kommentare, die komplexe Logik, die Absicht einer Übungsaufgabe, Sicherheitsbeschränkungen oder eine notwendige Ausweichlösung erläutern. Führen Sie bei jeder Codeänderung das Prüfwerkzeug des Repositorys aus, es sei denn, die Änderung ist auf Dokumentation beschränkt, die das Repository ausdrücklich davon ausnimmt. Generierter Code muss dieselben Stilregeln wie von Hand geschriebener Code einhalten. - Beheben Sie Beanstandungen der Stilprüfung, statt die Richtigkeit des Vorschlags vorauszusetzen. - Bewahren Sie unnötigen Code nicht allein deshalb auf, weil ein Assistent ihn erzeugt hat. - Prüfen Sie den Änderungsvergleich auf umfangreiche reine Formatänderungen und unzusammenhängende Dateiänderungen. - Verwenden Sie klare Namen und knappe Kommentare, die künftig Verantwortlichen helfen, die Absicht zu verstehen. - Stellen Sie sicher, dass Dokumentation und Commit-Beschreibung die tatsächliche Änderung und nicht den Arbeitsablauf des Assistenten beschreiben. ## Die Tests ausführen, die jede Art von Änderung verlangt Die Testanforderungen richten sich nach dem geänderten Bereich, doch das Vertrauen in einen Assistenten ersetzt niemals die tatsächliche Ausführung. - Fügen Sie für geänderte Logik Unit-Tests hinzu oder aktualisieren Sie diese. - Führen Sie API-Integrationstests aus, wenn sich Anfrageverarbeitung, Persistenz, Autorisierung oder Antwortverhalten ändern. - Führen Sie für clientseitige Komponenten und Dienste Unit-Tests der Benutzeroberfläche aus. - Führen Sie für neue oder geänderte Übungsaufgaben und schichtübergreifendes Verhalten durchgängige Tests aus. - Führen Sie vor dem Einreichen die gesamte Testsammlung des Repositorys aus, es sei denn, das Repository nimmt die geänderte Dokumentation ausdrücklich davon aus. - Prüfen Sie den für Benutzer sichtbaren Ablauf oder den Lösungsweg der Übungsaufgabe manuell. - Führen Sie das Sicherheitsnetz für die Refaktorierung von Übungsaufgaben immer aus, wenn sich vorhandener Quellcode zu Übungsaufgaben ändert. Verwenden Sie während der schrittweisen Bearbeitung die kleinste gezielte Testsammlung und führen Sie vor der Prüfung anschließend die vollständige erforderliche Matrix aus. Halten Sie die genauen Befehle und Ergebnisse fest. Behaupten Sie keinen Erfolg allein aufgrund statischer Analyse und überspringen Sie keine langsame Testsammlung, nur weil generierter Code plausibel erscheint. ## Übungscode und gespiegelte Korrekturdateien abgleichen Quellcode zu Übungsaufgaben kann in Codeausschnitten, erwarteten Korrekturen, Metadaten oder zwischengespeicherten Artefakten des Sicherheitsnetzes gespiegelt sein. Eine Refaktorierung ist unvollständig, wenn diese Darstellungen voneinander abweichen. 1. Führen Sie nach Änderungen an Code zu Übungsaufgaben das Sicherheitsnetz des Repositorys für deren Refaktorierung aus. 2. Falls es fehlschlägt, untersuchen Sie jeden gemeldeten Unterschied, statt den Zwischenspeicher sofort zu aktualisieren. 3. Bestimmen Sie, ob der Unterschied ein unbeabsichtigter Rückschritt oder ein beabsichtigter Teil der Änderung ist. 4. Wenden Sie bei einer beabsichtigten Refaktorierung die entsprechende Änderung auch auf die zugehörigen Korrekturartefakte und Codeausschnitte an. 5. Aktualisieren Sie den Zwischenspeicher der genehmigten Unterschiede erst, nachdem Quellcode, Verhalten der Übungsaufgabe und gespiegelte Artefakte konsistent sind. 6. Führen Sie das Sicherheitsnetz und den betreffenden Ablauf der Übungsaufgabe erneut aus. Verwenden Sie niemals eine Aktualisierung des Zwischenspeichers, um ungeklärte Unterschiede zu verbergen. Neues oder geändertes Verhalten einer Übungsaufgabe erfordert außerdem einen durchgängigen Nachweis dafür, dass die Aufgabe weiterhin erreichbar, lösbar und korrekt erkannt wird. ## Übersetzungen über die freigegebene Plattform einreichen und die Schlussprüfungen machen Bearbeiten Sie generierte oder extern verwaltete Lokalisierungsdateien nicht direkt. Reichen Sie Übersetzungsänderungen über die vom Repository genehmigte Lokalisierungsplattform ein, damit Ausgangstext, Prüfverlauf und generierte Dateien synchron bleiben. Vor dem Einreichen: - Vergewissern Sie sich, dass die Stilprüfungen bestanden wurden und alle generierten Rückstände beseitigt sind. - Vergewissern Sie sich, dass alle für die Änderung erforderlichen Unit-, Integrations-, Benutzeroberflächen-, durchgängigen und Sicherheitsnetzprüfungen bestanden wurden. - Prüfen Sie das Verhalten manuell und untersuchen Sie den abschließenden Änderungsvergleich auf unbeabsichtigte Änderungen. - Bestätigen Sie die Kompatibilität von Abhängigkeiten und Laufzeitumgebung. - Stellen Sie sicher, dass Commits die Abzeichnungsrichtlinie des Repositorys erfüllen. - Bauen Sie den Beitrag auf dem vorgeschriebenen Integrationszweig auf und verweisen Sie auf zugehörige Vorgänge. - Dokumentieren Sie komplexe Logik, Sicherheitsabsicht, ausgeführte Tests und alle genehmigten Ausnahmen. - Vergewissern Sie sich, dass alle Prüfungen der kontinuierlichen Integration bestanden wurden. Falls eine erforderliche Prüfung nicht ausgeführt werden konnte, nennen Sie diese Einschränkung ausdrücklich. Stellen Sie eine teilweise Überprüfung nicht als vollständige Prüfung der Sicherheit oder der Integrität der Übungsaufgabe dar.