© Krivosheev Vitaly/Shutterstock.com
Java Magazin
Wie sich Softwareentwicklung verändern muss, um sicher zu werden

Security by Design in einer DevOps-Welt

In der Softwareentwicklung hat sich der DevOps-Ansatz immer stärker durchgesetzt, um so eine effektivere und effizientere Zusammenarbeit in der Entwicklung, dem IT-Betrieb und der Qualitätssicherung voranzubringen. Um die Sicherheit der Produkte zu gewährleisten, müssen sich allerdings Kultur und Prozesse der Teams ändern.

Mark Geeslin


Frederick Brooks hat vor vielen Jahren in seinem berühmten Artikel „No Silver Bullet“ [1] überzeugend darauf hingewiesen, dass das Entwerfen und Entwickeln von Software von Natur aus ein schwieriger Prozess ist. Die der Softwareentwicklung inhärente Komplexität lässt sich demzufolge, außer in Details, nicht vereinfachen. Mehrheitlich genießt dieser Standpunkt Akzeptanz: Falsche Hoffnungen, bahnbrechende Vereinfachungen der Abläufe durch eigenwillige, zeitweilig beliebte Ideen wie visuelle Programmierung, formale Verifikation und dergleichen zu erreichen, werden ad acta gelegt. Es gibt jedoch immer noch viele, die glauben, dass sie auf diesen Gebieten doch noch den Durchbruch erzielen könnten. Allerdings dauert es in der Regel nur wenige Jahre, bis die Praxis ihre Fantasien mit Fakten korrigiert, zum Beispiel dem Fortbestehen von Bugs, überzogenen Deadlines, technischen Unzulänglichkeiten und ähnlichem mehr. Brooks behält Recht: Es gibt kein und wird auch nie ein Wundermittel geben, um die oftmals quälende Komplexität in der Softwareentwicklung zu überwinden.

Wenn die Entwicklung von Software also ein im Wesentlichen schwieriger Prozess ist, dann ist die Entwicklung sicherer Software ein noch schwierigerer Prozess. Eine Tatsache, die die überwiegende Mehrheit der Ingenieure, Forscher, Manager und Wissenschaftler in der Industrie zweifellos bestätigt. Seit dem Aufkommen der Securityidee in der Softwareentwicklung ist die Gewährleistung der Sicherheit eines Systems immer eine der anspruchsvollsten Aufgaben. Es ist schwierig genug, sicherzustellen, dass die Software in jedem vorstellbaren Nutzungsszenario tatsächlich das tut, wofür sie entwickelt wurde. Noch anspruchsvoller ist es, dafür zu sorgen, dass sie darüber hinaus nichts anderes kann, als das, wofür sie konzipiert wurde. Doch trotz des hohen Anspruchs ist das die zentrale Aufgabe, vor der Entwickler und Unternehmen stehen, wenn sie eine sichere Software programmieren wollen.

Werden darüber hinaus die aktuellen Praktiken von DevOps und Continuous Integration/Continuous Delivery (CI/CD) in diese ohnehin schon herausfordernde Welt eingebracht, droht ein sicherheitsbewusster Softwareentwickler zu verzweifeln. Ist es überhaupt möglich, einen Entwicklungskontext, eine Kultur oder Prozesse zu etablieren, die uns ein hohes Maß an Vertrauen in die Sicherheit von Software geben, die in einer groß angelegten DevOps- und Continuous-Deployment-Umgebung hergestellt wird? Das ließe sich ein wenig mit einer Organisat...

Java Magazin
Wie sich Softwareentwicklung verändern muss, um sicher zu werden

Security by Design in einer DevOps-Welt

In der Softwareentwicklung hat sich der DevOps-Ansatz immer stärker durchgesetzt, um so eine effektivere und effizientere Zusammenarbeit in der Entwicklung, dem IT-Betrieb und der Qualitätssicherung voranzubringen. Um die Sicherheit der Produkte zu gewährleisten, müssen sich allerdings Kultur und Prozesse der Teams ändern.

Mark Geeslin


Frederick Brooks hat vor vielen Jahren in seinem berühmten Artikel „No Silver Bullet“ [1] überzeugend darauf hingewiesen, dass das Entwerfen und Entwickeln von Software von Natur aus ein schwieriger Prozess ist. Die der Softwareentwicklung inhärente Komplexität lässt sich demzufolge, außer in Details, nicht vereinfachen. Mehrheitlich genießt dieser Standpunkt Akzeptanz: Falsche Hoffnungen, bahnbrechende Vereinfachungen der Abläufe durch eigenwillige, zeitweilig beliebte Ideen wie visuelle Programmierung, formale Verifikation und dergleichen zu erreichen, werden ad acta gelegt. Es gibt jedoch immer noch viele, die glauben, dass sie auf diesen Gebieten doch noch den Durchbruch erzielen könnten. Allerdings dauert es in der Regel nur wenige Jahre, bis die Praxis ihre Fantasien mit Fakten korrigiert, zum Beispiel dem Fortbestehen von Bugs, überzogenen Deadlines, technischen Unzulänglichkeiten und ähnlichem mehr. Brooks behält Recht: Es gibt kein und wird auch nie ein Wundermittel geben, um die oftmals quälende Komplexität in der Softwareentwicklung zu überwinden.

Wenn die Entwicklung von Software also ein im Wesentlichen schwieriger Prozess ist, dann ist die Entwicklung sicherer Software ein noch schwierigerer Prozess. Eine Tatsache, die die überwiegende Mehrheit der Ingenieure, Forscher, Manager und Wissenschaftler in der Industrie zweifellos bestätigt. Seit dem Aufkommen der Securityidee in der Softwareentwicklung ist die Gewährleistung der Sicherheit eines Systems immer eine der anspruchsvollsten Aufgaben. Es ist schwierig genug, sicherzustellen, dass die Software in jedem vorstellbaren Nutzungsszenario tatsächlich das tut, wofür sie entwickelt wurde. Noch anspruchsvoller ist es, dafür zu sorgen, dass sie darüber hinaus nichts anderes kann, als das, wofür sie konzipiert wurde. Doch trotz des hohen Anspruchs ist das die zentrale Aufgabe, vor der Entwickler und Unternehmen stehen, wenn sie eine sichere Software programmieren wollen.

Werden darüber hinaus die aktuellen Praktiken von DevOps und Continuous Integration/Continuous Delivery (CI/CD) in diese ohnehin schon herausfordernde Welt eingebracht, droht ein sicherheitsbewusster Softwareentwickler zu verzweifeln. Ist es überhaupt möglich, einen Entwicklungskontext, eine Kultur oder Prozesse zu etablieren, die uns ein hohes Maß an Vertrauen in die Sicherheit von Software geben, die in einer groß angelegten DevOps- und Continuous-Deployment-Umgebung hergestellt wird? Das ließe sich ein wenig mit einer Organisat...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang