Software-Sicherheit im Unternehmen: der Praxisleitfaden 2026

Software-Sicherheit im Unternehmen kaufen Sie nicht als fertiges Produkt. Sie entsteht, wenn Sicherheit in jeder Phase einer Anwendung mitgeplant wird: bei der Anforderung, im Code, beim Testen, im Betrieb und bei der Wartung. Virenscanner und Firewalls schützen Ihre Infrastruktur. Gegen eine Webanwendung, die Zugriffsrechte falsch prüft, oder gegen eine veraltete Bibliothek in Ihrer Kundenplattform helfen sie wenig. In diesem Leitfaden zeigen wir, wie Sie Security by Design und einen sicheren Entwicklungszyklus in der Praxis umsetzen, wofür die OWASP Top 10 gut sind und welche Pflichten durch NIS-2 und den Cyber Resilience Act auf Unternehmen zukommen.

Mintellity

Sicherheit passend zur Software planen

Mintellity entwickelt Softwarelösungen, die sich an den individuellen Prozessen Ihres Unternehmens orientieren und langfristig weiterentwickelt werden.

Softwarelösungen ansehen

TL;DR

Software-Sicherheit ist eine Prozessfrage: Sie beginnt mit Bedrohungsmodell und Sicherheitsanforderungen, nicht erst beim Penetrationstest kurz vor dem Go-live.
Der sichere Lebenszyklus deckt alles ab, von der Idee bis zur Wartung. Das BSI beschreibt ihn in der Technischen Richtlinie TR-03185.
Die OWASP Top 10 sind eine bewährte Prüfliste für die häufigsten Risiken in Webanwendungen, aber kein vollständiges Sicherheitskonzept.
Regulierung macht Sicherheit nachweispflichtig: NIS-2 und der Cyber Resilience Act verlangen dokumentierte Maßnahmen bei Entwicklung, Wartung und Schwachstellenmanagement.
Eine Cyberversicherung ergänzt, ersetzt aber nichts: Versicherer setzen ein Mindestniveau an IT-Sicherheit voraus.

Software-Sicherheit und IT-Sicherheit: der Unterschied

Viele Unternehmen setzen beides gleich, dabei sind es zwei Ebenen. IT-Sicherheit schützt Ihre Infrastruktur: Netzwerke, Endgeräte, E-Mail, Zugänge. Typische Werkzeuge sind Endpoint-Schutz, Firewalls, Backups und Mitarbeiterschulungen.

Software-Sicherheit setzt eine Ebene tiefer an, nämlich bei den Anwendungen selbst. Die entscheidenden Fragen lauten hier:

Prüft Ihr Kundenportal bei jeder Anfrage, ob der angemeldete Nutzer diese Daten überhaupt sehen darf?
Werden Eingaben in Formularen und Schnittstellen sauber validiert, bevor sie in eine Datenbank gelangen?
Wissen Sie, welche Open-Source-Bibliotheken in Ihrer Webanwendung stecken und ob es für sie bekannte Schwachstellen gibt?
Werden Passwörter, Tokens und API-Schlüssel sicher gespeichert, oder stehen sie irgendwo im Quellcode?

Diese Fragen löst kein Sicherheitsprodukt von der Stange. Sie werden im Design und im Code entschieden. Deshalb betrifft Software-Sicherheit jedes Unternehmen, das eigene Anwendungen betreibt oder entwickeln lässt: den Online-Shop mit Warenwirtschaftsanbindung genauso wie die interne Lager-App oder die KI-gestützte Dokumentenverarbeitung.

Für Unternehmen mit individuell entwickelter Software ist das eine gute Nachricht. Sie haben die Sicherheitsarchitektur selbst in der Hand, statt darauf zu warten, dass ein Hersteller Lücken schließt. Das BSI-Grundschutz-Baustein CON.8 zur Software-Entwicklung hält ausdrücklich fest, dass viele Institutionen ihre Herausforderungen nicht mehr mit fertiger, unangepasster Software lösen können. Er beschreibt deshalb, welche Anforderungen für eine sichere Eigen- oder Auftragsentwicklung gelten.

Warum der Mittelstand im Fokus steht

Angreifer suchen den Weg des geringsten Widerstands. In seiner Analyse zur Gefährdungslage kleiner und mittlerer Unternehmen beschreibt das BSI die Lage für die rund 3,1 Millionen KMU in Deutschland als weiterhin angespannt und stellt fest, dass viele es Angreifern immer noch zu leicht machen.

