Public Resources
k-develop

Software Project Review Guide (.NET)
Jannis Kühn

Vorschläge zur Sicherung der Qualität in agilen .NET Softwareprojekten.

Version 1.2.8

Feedback an jannis@k-develop.de
Siehe auch: Agile Project Review Guide

Anmerkungen, Vorschläge und Hinweise sind ausdrücklich erwünscht!


Inhaltsverzeichnis

1.Organisation
2.Entwicklung
2.1.Versionskontrolle
2.2.Fehlerbehandlung
2.3.Tests
2.4.Abhängigkeiten
3.Daten
3.1.Datenbanken
4.Dokumentation
4.1.Logging
5.Bereitstellung
5.1.Build
5.2.Deployment
6.Betrieb
6.1.Monitoring
7.Literatur

Tags: Architektur (8) Automatisierung (21) Disziplin (46) Kundenorientierung (14) Nachhaltigkeit (49) Nachvollziehbarkeit (33) Organisatorisch (53) Qualität (35) Security (36) Stabilität (32) (Filter zurücksetzen)


1Organisation

C129 Dem Anwender wird eine Möglichkeit geboten, Datenschutz- und Sicherheitsvorfälle unkompliziert und schnell über die Benutzeroberfläche zu melden.

Beispiel: Anonyme Meldung zu Datenschutz- und Sicherheitsvorfällen jederzeit möglich (z.B. Freitextfeld).

Tags: Kundenorientierung Nachhaltigkeit Organisatorisch Security

Änderung vorschlagen

C006 Bugs werden erfasst und immer mit höchster Priorität behoben.

Anmerkung: Jeder Bug in Produktion sollte als gleich wichtig und kritisch erachtet werden.

Tags: Disziplin Kundenorientierung Organisatorisch Security Stabilität

Änderung vorschlagen

C008 Test- und Produktionsdaten sind voneinander getrennt.

Beispiel: Auf Testdaten angewendete Operationen haben keine Wirkung auf Produktionssysteme.

Tags: Organisatorisch Security Stabilität

Änderung vorschlagen

C009 Testdaten sind anonymisiert und enthalten keine zuordenbare Nutzerinformationen.

Anmerkung: Datenschutz und diskreter Umgang mit Anwenderdaten.

Tags: Organisatorisch Qualität Security

Änderung vorschlagen

C010 Test- und Produktionssysteme sind voneinander getrennt.

Anmerkung: Fehler und Systemabstürze in der Testumgebung haben so keine Auswirkung auf das operative Geschäft.

Tags: Organisatorisch Security Stabilität

Änderung vorschlagen

2Entwicklung

C032 Umfangreiche Refaktorisierungsmaßnahmen werden mit dem kompletten Team besprochen.

Beispiel: Durch die Verteilung der Information werden die Maßnahmen bei zukünftigen Implementierungen beachtet.

Tags: Disziplin Nachhaltigkeit Organisatorisch Security

Änderung vorschlagen

C033 Statische Codeanalysen werden regelmäßig und automatisiert durchgeführt und fließen in den Entwicklungsprozess ein.

Beispiel: Sonarqube integriert im CI-Build

Tags: Automatisierung Nachhaltigkeit Qualität Security

Änderung vorschlagen

C121 Konfigurationsdateien enthalten ausschließlich verwendete Einträge. Nicht mehr genutzte Einträge werden konsequent aus den Dateien entfernt.

Beispiel: Obsolete Schlüssel-Wert-Paare, Verbindungszeichenfolgen, etc...

Tags: Disziplin Nachhaltigkeit Nachvollziehbarkeit Security

Änderung vorschlagen

C116 Alle verwendeten kryptografischen Verfahren gelten nach derzeitigem Stand als geeignet für den entsprechenden Anwendungsfall.

Beispiel: Hashing, Verschlüsselung, Zertifikate, etc...

Tags: Nachhaltigkeit Security

Änderung vorschlagen

C122 Es gibt ein Konzept für den Austausch von Hash-, bzw. Verschlüsselungsverfahren.

Beispiel: Austausch des Hashverfahrens für Nutzerpasswörter gegen ein stärkeres oder besser geeignetes Verwahren.

Tags: Kundenorientierung Nachhaltigkeit Organisatorisch Qualität Security

Änderung vorschlagen

C119 Technische Schnittstellen sind durch gängige Authentifizierungsmechanismen abgesichert.

Beispiel: OAuth für Web-APIs.

Tags: Nachhaltigkeit Organisatorisch Security

Änderung vorschlagen

