Willkommen im SSDLC Hub von dimedis. Diese Dokumentation bündelt unsere Leitlinien, Checklisten und Vorlagen rund um sichere Softwareentwicklung nach ISO 27001. Nutze die linke Navigation, um schnell zu den Phasen-Checklisten, dem Glossar oder Beispielen für Sicherheitsartefakte zu springen.

Keine Angst vor der ISO 27001 #

Auch wenn ISO 27001 für Entwicklerinnen und Entwickler ungewohnt klingt: Ihr müsst keine Auditoren werden. Wir wollen nur zeigen, wie sich bewährte Engineering-Praktiken mit ein paar zusätzlichen Nachweisen verbinden lassen. Denkt ISO weniger als Bürokratie, sondern als Mindset-Shift hin zu “Security by Default”. Kleine Schritte wie saubere Tickets, nachvollziehbare Reviews oder dokumentierte Scans reichen aus, um Vertrauen aufzubauen. Ihr seid nicht allein – die Vorlagen, Leitfäden und Beispiele in diesem Hub nehmen euch an die Hand und zeigen, wie jedes Artefakt aussehen kann. Traut euch, Fragen zu stellen und Feedback zu geben: Die Norm hilft uns nur, wenn wir sie auf den Alltag im Code übersetzen.

Fünf Kernprinzipien für ISO-27001-konforme Projekte #

• Sicherheitsziele und Risiken früh klären und dokumentieren (Planungs-Checkliste nutzen).
• Standards im Code leben: definierter Tech-Stack, Reviews und Policiescans pro Release.
• Tests ernst nehmen: SAST, SCA und – wo sinnvoll – DAST in der CI/CD belegen.
• Artefakte versionieren: Nachweise in docs/ und scan-reports/ ablegen, Tickets verlinken.
• Kommunikation pflegen: Abnahmen, Ausnahmen und Monitoring-Folgen im Team transparent halten.

Was erwartet euch im Audit? #

Auditoren starten meist mit Dokumenten: sie prüfen Checklisten, Tickets und Reports von ein bis zwei Releases. Danach folgen Stichproben in Repos oder CI/CD-Pipelines. Rechnet damit, dass Security Champion, Lead Developer und ein zufällig ausgewähltes Feature-Team in kurzen Interviews erläutern, wie Sicherheitsziele, Tests und Ausnahmen gehandhabt werden. Bereitet euch vor, indem ihr aktuelle Artefakte parat habt, zeigen könnt, wo sie liegen und wie ihr im Alltag damit arbeitet. Ehrliche Antworten plus ein klarer Verweis auf eure Nachweise überzeugen mehr als perfektes Auswendiglernen.

Warum die Doku ins Repository gehört #

Unser Git/SVN-Repository ist die erste Anlaufstelle für Entwickler, Product Owner und Auditoren. Wenn alle Sicherheitsdokumente dort liegen, findet jeder sofort die passende Version zum jeweiligen Code-Stand – Branch, Tag oder Commit liefern das Änderungsprotokoll kostenlos mit. Confluence & Co. eignen sich für Übersichtsseiten oder Prozessbeschreibungen, aber die verlässlichen Nachweise sollten im Repo leben. So vermeidet ihr, dass beim Audit oder Onboarding erst das ganze Team gefragt werden muss, wo die Wahrheit steht. Stattdessen verlinkt ihr von den Markdown- Dateien im Repo aus zu weiterführenden Quellen; wer im Repo startet, erreicht alle anderen Systeme ohne Medienbruch. Das spart Zeit, reduziert Fehler und macht Prüfungen transparenter.