Die Behörde bewertet die Lage dabei nicht nur über die Zahl der Angriffe. Die Systematik der Lagebewertung unterscheidet fünf Dimensionen: Bedrohungen, Angriffsfläche, Gefährdungen, Schadwirkungen und Resilienz. Für Ihre Software sind vor allem zwei davon interessant, denn auf sie haben Sie direkten Einfluss:

Angriffsfläche: Jede öffentlich erreichbare Webanwendung, jede Schnittstelle und jede ungepflegte Komponente vergrößert sie. Weniger offene Endpunkte, schlanke Abhängigkeiten und konsequente Updates verkleinern sie.
Resilienz: Damit ist gemeint, wie gut Ihr System einen Vorfall erkennt, eindämmt und sich davon erholt. Das hängt von Logging, Backups, Notfallplänen und einer gepflegten Codebasis ab.

Der Lagebericht zur IT-Sicherheit in Deutschland 2025 gibt einen kompakten Überblick über diese Entwicklungen und eignet sich gut als Gesprächsgrundlage für die Geschäftsführung.

Security by Design: Sicherheit vor der ersten Codezeile

Security by Design heißt: Sicherheit wird als Anforderung behandelt, so wie Funktionen und Performance auch. Sie ist kein Zusatzmodul, das kurz vor dem Livegang noch angeschraubt wird. Das BSI formuliert in der Technischen Richtlinie TR-03185 „Sicherer Software-Lebenszyklus“ genau diesen Anspruch an Hersteller: Informationssicherheit gehört über den gesamten Lebenszyklus eines Produkts hinweg verankert.

In der Praxis heißt das, schon in der Konzeptphase konkrete Fragen zu stellen:

Welche Daten verarbeitet die Anwendung? Personenbezogene Kundendaten, Preiskalkulationen und Produktionsdaten haben jeweils einen anderen Schutzbedarf.
Wer darf was? Ein sauberes Rollen- und Rechtekonzept entsteht am Whiteboard, nicht als nachträglicher Patch.
Wo sind die Vertrauensgrenzen? Überall dort, wo Daten von außen kommen, etwa über Formulare, Schnittstellen, Datei-Uploads oder KI-Eingaben, wird geprüft und gefiltert.
Was passiert im Fehlerfall? Eine Anwendung, die bei einem Fehler Stacktraces mit Datenbankdetails ausgibt, verrät Angreifern mehr als nötig.

Das zentrale Werkzeug dafür ist die Bedrohungsmodellierung. Das Team spielt systematisch durch, wie ein Angreifer die Anwendung missbrauchen könnte, und leitet daraus Gegenmaßnahmen ab. Das klingt aufwendig. Für ein überschaubares Projekt reicht aber oft ein halbtägiger Workshop mit Produktverantwortlichen und Entwicklern. Jede Lücke, die Sie so im Konzept finden, müssen Sie später nicht teuer im Live-System beheben.

Datenschutz gehört direkt dazu. Privacy by Design und Security by Design greifen ineinander, und wer beides gemeinsam plant, spart doppelte Arbeit. Worauf es dabei konkret ankommt, haben wir in unserem Beitrag zu DSGVO-konformer Software zusammengefasst.

Der sichere Entwicklungszyklus in sechs Phasen

Der Secure Development Lifecycle, kurz SDL, übersetzt Security by Design in einen wiederholbaren Ablauf. Es gibt verschiedene Modelle. Im Kern laufen sie auf diese sechs Phasen hinaus:

Anforderungen und Schutzbedarf: Sicherheitsanforderungen werden zusammen mit den fachlichen Anforderungen definiert und dokumentiert. Dazu gehören Authentifizierung, Verschlüsselung, Protokollierung und Aufbewahrungsfristen.
Design und Bedrohungsmodell: Die Architektur wird auf Angriffsszenarien geprüft. Hier fallen Entscheidungen wie die Trennung von Mandanten, die Absicherung von Schnittstellen und die Wahl der Authentifizierungsverfahren.
Sichere Implementierung: Das Team arbeitet mit verbindlichen Coding-Richtlinien, Code-Reviews nach dem Vier-Augen-Prinzip und bewährten Frameworks, statt Sicherheitsfunktionen selbst zu erfinden. Geheimnisse wie API-Schlüssel landen in einem Secrets-Management, nicht im Repository.
Automatisierte und manuelle Tests: Statische Codeanalyse (SAST) und Abhängigkeitsprüfungen laufen automatisch in der CI/CD-Pipeline. Dynamische Tests (DAST) und bei kritischen Anwendungen ein Penetrationstest ergänzen sie vor größeren Releases.
Sicheres Deployment und Betrieb: Gehärtete Server- und Cloud-Konfigurationen, minimale Rechte für Dienste, zentrale Protokollierung und Monitoring sorgen dafür, dass Auffälligkeiten früh sichtbar werden. Wie das gelingt, zeigt unser Fahrplan zum zentralen Logging.
Wartung und Schwachstellenmanagement: Abhängigkeiten werden regelmäßig aktualisiert, neue Schwachstellen bewertet und priorisiert behoben. Ein manuell gepflegtes Patch-Management ist ohne Automatisierung fehleranfällig. Werkzeuge, die veraltete Bibliotheken automatisch melden, gehören deshalb zum Standard.