C036 Passwörter und Verbindungszeichenfolgen sind ausschließlich verschlüsselt abgelegt.

Beispiel: Verschlüsselte Variablen in der Library auf Azure-Pipelines.

Tags: Organisatorisch Security

Änderung vorschlagen

C037 Parameter werden einheitlich durch zentrale Mechanismen validiert.

Beispiel: Regex-Verzeichnis und Assert-Klassen.

Tags: Qualität Security

Änderung vorschlagen

C126 Sitzungsidentifikatoren werden nach einer bestimmten Zeit Inaktivität ungültig.

Beispiel: Aktualisierung der Session-Cookies bei jeder Aktivität des Nutzers.

Tags: Nachhaltigkeit Security

Änderung vorschlagen

C127 Sitzungen werden nach einer konfigurierbaren Zeit ungültig.

Beispiel: Session-Cookies haben eine absolute Gültigkeit, unabhängig von der Aktivität des Nutzers.

Tags: Nachhaltigkeit Security

Änderung vorschlagen

C128 Sitzungsidentifikatoren werden nach erneutem Anmelden erneuert.

Beispiel: Neue SessionID.

Tags: Nachvollziehbarkeit Security

Änderung vorschlagen

C041 Bei der Verarbeitung von Texten ist die Kodierung immer explizit angegeben.

Beispiel: Für das Lesen und Schreiben von Daten wird explizit UTF-8 verwendet.

Tags: Nachvollziehbarkeit Security

Änderung vorschlagen

2.1 Versionskontrolle

C013 Für die Übernahme von Codeänderungen in den Hauptzweig des Code-Repositorys wird das Vier-Augen-Prinzip oder ein ähnliches Verfahren angewendet.

Beispiel: Pull-Request Verfahren mit verpflichtendem Review durch den Author und mindestens eine weitere Person.

Tags: Disziplin Organisatorisch Qualität Security

Änderung vorschlagen

C114 Verbindungszeichenfolgen und Geheimnisse sind nicht in das Code-Repository eingecheckt.

Beispiel: DB Connection-Strings, User-Credentials, OAuth Client-Secrets.

Tags: Disziplin Organisatorisch Security

Änderung vorschlagen

2.2 Fehlerbehandlung

2.3 Tests

2.4 Abhängigkeiten

C023 Alle eingebundenen Bibliotheken sind auf dem neusten Versionsstand.

Beispiel: Prüfung durch Nuget Package Manager

Tags: Security Stabilität

Änderung vorschlagen

3Daten

C045 Sämtliche Daten sind nach geltenden Datenschutzrichtlinien klassifiziert.

Beispiel: Klassifizierung nach öffentlichen, internen, vertraulichen und geheimen Daten.

Tags: Disziplin Nachhaltigkeit Organisatorisch Security

Änderung vorschlagen

C046 Persönliche Daten sind verschlüsselt abgelegt.

Beispiel: Kontaktinformationen, Zahlungsmittel, Geburtsdaten...

Tags: Nachhaltigkeit Organisatorisch Security

Änderung vorschlagen

C060 Für die Abfrage von Datensätzen, durch externe Komponenten oder Benutzer der Applikation, wird als Identifikationsmerkmal keine fortlaufende, nummerische ID verwendet.

Beispiel Eine UUID als Identifikationsmerkmal kann nur schwer erraten werden.

Tags: Organisatorisch Security

Änderung vorschlagen

3.1 Datenbanken

C049 Sämtliche eingehende Daten werden seitens der Datenbank validiert.

Beispiel: Explizite typisierung parametrisierter Datenbankprozeduren.

Tags: Disziplin Qualität Security

Änderung vorschlagen

C055 Zum Lesen und Schreiben von Daten existieren separate Datenbankbenutzer.

Beispiel: Die Applikation "Sample" benutzt die DB-User "app_sample_read" und "app_sample_write". Aus dem Namen des DB-Users lässt sich die zugehörige Applikation ableiten.

Tags: Nachvollziehbarkeit Organisatorisch Security

Änderung vorschlagen

C056 Jede Komponente nutzt eigene Datenbankbenutzer mit entsprechend eingeschränkten Rechten.

Beispiel: Jedes fachlich getrennte Modul erhält einen "read" und einen "write" DB-User. Aus dem Namen des DB-Users lässt sich das zugehörige Applikationsmodul ableiten.

Tags: Nachvollziehbarkeit Organisatorisch Security

Änderung vorschlagen