Gerade Phase 6 wird oft unterschätzt. Software, die am Tag des Go-live sicher war, ist es nach zwei Jahren ohne Pflege meist nicht mehr, weil sich die Bedrohungen und die eingesetzten Komponenten weiterentwickeln. Unsere Best Practices zur Softwarewartung zeigen, wie Sie das organisatorisch aufstellen.

Zum Lebenszyklus gehört auch Transparenz gegenüber den Nutzern. Ein gutes Beispiel liefert das Handbuch zu Sicherheit und Datenschutz einer Dispositionssoftware für Sicherheitsdienste: Es erklärt Anwendern verständlich, wie ihre Daten geschützt werden. Eine solche Dokumentation schafft Vertrauen und zwingt das eigene Team, die Sicherheitsmaßnahmen klar zu benennen.

Die OWASP Top 10 als Prüfliste für Webanwendungen

Das Open Worldwide Application Security Project (OWASP) veröffentlicht in regelmäßigen Abständen eine Rangliste der häufigsten Sicherheitsrisiken in Webanwendungen. Die jüngste Ausgabe stammt aus dem Jahr 2025. Wer nach einer Version für 2026 sucht, landet deshalb in der Regel bei dieser Liste. Die Top 10 sind kein Standard, den man „erfüllt“. Sie sind ein gemeinsamer Wortschatz für Entwickler, Tester und Auftraggeber und eine gute erste Prüfliste.

Die folgenden Risikoklassen ziehen sich seit Jahren durch die Liste. Die Tabelle zeigt, was dahintersteckt und wo Sie im Lebenszyklus gegensteuern:

Risikoklasse	Typisches Beispiel	Wirksame Gegenmaßnahme	Phase im Lebenszyklus
Fehlerhafte Zugriffskontrolle	Nutzer ändert eine ID in der URL und sieht fremde Bestellungen	Berechtigungen serverseitig bei jeder Anfrage prüfen	Design, Implementierung
Sicherheitsrelevante Fehlkonfiguration	Standardpasswörter, offene Admin-Oberflächen, ausführliche Fehlermeldungen	Gehärtete Konfigurationen, Infrastructure as Code, regelmäßige Prüfung	Deployment, Betrieb
Schwachstellen in der Software-Lieferkette	Veraltete oder manipulierte Open-Source-Bibliothek	Abhängigkeiten inventarisieren (SBOM), automatisch prüfen und aktualisieren	Implementierung, Wartung
Kryptografische Schwächen	Unverschlüsselte Übertragung, schwache Passwort-Hashes	Aktuelle Verfahren, TLS überall, bewährte Bibliotheken	Design, Implementierung
Injection	SQL-Befehle über ein Suchfeld einschleusen	Parametrisierte Abfragen, Eingabevalidierung	Implementierung, Test
Unsicheres Design	Passwort-Reset ohne ausreichende Prüfung	Bedrohungsmodellierung, Sicherheitsanforderungen	Anforderungen, Design
Schwache Authentifizierung	Keine Begrenzung von Login-Versuchen, kein zweiter Faktor	MFA, Rate Limiting, sichere Sitzungsverwaltung	Design, Implementierung
Unzureichendes Logging und Monitoring	Angriff bleibt wochenlang unbemerkt	Zentrale Protokollierung mit Alarmierung	Betrieb

Schnittstellen verdienen besondere Aufmerksamkeit. Für APIs pflegt OWASP eine eigene Liste, weil dort andere Fehler dominieren, etwa fehlende Berechtigungsprüfungen auf Objektebene. Wenn Sie mehrere Systeme über Schnittstellen verbinden, sollten Sie auch einen geordneten Lebenszyklus für die APIs selbst haben. Unser Beitrag zur API-Versionierung zeigt, wie alte, ungesicherte Versionen geordnet abgeschaltet werden.

Regulatorische Pflichten: NIS-2, Cyber Resilience Act und DSGVO

Software-Sicherheit war lange vor allem eine Frage guter Praxis. Inzwischen ist sie zunehmend Pflicht, die Sie dokumentieren und nachweisen müssen.

NIS-2: mehr Unternehmen unter Aufsicht

Mit dem aktuellen BSI-Gesetz wird das BSI laut seiner Übersicht zu den NIS-2-Pflichten für deutlich mehr Unternehmen zuständig als bisher, nämlich für rund 29.500 „besonders wichtige“ und „wichtige“ Einrichtungen. Zu den geforderten Maßnahmen zählen ausdrücklich Sicherheit bei Erwerb, Entwicklung und Wartung von IT-Systemen sowie ein strukturiertes Schwachstellenmanagement. Auch wenn Ihr Unternehmen nicht selbst unter NIS-2 fällt: Sind Ihre Kunden betroffen, werden sie diese Anforderungen an ihre Software-Lieferanten weitergeben. Ob und wie Ihr Unternehmen konkret betroffen ist, klären Sie am besten mit dem Betroffenheitscheck des BSI und im Zweifel mit einer auf IT-Recht spezialisierten Kanzlei.

Cyber Resilience Act: Sicherheit für Produkte mit digitalen Elementen

Der Cyber Resilience Act der EU richtet sich an Hersteller von Produkten mit digitalen Elementen, also auch an Unternehmen, die Software vertreiben. Er verlangt, dass Sicherheit über den gesamten Lebenszyklus dokumentiert wird, von der ersten Idee bis zur Wartung. Die BSI-Richtlinie TR-03185 bietet dafür eine praxisnahe Orientierung. Das betrifft auch kleinere Softwareanbieter: Rein funktionale Entwicklung ohne nachvollziehbare Sicherheitsprozesse wird künftig nicht mehr genügen. Prüfen Sie Fristen und Anwendungsbereich anhand der offiziellen Informationen von EU und BSI, denn die Pflichten greifen gestaffelt.

DSGVO und KI-Anwendungen

Die DSGVO verlangt geeignete technische und organisatorische Maßnahmen für personenbezogene Daten. Kommt es zu einer Datenpanne, gilt in der Regel eine Meldefrist von 72 Stunden an die Aufsichtsbehörde. Darauf weist auch der Ratgeber zur Cyberversicherung hin. Neu hinzu kommen KI-Anwendungen: Wer Sprachmodelle in Prozesse einbindet, muss klären, welche Daten in welche Systeme fließen dürfen. Eine interne Richtlinie schafft hier Klarheit. Warum viele Unternehmen dafür eine eigene AI Policy brauchen, lohnt sich vor jeder KI-Integration zu lesen. Technisch sichern wir KI-Lösungen genauso ab wie jede andere Schnittstelle, mit Eingabeprüfung, Rechtekonzept und Protokollierung. Mehr dazu in unserem Aktionsplan zur KI-Integration im Unternehmen.

Cyberversicherung: Risikotransfer statt Schutzschild

Viele Unternehmen fragen, ob sie gegen Cyberangriffe versichert sind oder sein sollten. Eine Cyberversicherung kann die finanziellen Folgen eines Vorfalls abfedern, etwa Kosten für Forensik, Betriebsunterbrechung oder Haftungsansprüche. Sie ist aber eine Maßnahme zum Risikotransfer und keine Sicherheitsmaßnahme.

Versicherer setzen laut dem genannten Ratgeber ein Mindestniveau an IT-Sicherheit voraus, häufig zum Beispiel Multi-Faktor-Authentifizierung für Fernzugriffe, E-Mail und administrative Konten. Fehlt im Schadenfall eine zugesagte Maßnahme, kann die Leistung gekürzt oder abgelehnt werden. Gesetzliche Meldepflichten bleiben ohnehin beim Unternehmen. Auch der Markt verändert sich: Die Marktanalyse von CyberDirekt beschreibt, wie Versicherer ihre Produkte an die Bedrohungslage und die Schadenerfahrungen anpassen. Lassen Sie die Fragebögen des Versicherers deshalb von jemandem beantworten, der Ihre Systeme technisch kennt, und gleichen Sie die Bedingungen vor Vertragsschluss mit einem Versicherungsmakler ab.

Unsere Sicht: Sicherheit ist eine Partnerschaft, kein Abnahmetermin