C057 CRUD Operationen werden von der Datenbank ausschließlich über Funktionen, Prozeduren und Views bereitgestellt. Die Applikation hat keinen direkten Zugriff auf einzelne Tabellen und besitzt keine "Kenntnis" über die interne Tabellenstruktur.

Anmerkung: Insbesondere die richtige Anwendung von typisierten Parametern verhindert die meisten Angriffe per SQL-Injection.

Tags: Nachhaltigkeit Organisatorisch Security

Änderung vorschlagen

C059 Fortlaufende IDs werden nicht von der Applikation, sondern von dem Datenbanksystem generiert.

Anmerkung: Falls möglich sollten UUIDs bevorzugt werden, da diese nur schwer erraten werden können.

Tags: Nachhaltigkeit Qualität Security Stabilität

Änderung vorschlagen

C063 Datenbanken sind so konfiguriert, dass sie in den Produktiven Umgebungen nicht auf Anfragen zu Instanzinformationen antworten.

Beispiel: MS SQL "Hidden SQL Server Instance" oder "Turn off SQL Server Browser".

Tags: Nachhaltigkeit Organisatorisch Security

Änderung vorschlagen

C064 Die Anmeldung von globalen Root-Usern an einem Datenbanksystem ist nur von bestimmten Systemen aus erlaubt.

Beispiel: Einschränkung auf 127.0.0.1 (localhost).

Tags: Nachhaltigkeit Organisatorisch Security

Änderung vorschlagen

4Dokumentation

C070 Firewallregeln sind dokumentiert und werden bei jedem Release auf Notwendigkeit geprüft.

Anmerkung: Sollte eine Firewallregel nicht mehr notwendig sein, wird sie wieder entfernt.

Tags: Disziplin Nachhaltigkeit Security

Änderung vorschlagen

C084 Alle ein- und ausgehenden Netzwerkverbindungen der Applikation sind dokumentiert.

Beispiel: Netzwerkadresse des Zielsystems, Netzwerkkonfiguration (Proxy, etc.), Fachliche Beziehungen, Abhängigkeiten, Kritikalität bei Ausfall der Verbidung.

Tags: Nachhaltigkeit Nachvollziehbarkeit Organisatorisch Security Stabilität

Änderung vorschlagen

4.1 Logging

C080 Persönliche Nutzerinformationen (PII) sind in dem technischen Anwendungsprotokoll nicht enthalten.

Anmerkung: Auschluss von Adressen, Kontodaten und weiteren Identifikationsmerkmalen.

Tags: Disziplin Kundenorientierung Organisatorisch Security

Änderung vorschlagen

5Bereitstellung

5.1 Build

5.2 Deployment

C120 Sensible Sektionen der Konfiguration auf den Host-Systemen sind verschlüsselt.

Beispiel: Verschlüsselung durch ASPNET_REGIIS bei ASP.NET oder andere Verfahren.

Tags: Automatisierung Nachhaltigkeit Security

Änderung vorschlagen

6Betrieb

C105 Das Datenbanksystem wird regelmäßig gepatcht und läuft auf der aktuellen Version.

Beispiel: Teil jedes Sprints ist die Durchsicht der Release-Notes verwendeter Softwarekomponenten.

Tags: Disziplin Security Stabilität

Änderung vorschlagen

C106 Alle Systemkomponenten haben einen aktuellen Patch-Stand.

Beispiel: Datenbank, Webserver, Hostsystem, ...

Tags: Security Stabilität

Änderung vorschlagen

6.1 Monitoring

7Literatur


Kontakt: jannis@k-develop.de
Dokument: https://k-develop.de/SoftwareProjectReviewGuide
Impressum: https://k-develop.de/

Guide Version: 1.2.8 (09.06.2020)
Major: Große strukturelle Änderungen
Minor: Nummern neu vergeben (z.B. C053 auf C065)
Patch: Neue Kapitel, Neue Einträge, Textanpassung, Reihenfolge

Last Page Update: 26.06.2020

Guides
Agile Projects: https://k-develop.de/AgileProjectReviewGuide
Software Projects: https://k-develop.de/SoftwareProjectReviewGuide


Datenschutzerklärung:

Der Webserver protokolliert Seitenzugriffe und die IP-Adressen der Aufrufer. Diese Protokolle werden ausschließlich zur Fehlersuche ausgewertet. Da es auf dieser Seite keine Benutzerkonten oder Tracking-Cookies gibt, sind diese Daten keiner Person zuordenbar und werden damit als nicht Personenbezogen betrachtet. Abgesehen davon werden keine Daten erhoben, gespeichert oder ausgewertet.

© 2020 Jannis Kühn Rights Reserved