In unseren Projekten erleben wir immer wieder dasselbe Muster: Sicherheit wird als Prüfpunkt am Ende verstanden, als Test, der kurz vor dem Go-live bestanden werden muss. Wir sehen das anders. Die wirksamsten Sicherheitsentscheidungen fallen in den ersten Wochen eines Projekts, wenn wir gemeinsam mit unseren Kunden die Geschäftsprozesse verstehen. Wer genau weiß, welche Abteilung welche Daten braucht, baut ein Rechtekonzept, das zum Alltag passt. Und ein Rechtekonzept, das zum Alltag passt, wird nicht durch Sammelkonten und geteilte Passwörter umgangen.

Deshalb ist für uns Prozessnähe auch Sicherheitsarbeit. Maßgeschneiderte Software hat hier einen echten Vorteil: Sie enthält nur die Funktionen, die gebraucht werden. Das bedeutet weniger Angriffsfläche, weniger ungenutzte Module und weniger Komponenten, die gepflegt werden müssen.

Genauso wichtig ist uns, was nach dem Launch passiert. Software lebt weiter, Abhängigkeiten altern, neue Schwachstellen werden bekannt. In langfristigen Partnerschaften entwickeln wir Anwendungen kontinuierlich weiter, halten Komponenten aktuell und reagieren, wenn sich die Lage ändert. Das ist für uns der Kern von Zukunftssicherheit: kein einmaliges Zertifikat, sondern ein System, das mit Ihrem Unternehmen wächst und dabei sicher bleibt.

— Mintellity

Sichere Software mit uns planen

Sie planen eine neue Webanwendung, eine App oder eine KI-Integration und möchten Sicherheit von Anfang an richtig verankern? Oder Sie betreiben ein gewachsenes System, bei dem niemand mehr genau weiß, welche Komponenten darin stecken? Mit unserer individuellen Softwareentwicklung bauen wir Lösungen, die exakt zu Ihren Prozessen passen und Sicherheit vom ersten Workshop an mitdenken. Für bestehende Anwendungen bringen wir mit Softwaremodernisierung veraltete Technik auf einen sicheren Stand und halten sie mit Wartung und Support dauerhaft aktuell. Wie wir dabei konkret vorgehen, lesen Sie unter So arbeiten wir.

Häufige Fragen zur Software-Sicherheit

Ist Standardsoftware sicherer als Individualsoftware?

Nicht grundsätzlich. Standardsoftware wird von vielen Nutzern eingesetzt, Lücken werden deshalb schnell bekannt, aber auch breit ausgenutzt. Individualsoftware hat eine kleinere Angriffsfläche und eine Architektur, die Sie selbst bestimmen, braucht aber einen sauberen Entwicklungs- und Wartungsprozess. Eine ausführliche Entscheidungshilfe finden Sie in unserem Vergleich Standardsoftware vs. Individualsoftware.

Was kostet ein sicherer Entwicklungsprozess?

Das hängt vom Schutzbedarf und vom Umfang der Anwendung ab. Viele Maßnahmen, etwa automatisierte Codeanalyse, Abhängigkeitsprüfungen und Code-Reviews, lassen sich mit überschaubarem Aufwand in bestehende Abläufe integrieren. Teurer wird es fast immer, wenn Sicherheitslücken erst im Live-Betrieb gefunden werden, weil dann Architektur und Daten betroffen sein können.

Wie oft sollte eine Webanwendung auf Sicherheit geprüft werden?

Automatisierte Prüfungen sollten bei jedem Code-Änderungsstand in der Pipeline laufen. Ergänzend empfiehlt sich ein manueller Test oder Penetrationstest vor größeren Releases und nach wesentlichen Architekturänderungen. Abhängigkeiten sollten Sie laufend überwachen, denn neue Schwachstellen werden unabhängig von Ihrem Release-Rhythmus bekannt.

Wie viel verdient man in der IT-Sicherheit?

Nach der Berufsgruppen-Statistik der Bundesagentur für Arbeit liegt das mittlere monatliche Bruttogehalt vollzeitbeschäftigter IT-Fachkräfte bei etwa 6.114 Euro. Expertenrollen wie IT-Sicherheitskoordinatoren liegen im Median zwischen rund 6.200 und 6.500 Euro. Für viele mittelständische Unternehmen ist ein eigenes Sicherheitsteam deshalb eine große Investition, und ein externer Entwicklungspartner mit Sicherheitserfahrung kann die Lücke schließen.

Quellen