[{"data":1,"prerenderedAt":758},["ShallowReactive",2],{"/de-de/blog/what-is-a-rest-api-guide-and-functions":3,"navigation-de-de":37,"banner-de-de":441,"footer-de-de":451,"blog-post-authors-de-de-GitLab Germany Team":656,"blog-related-posts-de-de-what-is-a-rest-api-guide-and-functions":671,"assessment-promotions-de-de":709,"next-steps-de-de":748},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":25,"isFeatured":12,"meta":26,"navigation":27,"path":28,"publishedDate":20,"seo":29,"stem":33,"tagSlugs":34,"__hash__":36},"blogPosts/de-de/blog/what-is-a-rest-api-guide-and-functions.yml","What Is A Rest Api Guide And Functions",[7],"gitlab-germany-team",null,"devsecops",{"slug":11,"featured":12,"template":13},"what-is-a-rest-api-guide-and-functions",false,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22},"Was ist eine REST-API? Guide & Funktionen","REST-APIs sind der de-facto-Standard für die Kommunikation zwischen Server und Client. Erfahren Sie hier alles Wissenswerte zum Thema!",[18],"GitLab Germany Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662858/Blog/Hero%20Images/API-REST.jpg","2024-10-16","REST-APIs sind seit über zwei Jahrzehnten ein zentraler Baustein des Internets. Bei ihnen handelt es sich um Programmierschnittstellen (APIs), die den Austausch von Daten zwischen Client und Server regeln. REST-APIs unterliegen einem Satz von Bedingungen, welche der Wissenschaftler Roy Fielding im Jahr 2000 entwickelt und unter der Abkürzung REST (representational state transfer) [festgelegt hat](https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7 \"festgelegt hat\").\n\nREST legt die genaue technische Umsetzung dieser Schnittstellen nicht fest. Fielding hat REST vielmehr als einen „Architektur-Stil“ [bezeichnet](https://www.youtube.com/watch?v=6oFAmQUM8ws \"bezeichnet\"), der eine Vielzahl praktischer Lösungen erlaubt. Jede API, die sich innerhalb der Grenzen dieser Architektur bewegt, entspricht dem REST-Standard.\n\nIn diesem Artikel zeigen wir Ihnen, warum sich REST seit seiner Einführung zum dominanten Modell entwickelt hat und welche Vorteile sich für Web-Development-Teams daraus ergeben. \n\n## Constraints: Die Grundbausteine der REST-Architektur\n\nREST baut auf insgesamt sechs sogenannten „Constraints“ (Einschränkungen) auf. \n\nAus ihnen ergibt sich eine Architektur, die einfach und anpassungsfähig ist und auch in einem rasch wandelnden Geschäftsumfeld langfristig Bestand haben kann.\n\n## Definition: Was ist eine Rest-API?\n\nREST-APIs sind praktische Softwarelösungen, die auf der REST-Dokumentation aufbauen und gemäß der folgenden sechs REST-Prinzipien für ein Client-Server-Modell erstellt werden: \n\n- Unabhängigkeit zwischen Client und Server,\n- Zustandslosigkeit,\n- ein mehrschichtiges Systemmodell, \n- eine einheitliche Schnittstelle,\n- Cache-Fähigkeit und\n- ein optionales Constraint: Code on Demand.\n\nIn den folgenden Abschnitten betrachten wir diese Constraints genauer. \n\n### Unabhängigkeit zwischen Client und Server\n\nREST findet wie erwähnt für APIs Anwendung, die den Austausch von Ressourcen zwischen einem Client und einem Server ermöglichen. Entscheidend ist, dass Client und Server vollkommen unabhängig voneinander bleiben. \n\nSo kann beispielsweise der Code des Servers verändert werden, ohne dass der Client ebenfalls Änderungen vornehmen muss, um weiterhin Informationen anfragen und erhalten zu können. \n\n### Zustandslosigkeit\n\nDie Einschränkung der Zustandslosigkeit hat der REST-Architektur ihren Namen verliehen. Für APIs soll gemäß dieser Vorgabe gelten, dass für die korrekte Beantwortung einer Anfrage die übermittelten Informationen der aktuellen Sitzung ausreichen.\n\nDas bedeutet: Es ist keine dauerhafte Verbindung zwischen Client und Server erforderlich und Client-Anfragen müssen auf der Server-Seite auch nicht zwischengespeichert werden. \n\nZustandslosigkeit führt zu höherer Daten- und Ausfallsicherheit. Gleichzeitig gilt aber auch: Benötigen Nutzer(innen) dieselben Informationen ein zweites Mal, müssen sämtliche Informationen der vorigen Sitzung erneut eingeben werden. \n\n### Mehrschichtiges Systemmodell\n\nFür jedes Unternehmen ist eine andere Server-Struktur optimal. Werden Informationen beispielsweise in verschiedenen Schichten gespeichert, gestaltet sich die Abfrage mehr oder weniger komplex. Das aber sollte für eine Anfrage unerheblich bleiben, solange die Daten korrekt übermittelt werden.  \n\nDie Einschränkung des mehrschichtigen Systemmodells ist somit das Gegenstück zur Zustandslosigkeit. Während letztere besagt, dass der Server vom Client nichts weiter benötigt als die Anfrageinformationen, verlangt das mehrschichtige Modell, dass dem Client nicht bekannt zu sein braucht, wie der Server die angeforderten Daten bereitstellt. \n\nDer Server kann also mit einer Vielzahl verschiedener Architekturen arbeiten, ohne dass die REST-API-Schnittstelle beeinflusst wird. \n\n### Einheitliche Schnittstelle\n\nDiese Einschränkung ist etwas komplexer und wiederum aus vier Unterpunkten aufgebaut. Für Roy Fielding war sie die womöglich wichtigste der gesamten REST-API-Architektur. \n\nDie einheitliche Schnittstelle fordert:\n\n- dass jeder Datensatz über eine einzige URI eindeutig gekennzeichnet ist,\n- dass Veränderungen oder auch Löschungen der Daten nur mittels der grundlegenden Netzwerkprotokollbefehle, wie GET, POST, PUT/PATCH und DELETE, vorgenommen werden können,\n- dass jede Nachricht, die versandt wird, mittels Metadaten sämtliche Informationen bereithält, die für die Bearbeitung der Daten erforderlich ist und\n- dass, sofern erforderlich, Hyperlinks (HATEOAS) bereitgestellt werden, um weitere benötigte Informationen einzuholen.\n\nDie einheitliche Schnittstelle sorgt für maximale Klarheit und eine einfache, standardisierte Client-Server-Kommunikation. \n\n### Cache-Fähigkeit\n\nZwar findet bei REST-APIs der Ressourcenaustausch zustandslos statt, zugleich aber sollten einmal angeforderte Daten aus einer Sitzung auf demselben Endgerät weiterverwendet werden können.\n\nIndem REST das Cachen dieser Informationen ermöglicht, sorgt es für eine höhere Effizienz und beschleunigt viele Prozesse bedeutend.\n\n### Code on Demand\n\nFür die meisten Anwendungen reicht die Bereitstellung der Daten in der Form von XML or JSON vollkommen aus. In bestimmten Fällen aber kann es von Vorteil sein, dem Client darüber hinaus –      oder stattdessen – eine Anwendung bereitzustellen. Denken Sie dabei an Java Applets oder JavaScript.\n\nCode on Demand stellt eine sinnvolle Erweiterung der REST-Architektur dar, aber sie ist als einzige der sechs Einschränkungen optional. \n\n## Wofür eignen sich REST-APIs?\n\nFlexibilität ist eines der Hauptmerkmale von REST-APIs. So sind sehr viele praktische Anwendungen denkbar:\n\n- Ganz grundsätzlich das Abrufen und Bereitstellen von Daten. Social-Media-Seiten wie Instagram oder Facebook nutzen REST-APIs beispielsweise um Updates zu posten.\n- Gerade weil sie zustandslos sind, eignen sich REST-APIs für Cloud-Services: Auch wenn die Verbindung abbricht, können die Daten weiter genutzt werden. \n- [Microservices](https://microservices.io/ \"Microservices\") gewinnen rasch an Beliebtheit und Bedeutung. Mit ihnen geht ein umfassender Perspektivenwechsel einher: Applikationen werden nicht mehr als riesige, in sich geschlossene Systeme gedacht, sondern als modular und aus kleineren, schlanken Elementen zusammengesetzt. REST-APIs bilden die ideale Schnittstelle zur nahtlosen Integration dieser verschiedenen Bausteine.\n\nIm Laufe der letzten 20 Jahre sind Alternativen zu REST-APIs verfügbar geworden. Dennoch hat sich keine davon auf breiter Basis durchsetzen können. Ganz offensichtlich ist REST auch aktuell der beste Ansatz zum Datenaustausch im Netz. \n\n## Was sind die Vorteile einer Rest-     API?\n\nIn den frühen Tagen des Internets war SOAP (Simple object access protocol) die dominante Form des Datenaustauschs. \n\nDass sich REST seitdem durchgesetzt hat und fast ein Vierteljahrhundert lang relevant geblieben ist, lässt sich recht einfach aus seinen inhärenten Vorteilen erklären:\n\n- SOAP vs REST: SOAP ist ein Protokoll, das Regeln und auch technische Realisierungen im Gegensatz zu REST sehr präzise vorschreibt. Daraus ergibt sich unmittelbar, dass APIs, die auf diesen Anforderungen aufbauen, weitaus komplexer als REST-APIs sind.\n- Die APIs, die gemäß der REST-Richtlinien programmiert wurden, basieren auf dem HTTP-Standard. Sie sind schnell und effizient und in nahezu jedem Kontext einsetzbar. Aus genau diesen Gründen eignen sich REST-APIs auch besonders gut für mobile Anwendungen.\n- Der Begriff der Skalierbarkeit ist bereits gefallen und er ist auch einer der maßgeblichen Argumente für die Verwendung von REST-APIs. Darunter ist zu verstehen, dass bei Erweiterungen der Server-Architektur nicht die darunter liegende Datenaustausch-Technologie verändert werden muss. \n- Einige Unternehmen setzen aus Sicherheitserwägungen immer noch auf SOAP. Allerdings sind REST-APIs keineswegs grundsätzlich unsicher. Entscheidend ist, einige grundlegende Best Practices anzuwenden – darunter die Verwendung von HTTPS sowie Autorisierung und Authentifizierung. \n\n## Gibt es eine REST-API von GitLab?\n\nAuch bei GitLab sind wir von den Vorzügen der REST-Architektur überzeugt. Aus diesem Grund stellen wir unseren Nutzer(inne)n eine [GitLab-REST-API](https://docs.gitlab.com/ee/api/rest/ \"GitLab-REST-API\") zur Verfügung. \n\nBei GitLab handelt es sich um den führenden Anbieter von DevSecOps-Lösungen. Anwender(innen) nutzen die Plattform, um sicher, fehlerfrei und kollaborativ an Entwicklungsprojekten zu arbeiten. \n\nDie GitLab-API kann sowohl genutzt werden, um öffentlich sichtbare, als auch nicht öffentliche Daten (nach erfolgter Authentifizierung und Autorisierung) abzurufen. Weil die API unmittelbar auf GitLab abgestimmt ist, erfolgt der Austausch sicher, schnell und effizient. \n\n## REST-API FAQs\n\n### Ist REST ein Standard?\n\nREST ist ein Satz aus sechs Einschränkungen, die den Datenaustausch in einer Client-Server-Beziehung regeln. Alle API-Schnittstellen, die diesen Vorgaben entsprechen, sind „RESTful“. \nEs ist somit nicht falsch, REST als einen Standard zu bezeichnen. Allerdings gilt dies weniger im Sinne eines Protokolls oder konkreter Anweisungen. REST gibt vielmehr Leitlinien und Anforderungen vor, deren Umsetzung zu gewünschten Ergebnissen führen, unabhängig davon, wie diese technisch realisiert werden.\n\nAus diesem Grund wird REST zumeist als ein „Architektur-Stil“ definiert. \n\n### Muss ich alle sechs REST-Einschränkungen befolgen?\n\nRoy Fielding hat hierzu persönlich im Laufe der Jahre mehrfach [Stellung bezogen](https://www.infoq.com/articles/roy-fielding-on-versioning/ \"Stellung bezogen\"). Seine Ansichten zu dieser Frage sind eindeutig: REST ist nicht in allen Fällen zwangsläufig die beste Option. Wenn man aber eine REST-konforme Architektur wünscht, müssen sämtliche Constraints ausnahmslos umgesetzt werden. \n\nEine API beispielsweise, die alle Einschränkungen umsetzt, bei der aber keine Daten gecached werden können, ist nicht RESTful. \n\nDie einzige Ausnahme ist Code on Demand. Diese Einschränkung ist optional und muss somit nicht umgesetzt werden, damit eine REST-API die Kriterien erfüllt. \n\n### Wie passen Cache-Fähigkeit und Zustandslosigkeit zusammen?\n\nZwischen den Einschränkungen der Cache-Fähigkeit und Zustandslosigkeit scheint ein Spannungsverhältnis zu bestehen. Wenn bei jeder Anfrage die Daten neu übermittelt werden müssen, widerspricht das Zwischenspeichern von Daten im Cache dann nicht dieser Forderung? \n\nIn Wahrheit fordert Zustandslosigkeit lediglich, dass der Server jede Anfrage so behandelt, als wäre sie die erste. Es besteht keine Zuordnung der Daten im Cache zu einer aktuellen Anfrage. \n\nDas Cachen der Daten dient lediglich einer höheren Effizienz und sorgt für Stabilität. \n\n### Was bedeutet der Begriff Idempotenz im Zusammenhang mit REST-APIs?\n\nWenn ein Client dieselbe Anfrage mehrfach nacheinander stellt, spricht man von Idempotenz. Das kann entweder passieren, weil die Verbindung instabil oder der Code fehlerhaft ist. \n\nEntscheidend ist, dass eine solche idempotente Anfrage nicht zu einem Fehler bei der Beantwortung der Anfrage führt. \n\nDie Einschränkung der Cache-Fähigkeit sorgt dafür, dass idempotente Anfragen als solche erkannt und fehlerfrei bearbeitet werden können. \n\n### Wie lassen sich Rest-APIs sichern?\n\nREST-APIs können sehr effektiv gesichert werden. \n\nÜbliche und sehr effiziente Methoden sind die Verwendung von HTTPS und API-Schlüsseln, die Durchführung von Authentifizierungen und Autorisierungen sowie die Durchführung einer Input-Validation und eines Audit-Loggings. \n\nAuch die Begrenzung der Anfragen in einem bestimmten Zeitfenster im Sinne eines Rate-Limiting empfiehlt sich.",[23,24],"DevOps","DevSecOps","yml",{},true,"/de-de/blog/what-is-a-rest-api-guide-and-functions",{"title":15,"description":16,"ogTitle":15,"ogDescription":16,"noIndex":12,"ogImage":19,"ogUrl":30,"ogSiteName":31,"ogType":32,"canonicalUrls":30},"https://about.gitlab.com/blog/what-is-a-rest-api-guide-and-functions","https://about.gitlab.com","article","de-de/blog/what-is-a-rest-api-guide-and-functions",[35,9],"devops","LwVtIuiFDQZCDtKy-K3IGrqZNiR3hhiNc1A6tlXfCg8",{"data":38},{"logo":39,"freeTrial":44,"sales":49,"login":54,"items":59,"search":368,"minimal":403,"duo":421,"pricingDeployment":431},{"config":40},{"href":41,"dataGaName":42,"dataGaLocation":43},"/de-de/","gitlab logo","header",{"text":45,"config":46},"Kostenlose Testversion anfordern",{"href":47,"dataGaName":48,"dataGaLocation":43},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":50,"config":51},"Vertrieb kontaktieren",{"href":52,"dataGaName":53,"dataGaLocation":43},"/de-de/sales/","sales",{"text":55,"config":56},"Anmelden",{"href":57,"dataGaName":58,"dataGaLocation":43},"https://gitlab.com/users/sign_in/","sign in",[60,87,183,188,289,349],{"text":61,"config":62,"cards":64},"Plattform",{"dataNavLevelOne":63},"platform",[65,71,79],{"title":61,"description":66,"link":67},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":68,"config":69},"Erkunde unsere Plattform",{"href":70,"dataGaName":63,"dataGaLocation":43},"/de-de/platform/",{"title":72,"description":73,"link":74},"GitLab Duo Agent Platform","Agentische KI für den gesamten Softwareentwicklungszyklus",{"text":75,"config":76},"Lerne GitLab Duo kennen",{"href":77,"dataGaName":78,"dataGaLocation":43},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":80,"description":81,"link":82},"Gründe, die für GitLab sprechen","Erfahre, warum Unternehmen auf GitLab setzen",{"text":83,"config":84},"Mehr erfahren",{"href":85,"dataGaName":86,"dataGaLocation":43},"/de-de/why-gitlab/","why gitlab",{"text":88,"left":27,"config":89,"link":91,"lists":95,"footer":165},"Produkt",{"dataNavLevelOne":90},"solutions",{"text":92,"config":93},"Alle Lösungen anzeigen",{"href":94,"dataGaName":90,"dataGaLocation":43},"/de-de/solutions/",[96,121,143],{"title":97,"description":98,"link":99,"items":104},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":100},{"icon":101,"href":102,"dataGaName":103,"dataGaLocation":43},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[105,109,112,117],{"text":106,"config":107},"CI/CD",{"href":108,"dataGaLocation":43,"dataGaName":106},"/de-de/solutions/continuous-integration/",{"text":72,"config":110},{"href":77,"dataGaLocation":43,"dataGaName":111},"gitlab duo agent platform - product menu",{"text":113,"config":114},"Quellcodeverwaltung",{"href":115,"dataGaLocation":43,"dataGaName":116},"/de-de/solutions/source-code-management/","Source Code Management",{"text":118,"config":119},"Automatisierte Softwarebereitstellung",{"href":102,"dataGaLocation":43,"dataGaName":120},"Automated software delivery",{"title":122,"description":123,"link":124,"items":129},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":125},{"href":126,"dataGaName":127,"dataGaLocation":43,"icon":128},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[130,134,139],{"text":131,"config":132},"Application Security Testing",{"href":126,"dataGaName":133,"dataGaLocation":43},"Application security testing",{"text":135,"config":136},"Schutz der Software-Lieferkette",{"href":137,"dataGaLocation":43,"dataGaName":138},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":140,"config":141},"Software Compliance",{"href":142,"dataGaName":140,"dataGaLocation":43},"/de-de/solutions/software-compliance/",{"title":144,"link":145,"items":150},"Bewertung",{"config":146},{"icon":147,"href":148,"dataGaName":149,"dataGaLocation":43},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[151,155,160],{"text":152,"config":153},"Sichtbarkeit und Bewertung",{"href":148,"dataGaLocation":43,"dataGaName":154},"Visibility and Measurement",{"text":156,"config":157},"Wertstrommanagement",{"href":158,"dataGaLocation":43,"dataGaName":159},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":161,"config":162},"Analysen und Einblicke",{"href":163,"dataGaLocation":43,"dataGaName":164},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":166,"items":167},"GitLab für",[168,173,178],{"text":169,"config":170},"Enterprise",{"href":171,"dataGaLocation":43,"dataGaName":172},"/de-de/enterprise/","enterprise",{"text":174,"config":175},"Kleinunternehmen",{"href":176,"dataGaLocation":43,"dataGaName":177},"/de-de/small-business/","small business",{"text":179,"config":180},"den öffentlichen Sektor",{"href":181,"dataGaLocation":43,"dataGaName":182},"/de-de/solutions/public-sector/","public sector",{"text":184,"config":185},"Preise",{"href":186,"dataGaName":187,"dataGaLocation":43,"dataNavLevelOne":187},"/de-de/pricing/","pricing",{"text":189,"config":190,"link":192,"lists":196,"feature":276},"Ressourcen",{"dataNavLevelOne":191},"resources",{"text":193,"config":194},"Alle Ressourcen anzeigen",{"href":195,"dataGaName":191,"dataGaLocation":43},"/de-de/resources/",[197,230,248],{"title":198,"items":199},"Erste Schritte",[200,205,210,215,220,225],{"text":201,"config":202},"Installieren",{"href":203,"dataGaName":204,"dataGaLocation":43},"/de-de/install/","install",{"text":206,"config":207},"Kurzanleitungen",{"href":208,"dataGaName":209,"dataGaLocation":43},"/de-de/get-started/","quick setup checklists",{"text":211,"config":212},"Lernen",{"href":213,"dataGaLocation":43,"dataGaName":214},"https://university.gitlab.com/","learn",{"text":216,"config":217},"Produktdokumentation",{"href":218,"dataGaName":219,"dataGaLocation":43},"https://docs.gitlab.com/","product documentation",{"text":221,"config":222},"Best-Practice-Videos",{"href":223,"dataGaName":224,"dataGaLocation":43},"/de-de/getting-started-videos/","best practice videos",{"text":226,"config":227},"Integrationen",{"href":228,"dataGaName":229,"dataGaLocation":43},"/de-de/integrations/","integrations",{"title":231,"items":232},"Entdecken",[233,238,243],{"text":234,"config":235},"Kundenerfolge",{"href":236,"dataGaName":237,"dataGaLocation":43},"/de-de/customers/","customer success stories",{"text":239,"config":240},"Blog",{"href":241,"dataGaName":242,"dataGaLocation":43},"/de-de/blog/","blog",{"text":244,"config":245},"Remote",{"href":246,"dataGaName":247,"dataGaLocation":43},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":249,"items":250},"Vernetzen",[251,256,261,266,271],{"text":252,"config":253},"GitLab-Services",{"href":254,"dataGaName":255,"dataGaLocation":43},"/de-de/services/","services",{"text":257,"config":258},"Community",{"href":259,"dataGaName":260,"dataGaLocation":43},"/community/","community",{"text":262,"config":263},"Forum",{"href":264,"dataGaName":265,"dataGaLocation":43},"https://forum.gitlab.com/","forum",{"text":267,"config":268},"Veranstaltungen",{"href":269,"dataGaName":270,"dataGaLocation":43},"/events/","events",{"text":272,"config":273},"Partner",{"href":274,"dataGaName":275,"dataGaLocation":43},"/de-de/partners/","partners",{"backgroundColor":277,"textColor":278,"text":279,"image":280,"link":284},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":281,"config":282},"the source promo card",{"src":283},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":285,"config":286},"Lies die News",{"href":287,"dataGaName":288,"dataGaLocation":43},"/de-de/the-source/","the source",{"text":290,"config":291,"lists":293},"Unternehmen",{"dataNavLevelOne":292},"company",[294],{"items":295},[296,301,307,309,314,319,324,329,334,339,344],{"text":297,"config":298},"Über",{"href":299,"dataGaName":300,"dataGaLocation":43},"/de-de/company/","about",{"text":302,"config":303,"footerGa":306},"Karriere",{"href":304,"dataGaName":305,"dataGaLocation":43},"/jobs/","jobs",{"dataGaName":305},{"text":267,"config":308},{"href":269,"dataGaName":270,"dataGaLocation":43},{"text":310,"config":311},"Geschäftsführung",{"href":312,"dataGaName":313,"dataGaLocation":43},"/company/team/e-group/","leadership",{"text":315,"config":316},"Team",{"href":317,"dataGaName":318,"dataGaLocation":43},"/company/team/","team",{"text":320,"config":321},"Handbuch",{"href":322,"dataGaName":323,"dataGaLocation":43},"https://handbook.gitlab.com/","handbook",{"text":325,"config":326},"Investor Relations",{"href":327,"dataGaName":328,"dataGaLocation":43},"https://ir.gitlab.com/","investor relations",{"text":330,"config":331},"Trust Center",{"href":332,"dataGaName":333,"dataGaLocation":43},"/de-de/security/","trust center",{"text":335,"config":336},"AI Transparency Center",{"href":337,"dataGaName":338,"dataGaLocation":43},"/de-de/ai-transparency-center/","ai transparency center",{"text":340,"config":341},"Newsletter",{"href":342,"dataGaName":343,"dataGaLocation":43},"/company/contact/#contact-forms","newsletter",{"text":345,"config":346},"Presse",{"href":347,"dataGaName":348,"dataGaLocation":43},"/press/","press",{"text":350,"config":351,"lists":352},"Kontakt",{"dataNavLevelOne":292},[353],{"items":354},[355,358,363],{"text":50,"config":356},{"href":52,"dataGaName":357,"dataGaLocation":43},"talk to sales",{"text":359,"config":360},"Support-Portal",{"href":361,"dataGaName":362,"dataGaLocation":43},"https://support.gitlab.com","support portal",{"text":364,"config":365},"Kundenportal",{"href":366,"dataGaName":367,"dataGaLocation":43},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":369,"login":370,"suggestions":377},"Schließen",{"text":371,"link":372},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":373,"config":374},"gitlab.com",{"href":57,"dataGaName":375,"dataGaLocation":376},"search login","search",{"text":378,"default":379},"Vorschläge",[380,382,387,389,394,399],{"text":72,"config":381},{"href":77,"dataGaName":72,"dataGaLocation":376},{"text":383,"config":384},"Code Suggestions (KI)",{"href":385,"dataGaName":386,"dataGaLocation":376},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":106,"config":388},{"href":108,"dataGaName":106,"dataGaLocation":376},{"text":390,"config":391},"GitLab auf AWS",{"href":392,"dataGaName":393,"dataGaLocation":376},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":395,"config":396},"GitLab auf Google Cloud",{"href":397,"dataGaName":398,"dataGaLocation":376},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":400,"config":401},"Warum GitLab?",{"href":85,"dataGaName":402,"dataGaLocation":376},"Why GitLab?",{"freeTrial":404,"mobileIcon":409,"desktopIcon":414,"secondaryButton":417},{"text":405,"config":406},"Kostenlos testen",{"href":407,"dataGaName":48,"dataGaLocation":408},"https://gitlab.com/-/trials/new/","nav",{"altText":410,"config":411},"GitLab-Symbol",{"src":412,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":410,"config":415},{"src":416,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":198,"config":418},{"href":419,"dataGaName":420,"dataGaLocation":408},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/compare/gitlab-vs-github/","get started",{"freeTrial":422,"mobileIcon":427,"desktopIcon":429},{"text":423,"config":424},"Erfahre mehr über GitLab Duo",{"href":425,"dataGaName":426,"dataGaLocation":408},"/de-de/gitlab-duo/","gitlab duo",{"altText":410,"config":428},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":430},{"src":416,"dataGaName":413,"dataGaLocation":408},{"freeTrial":432,"mobileIcon":437,"desktopIcon":439},{"text":433,"config":434},"Zurück zur Preisübersicht",{"href":186,"dataGaName":435,"dataGaLocation":408,"icon":436},"back to pricing","GoBack",{"altText":410,"config":438},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":440},{"src":416,"dataGaName":413,"dataGaLocation":408},{"title":442,"button":443,"config":448},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":444,"config":445},"GitLab Transcend jetzt ansehen",{"href":446,"dataGaName":447,"dataGaLocation":43},"/de-de/events/transcend/virtual/","transcend event",{"layout":449,"icon":450},"release","AiStar",{"data":452},{"text":453,"source":454,"edit":460,"contribute":465,"config":470,"items":475,"minimal":648},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":455,"config":456},"Quelltext der Seite anzeigen",{"href":457,"dataGaName":458,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":461,"config":462},"Diese Seite bearbeiten",{"href":463,"dataGaName":464,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":466,"config":467},"Beteilige dich",{"href":468,"dataGaName":469,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":471,"facebook":472,"youtube":473,"linkedin":474},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[476,499,554,581,615],{"title":61,"links":477,"subMenu":482},[478],{"text":479,"config":480},"DevSecOps-Plattform",{"href":70,"dataGaName":481,"dataGaLocation":459},"devsecops platform",[483],{"title":184,"links":484},[485,489,494],{"text":486,"config":487},"Tarife anzeigen",{"href":186,"dataGaName":488,"dataGaLocation":459},"view plans",{"text":490,"config":491},"Vorteile von Premium",{"href":492,"dataGaName":493,"dataGaLocation":459},"/de-de/pricing/premium/","why premium",{"text":495,"config":496},"Vorteile von Ultimate",{"href":497,"dataGaName":498,"dataGaLocation":459},"/de-de/pricing/ultimate/","why ultimate",{"title":500,"links":501},"Lösungen",[502,507,510,512,517,522,526,529,532,537,539,541,544,549],{"text":503,"config":504},"Digitale Transformation",{"href":505,"dataGaName":506,"dataGaLocation":459},"/de-de/topics/digital-transformation/","digital transformation",{"text":508,"config":509},"Sicherheit und Compliance",{"href":126,"dataGaName":133,"dataGaLocation":459},{"text":118,"config":511},{"href":102,"dataGaName":103,"dataGaLocation":459},{"text":513,"config":514},"Agile Entwicklung",{"href":515,"dataGaName":516,"dataGaLocation":459},"/de-de/solutions/agile-delivery/","agile delivery",{"text":518,"config":519},"Cloud-Transformation",{"href":520,"dataGaName":521,"dataGaLocation":459},"/de-de/topics/cloud-native/","cloud transformation",{"text":523,"config":524},"SCM",{"href":115,"dataGaName":525,"dataGaLocation":459},"source code management",{"text":106,"config":527},{"href":108,"dataGaName":528,"dataGaLocation":459},"continuous integration & delivery",{"text":156,"config":530},{"href":158,"dataGaName":531,"dataGaLocation":459},"value stream management",{"text":533,"config":534},"GitOps",{"href":535,"dataGaName":536,"dataGaLocation":459},"/de-de/solutions/gitops/","gitops",{"text":169,"config":538},{"href":171,"dataGaName":172,"dataGaLocation":459},{"text":174,"config":540},{"href":176,"dataGaName":177,"dataGaLocation":459},{"text":542,"config":543},"Öffentlicher Sektor",{"href":181,"dataGaName":182,"dataGaLocation":459},{"text":545,"config":546},"Bildungswesen",{"href":547,"dataGaName":548,"dataGaLocation":459},"/de-de/solutions/education/","education",{"text":550,"config":551},"Finanzdienstleistungen",{"href":552,"dataGaName":553,"dataGaLocation":459},"/de-de/solutions/finance/","financial services",{"title":189,"links":555},[556,558,560,562,565,567,569,571,573,575,577,579],{"text":201,"config":557},{"href":203,"dataGaName":204,"dataGaLocation":459},{"text":206,"config":559},{"href":208,"dataGaName":209,"dataGaLocation":459},{"text":211,"config":561},{"href":213,"dataGaName":214,"dataGaLocation":459},{"text":216,"config":563},{"href":218,"dataGaName":564,"dataGaLocation":459},"docs",{"text":239,"config":566},{"href":241,"dataGaName":242,"dataGaLocation":459},{"text":234,"config":568},{"href":236,"dataGaName":237,"dataGaLocation":459},{"text":244,"config":570},{"href":246,"dataGaName":247,"dataGaLocation":459},{"text":252,"config":572},{"href":254,"dataGaName":255,"dataGaLocation":459},{"text":257,"config":574},{"href":259,"dataGaName":260,"dataGaLocation":459},{"text":262,"config":576},{"href":264,"dataGaName":265,"dataGaLocation":459},{"text":267,"config":578},{"href":269,"dataGaName":270,"dataGaLocation":459},{"text":272,"config":580},{"href":274,"dataGaName":275,"dataGaLocation":459},{"title":290,"links":582},[583,585,587,589,591,593,595,599,604,606,608,610],{"text":297,"config":584},{"href":299,"dataGaName":292,"dataGaLocation":459},{"text":302,"config":586},{"href":304,"dataGaName":305,"dataGaLocation":459},{"text":310,"config":588},{"href":312,"dataGaName":313,"dataGaLocation":459},{"text":315,"config":590},{"href":317,"dataGaName":318,"dataGaLocation":459},{"text":320,"config":592},{"href":322,"dataGaName":323,"dataGaLocation":459},{"text":325,"config":594},{"href":327,"dataGaName":328,"dataGaLocation":459},{"text":596,"config":597},"Sustainability",{"href":598,"dataGaName":596,"dataGaLocation":459},"/sustainability/",{"text":600,"config":601},"Vielfalt, Inklusion und Zugehörigkeit",{"href":602,"dataGaName":603,"dataGaLocation":459},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":330,"config":605},{"href":332,"dataGaName":333,"dataGaLocation":459},{"text":340,"config":607},{"href":342,"dataGaName":343,"dataGaLocation":459},{"text":345,"config":609},{"href":347,"dataGaName":348,"dataGaLocation":459},{"text":611,"config":612},"Transparenzerklärung zu moderner Sklaverei",{"href":613,"dataGaName":614,"dataGaLocation":459},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":616,"links":617},"Nimm Kontakt auf",[618,621,626,628,633,638,643],{"text":619,"config":620},"Sprich mit einem Experten/einer Expertin",{"href":52,"dataGaName":53,"dataGaLocation":459},{"text":622,"config":623},"Support",{"href":624,"dataGaName":625,"dataGaLocation":459},"/support/","get help",{"text":364,"config":627},{"href":366,"dataGaName":367,"dataGaLocation":459},{"text":629,"config":630},"Status",{"href":631,"dataGaName":632,"dataGaLocation":459},"https://status.gitlab.com/","status",{"text":634,"config":635},"Nutzungsbedingungen",{"href":636,"dataGaName":637,"dataGaLocation":459},"/terms/","terms of use",{"text":639,"config":640},"Datenschutzerklärung",{"href":641,"dataGaName":642,"dataGaLocation":459},"/de-de/privacy/","privacy statement",{"text":644,"config":645},"Cookie-Einstellungen",{"dataGaName":646,"dataGaLocation":459,"id":647,"isOneTrustButton":27},"cookie preferences","ot-sdk-btn",{"items":649},[650,652,654],{"text":634,"config":651},{"href":636,"dataGaName":637,"dataGaLocation":459},{"text":639,"config":653},{"href":641,"dataGaName":642,"dataGaLocation":459},{"text":644,"config":655},{"dataGaName":646,"dataGaLocation":459,"id":647,"isOneTrustButton":27},[657],{"id":658,"title":659,"body":8,"config":660,"content":662,"description":8,"extension":25,"meta":666,"navigation":27,"path":667,"seo":668,"stem":669,"__hash__":670},"blogAuthors/en-us/blog/authors/gitlab-germany-team.yml","Gitlab Germany Team",{"template":661},"BlogAuthor",{"name":18,"config":663},{"headshot":664,"ctfId":665},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659488/Blog/Author%20Headshots/gitlab-logo-extra-whitespace.png","6tNquF8jQeRRRi8k3ZXpvS",{},"/en-us/blog/authors/gitlab-germany-team",{},"en-us/blog/authors/gitlab-germany-team","vGs9BT_ji6dORS29vl80DKX6mSputlQV2W7-4vW2hL8",[672,687,698],{"content":673,"config":685},{"description":674,"authors":675,"heroImage":677,"date":678,"title":679,"body":680,"category":9,"tags":681},"Komm am 10. Februar 2026 auf die GitLab Transcend in München oder sei online live dabei. Finde heraus, wie du Produktivitätsgewinne mit Qualität, Zuverlässigkeit und Sicherheit in Einklang bringst.",[676],"Manav Khurana","https://res.cloudinary.com/about-gitlab-com/image/upload/v1767982271/e9ogyosmuummq7j65zqg.png","2026-01-12","KI verändert DevSecOps: Triff GitLab und erfahre, was als Nächstes kommt","**KI verspricht einen Quantensprung bei der Innovationsgeschwindigkeit, doch die meisten Software-Teams stoßen an ihre Grenzen.**\n\nLaut unserem brandneuen [Global DevSecOps Report mit Zahlen für Deutschland](https://learn.gitlab.com/de-developer-survey/report-de-de-de-devsecops-report-practitioner) macht KI-generierter Code mittlerweile 32 Prozent aller Entwicklungsarbeit aus. Dennoch berichten 75 Prozent der deutschen DevSecOps-Expert(inn)en, dass KI das Compliance-Management erschwert, und 78 Prozent sagen, dass agentische KI beispiellose Sicherheitsherausforderungen schaffen wird.\n\nDas ist das **KI-Paradoxon:** KI beschleunigt das Programmieren, aber die Software-Auslieferung verlangsamt sich, weil Teams damit kämpfen, den Code zu testen, abzusichern und zu deployen.\n\n> **[Lade dir unseren DevSecOps Report für Deutschland *kostenlos* herunter!](https://learn.gitlab.com/de-developer-survey/report-de-de-de-devsecops-report-practitioner)**\n\n## Produktivitätsgewinne treffen auf Workflow-Engpässe\n\nDas Problem ist nicht die KI selbst. Es liegt daran, wie Software heute entwickelt wird. Der traditionelle DevSecOps-Lebenszyklus enthält Hunderte kleiner Aufgaben, die Entwickler(innen) manuell bewältigen müssen: Tickets aktualisieren, Tests ausführen, Reviews anfordern, auf Freigaben warten, Merge-Konflikte beheben, Sicherheitsprobleme angehen. Diese Aufgaben kosten laut unserer Forschung jedes Teammitglied durchschnittlich sieben Stunden pro Woche.\n\nEntwicklungsteams produzieren Code schneller als je zuvor, aber dieser Code kriecht immer noch durch fragmentierte Toolchains, manuelle Übergaben und unverbundene Prozesse. Tatsächlich verwenden nahezu 60 Prozent der deutschen DevSecOps-Teams mehr als fünf Tools für die Softwareentwicklung insgesamt, und 45 Prozent nutzen mehr als fünf KI-Tools. Diese Fragmentierung schafft Kollaborationsbarrieren – 97 Prozent der deutschen DevSecOps-Fachleute erleben Faktoren, die die Zusammenarbeit im Software-Entwicklungszyklus einschränken.\n\nDie Antwort sind nicht noch mehr Tools. Es ist intelligente Orchestrierung, die Software-Teams und ihre KI-Agenten über Projekte und Release-Zyklen hinweg zusammenbringt – mit eingebauter Sicherheit, Governance und Compliance auf Enterprise-Niveau.\n\n## Auf der Suche nach tieferen Mensch-KI-Partnerschaften\n\nDevSecOps-Profis wollen nicht, dass KI übernimmt – sie wollen verlässliche Partnerschaften. Die große Mehrheit (81 Prozent) sagt, dass die Nutzung agentischer KI ihre Arbeitszufriedenheit erhöhen würde, und 38 Prozent stellen sich eine ideale Zukunft mit einer 50/50-Aufteilung zwischen menschlichen und KI-Beiträgen vor. Sie sind bereit, KI rund ein Drittel ihrer täglichen Aufgaben ohne menschliche Überprüfung anzuvertrauen, besonders bei Dokumentation, Test-Erstellung und Code-Reviews.\n\nWas wir deutlich von deutschen DevSecOps-Expert(inn)en gehört haben, ist, dass KI sie nicht ersetzen wird; vielmehr wird sie ihre Rollen grundlegend verändern. 80 Prozent der DevSecOps-Fachleute glauben, dass KI ihre Arbeit innerhalb von fünf Jahren erheblich verändern wird, und bemerkenswert ist, dass drei Viertel denken, dies wird mehr Engineering-Jobs schaffen, nicht weniger. Da das Programmieren mit KI einfacher wird, werden Ingenieur(inn)en, die Systeme entwerfen, Qualität sicherstellen und geschäftlichen Kontext anwenden können, sehr gefragt sein.\n\nEntscheidend ist, dass 84 Prozent zustimmen, dass es wesentliche menschliche Qualitäten gibt, die KI niemals vollständig ersetzen wird, einschließlich Kreativität, Innovation, Zusammenarbeit und strategische Vision.\n\nWie können Organisationen also die Lücke zwischen dem Versprechen der KI und der Realität fragmentierter Workflows überbrücken?\n\n## Komm zur GitLab Transcend: Erfahre, wie du mit agentischer KI echten Wert schaffst\n\nAm 10. Februar 2026 veranstaltet GitLab Transcend, wo wir zeigen werden, wie intelligente Orchestrierung die KI-gestützte Softwareentwicklung transformiert. Du erhältst einen ersten Blick auf GitLabs kommende Produkt-Roadmap und erfährst, wie Teams reale Herausforderungen lösen, indem sie Entwicklungs-Workflows mit KI modernisieren.\n\nOrganisationen, die in dieser neuen Ära gewinnen, balancieren KI-Einführung mit Sicherheit, Compliance und Plattform-Konsolidierung. KI bietet echte Produktivitätsgewinne, wenn sie durchdacht implementiert wird – nicht indem sie menschliche Entwickler(innen) ersetzt, sondern indem sie DevSecOps-Profis befreit, sich auf strategisches Denken und kreative Innovation zu konzentrieren.\n\n> ## **Registriere dich jetzt für unser Event in München oder die Online-Konferenz**\n>\n> [Hier geht's zur digitalen Transcend](https://about.gitlab.com/events/transcend/virtual/) und [hier zum Live-Event in München](https://about.gitlab.com/events/transcend/munich/). Sichere dir deinen Platz und erfahre, wie intelligente Orchestrierung deinen Software-Teams helfen kann, im Flow zu bleiben.\n> *Die Transcend in München wird auf Englisch stattfinden.*",[682,683,684],"AI/ML","DevOps platform","security",{"featured":27,"template":13,"slug":686},"ai-is-reshaping-devsecops-attend-gitlab-transcend-to-see-whats-next",{"content":688,"config":696},{"title":689,"category":9,"tags":690,"authors":691,"heroImage":692,"body":693,"description":694,"date":695},"Shift Left Security: DevSecOps richtig umsetzen – ein Praxisleitfaden",[683],[18],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1765222301/czfqu7ajwcwyyn4beg6k.jpg","Traditionelle Sicherheitsmodelle geraten in modernen [DevOps-Umgebungen](https://about.gitlab.com/de-de/topics/devops/) schnell an ihre Grenzen. Sicherheitsprüfungen, die erst spät im Entwicklungsprozess erfolgen, verursachen hohe Kosten, lange Reaktionszeiten und unterbrechen agile Workflows. Der Shift Left Security-Ansatz begegnet diesen Herausforderungen, indem er Sicherheitsmaßnahmen frühzeitig integriert. Statt reaktiv auf Sicherheitslücken zu reagieren, werden Risiken bereits in der Entwicklungsphase erkannt und adressiert. Wir zeigen dir, wie dieser Ansatz funktioniert, welche Vorteile er bietet und wie du Shift Left Security umsetzt.\n\n## **Was ist Shift Left Security?**\n\nShift Left Security bezeichnet einen Ansatz in der Softwareentwicklung, bei dem Sicherheitsmaßnahmen möglichst früh im Entwicklungsprozess integriert werden.\n\nTraditionell wurden Sicherheitstests erst am Ende des Softwareentwicklungszyklus (SDLC) durchgeführt, zum Beispiel in der Test- oder Produktionsphase. Dieses Vorgehen führt oft zu höheren Kosten und längeren Entwicklungszeiten, wenn kritische Sicherheitslücken spät entdeckt werden.\n\nMit dem Shift Left Ansatz wird das Thema Sicherheit nun auf der Zeitachse der Anwendungsentwicklung nach links verschoben, sodass anfälliger Code früh entdeckt werden kann. Ziel ist es, Schwachstellen schon in den frühen Phasen wie Planung, Design oder Codierung zu erkennen und zu beheben, statt sie erst im späteren Verlauf oder nach dem Deployment zu adressieren.\n\n![Infografik So funktioniert Shift Left](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765222295/lx0qqnnyse2ginovcnxb.jpg \"Schaubild: Shift Left Security, Sicherheitsmaßnahmen werden möglichst früh im Entwicklungsprozess integriert.\")\n\n## **Der Shift Left Ansatz**\n\nShift Left Security ist eine strategische Herangehensweise, bei der Sicherheit möglichst früh in den Entwicklungsprozess integriert wird – nicht durch ein einzelnes Tool, sondern durch eine Kombination verschiedener Maßnahmen.\n\nTypischerweise werden dafür Sicherheitstools entlang des Entwicklungszyklus eingesetzt, darunter:\n\n* **SCA (Software Composition Analysis)**: SCA erkennt Schwachstellen und Lizenzrisiken in Open-Source-Komponenten, indem es Paketverwaltung, Manifestdateien, Binärdateien und Container-Images analysiert. Die Ergebnisse werden in einer Software-Stückliste (sog.[ Software Bill of Materials](https://about.gitlab.com/de-de/blog/the-ultimate-guide-to-sboms/)) zusammengeführt und mit Schwachstellen- und Lizenzdatenbanken abgeglichen. So lassen sich Sicherheits- und Compliance-Probleme systematisch aufspüren und schnell adressieren.\n* **SAST (Static Application Security Testing)**: SAST ist ein White-Box-Verfahren, das den Quellcode analysiert, ohne die Anwendung auszuführen. Es spiegelt die Sichtweise von Entwickler(innen) wider und erkennt Schwachstellen früh im Softwareentwicklungszyklus, z. B. fehlende Eingabevalidierung oder unsichere Codemuster. Dadurch ist es besonders kosteneffizient. Laufzeit- oder umgebungsbezogene Probleme kann SAST allerdings nicht erfassen.\n* **DAST (Dynamic Application Security Testing)**: DAST ist ein Black-Box-Verfahren, das laufende Web-Anwendungen testet und sich an der Methodik potenzieller Angreifer(innen) orientiert. Es erkennt Schwachstellen wie XSS, fehlerhafte Authentifizierung oder Konfigurationsfehler zur Laufzeit – ohne Kenntnis des zugrundeliegenden Codes. DAST wird typischerweise in späten Phasen der Entwicklung oder in Testumgebungen eingesetzt und eignet sich ausschließlich für Web-Anwendungen und -Services.\n* **Secret Scanning:** Shift Left Security umfasst auch das Scannen von Container-Images und serverlosen Funktionen, da moderne Anwendungen zunehmend in Containern ausgeführt oder über serverlose Architekturen bereitgestellt werden. Beim Scannen eines [Container-Images](https://about.gitlab.com/de-de/topics/devsecops/beginners-guide-to-container-security/) wird der Inhalt auf Sicherheitslücken, Schwachstellen im Build-Prozess und fehlerhafte Konfigurationen geprüft. Ziel ist es, Probleme zu erkennen, bevor das Image in der Produktion verwendet wird. Das Scannen serverloser Funktionen erfordert spezielle Überwachungslösungen, die cloud-native Umgebungen abdecken und auch ohne klassische Serverinfrastruktur funktionieren.\n\nDiese Tools können einzeln oder kombiniert verwendet werden. Effektiver ist jedoch eine [automatisierte Sicherheitsplattform](https://about.gitlab.com/de-de/blog/why-are-organizations-moving-to-a-unified-devsecops-platform/), die Risiken in allen Phasen des Entwicklungszyklus erkennt – von der Codierung bis zur Bereitstellung. So können DevOps-Teams Schwachstellen frühzeitig und systematisch beheben.\n\n**Lesetipp:** [SAST vs. DAST - Die Unterschiede erklärt](https://about.gitlab.com/de-de/topics/devsecops/sast-vs-dast/)\n\n## **Vorteile der Shift Left Security**\n\nDie Linksverschiebung sicherheitsrelevanter Maßnahmen führt zu einer Reihe von Vorteilen für Unternehmen und Entwickler(innen).\n\n* **Frühzeitiges Erkennen von Sicherheitsrisiken:** Durch Sicherheitsanalysen direkt im Code oder bei der Integration von Abhängigkeiten lassen sich Schwachstellen erkennen, bevor sie in produktive Systeme gelangen. Dies verschafft Entwickler(innen) mehr Zeit für die Reaktion und reduziert die potenzielle Bedrohung (beispielsweise durch Exploits oder Datenlecks) erheblich.\n* **Geringere Kosten für Fehlerbehebung:** Je später ein Sicherheitsfehler entdeckt wird, desto teurer ist seine Behebung. Wird eine Schwachstelle bereits vor dem Build entdeckt, reicht oft eine einfache Codeänderung – ohne zusätzlichen Aufwand für Tests oder Deployments. Wird das Problem erst in der Produktion bemerkt, ist der Aufwand deutlich höher und der gesamte Prozess kann Wochen dauern. Frühes Eingreifen spart Zeit, senkt die Kosten und ermöglicht es Entwickler(innen), sich stärker auf neue Funktionen statt auf Notfallpatches zu konzentrieren.\n* **Schnellere Entwicklungszyklen:** Sicherheitsprobleme lassen sich schneller beheben, solange sie nur im Quellcode bestehen. Wird ein Problem erst kurz vor dem Release oder in der Produktion entdeckt, verlängert sich der Behebungsprozess deutlich – mit der Gefahr, gesetzte Fristen zu verpassen und die Time-to-Market zu verlangsamen.\n* **Bessere Codequalität:** Sicherheitsüberprüfungen fördern eine saubere Code-Architektur, konsistente Implementierung und verständlichen Code. So entstehen robuste und wartbare Anwendungen.\n* **Bessere Zusammenarbeit:** Shift Left Security fördert die Zusammenarbeitzwischen Entwickler(innen) und Security-Teams. Wird ein Sicherheitsproblem früh im Quellcode erkannt, können beide Seiten gemeinsam daran arbeiten, ohne Schuldzuweisungen oder Zeitdruck. Das verbessert die Kommunikation und stärkt das gegenseitige Verständnis.\n* **Reduziertes Risiko im Live-Betrieb:** Wird eine Schwachstelle erst im laufenden Betrieb entdeckt, sind schnelle und oft drastische Maßnahmen nötig – etwa das Abschalten der App. Wird die Schwachstelle hingegen bereits während der Entwicklung identifiziert, lässt sie sich mit geringem Aufwand und ohne größere Auswirkungen auf Nutzer(innen) beheben.\n\n***[Wie Dunelm, der britische Marktführer für Haushaltswaren, die Sicherheit \"nach links\" geschoben hat, steht in dieser ausführlichen Case Study.](https://about.gitlab.com/de-de/customers/dunelm/)***\n\n## **Best Practices für deinen Shift Left Security Ansatz**\n\nShift Left Security erfordert die frühzeitige und umfassende Integration von Sicherheitsmaßnahmen in den Entwicklungsprozess – idealerweise ab dem ersten Moment, in dem Entwickler(innen) mit dem Programmieren beginnen. Die Sicherheitsprüfung soll nicht nachgelagert, sondern integraler Bestandteil der täglichen Entwicklungsarbeit sein. Damit das gelingt, solltest du auf Best Practices zurückgreifen.\n\n### **\\#1 Integration von Sicherheitsmaßnahmen in die CI/CD-Pipeline**\n\nSicherheits-Scans sind ein zentrales Element des Shift-Left-Ansatzes. Ihre volle Wirkung entfalten sie aber nur, wenn die Ergebnisse unmittelbar in die[ DevOps-Toolkette](https://about.gitlab.com/de-de/topics/ci-cd/shift-left-devops/) eingebunden sind. Reports sollten direkt im CI/CD-Pipeline-Bericht angezeigt werden, sodass Entwickler(innen) sie ohne Umwege nutzen können. Zusätzlich sollte die Erstellung einer Software Bill of Materials (SBOM) automatisiert werden, um alle verwendeten Abhängigkeiten, Container-Images und serverlosen Funktionen transparent zu erfassen und systematisch auf bekannte Schwachstellen zu prüfen.\n\n### **\\#2 Anwendung von Security-Tools in der Entwicklungsumgebung**\n\nSicherheitsfunktionen sollten direkt in die Entwicklungsumgebung eingebunden werden, damit Schwachstellen bereits vor Übertragung in den Main Branch erkannt werden. Durch die Integration in die vertrauten Toolsets der Entwickler(innen) wird eine kontinuierliche Zusammenarbeit mit dem Security-Team ermöglicht und der Aufwand für nachträgliche Korrekturen deutlich reduziert.\n\n### **\\#3 Schulung von Entwickler(innen)**\n\nDamit Entwickler(innen) die Anwendungssicherheit bereits frühzeitig im Prozess berücksichtigen, ist eine intensive Schulung notwendig. Entwicklerteams müssen verstehen, warum sie Sicherheitsprüfungen frühzeitig durchführen – und welchen Beitrag das zur Gesamtqualität und Stabilität der Anwendung leistet. Dazu eignen sich praxisnahe und rollenbezogene Schulungsformate wie z. B. Code Labs, Code Guidelines oder Hands-on-Training.\n\n### **\\#4 Integration von Security Reviews in Code Reviews und Pull Requests**\n\nSicherheit sollte auch Teil von [Code Reviews](https://about.gitlab.com/de-de/topics/version-control/what-is-code-review/) sein. Teams können z. B. Checklisten mit sicherheitsrelevanten Aspekten verwenden. Pair Programming bietet zusätzlich die Möglichkeit, Sicherheit direkt beim Schreiben des Codes mitzudenken – vor allem in frühen Projektphasen.\n\n## **HackerOne + GitLab: Setze Shift Left Security einfach und kostengünstig um**\n\nEine der größten Herausforderungen für die Umsetzung der Shift Left Sicherheit für Entwicklerteams ist eine aufgeblähte Toolchain. Der Wechsel zwischen Tools und unklare Rollenverteilungen können die frühzeitige Integration von Sicherheitsüberprüfungen behindern.\n\nGitLab bietet mit HackerOne eine integrierte Lösung, die Security-Teams und Entwickler(innen) effektiv verbindet. Sicherheitslücken, die über HackerOne gemeldet und validiert werden, werden automatisch in GitLab als Tickets angelegt. Diese enthalten unter anderem:\n\n* Synchronisation von Kommentaren\n* Statusänderungen\n* Zuständigkeiten\n* Belohnungen\n* Fälligkeitsdaten\n\nDie Kommunikation erfolgt dabei bidirektional zwischen beiden Plattformen. Die Integration ermöglicht es somit Entwickler(innen), im gewohnten Workflow zu bleiben und Sicherheitslücken direkt zu bearbeiten.\n\n### **Auswirkungen der automatisierten Sicherheitsintegration**\n\nDie Integration von HackerOne und GitLab führt in der Praxis zu:\n\n* Bis zu 70 Prozent Zeitersparnis von der Entdeckung bis zur Behebung von Schwachstellen\n* Erhöhte Transparenz über den Sicherheitsstatus im gesamten Unternehmen\n* Effektivere Nutzung der Ressourcen im Security-Team\n* Gesteigerte Zufriedenheit der Entwickler(innen), da sie im bevorzugten Workflow bleiben können\n\n## **Keine Kompromisse bei der Shift Left Security**\n\nShift Left Security verschiebt das Thema Sicherheit weg von der Endkontrolle hin zur kontinuierlichen Begleitung des Entwicklungsprozesses. Durch Tools wie SAST, DAST, SCA und Container-Scanning lassen sich Schwachstellen frühzeitig identifizieren – noch bevor sie produktiv wirksam werden. Das senkt Kosten, reduziert Risiken und beschleunigt Entwicklungszyklen.\n\nErfolgreich ist dieser Ansatz jedoch nur, wenn Sicherheitsprüfungen eng in die[ CI/CD-Pipeline](https://about.gitlab.com/de-de/topics/ci-cd/cicd-pipeline/) und Entwicklungsumgebungen integriert werden und Entwickler(innen) durch gezielte Schulungen und klare Prozesse unterstützt werden. Die Fallstudie zu GitLab und HackerOne zeigt zudem, dass integrierte Plattformen Kontextwechsel vermeiden und die Effizienz deutlich steigern können. Entscheidend für eine nachhaltige Umsetzung ist eine Sicherheitskultur, in der Entwicklung und Security partnerschaftlich und auf Augenhöhe zusammenarbeiten.","Erkenne und behebe Sicherheitslücken früh mit Shift-Left-Security. Lerne aus HackerOnes GitLab-Story und erhalte praxisnahe DevSecOps-Tipps.","2025-12-08",{"featured":12,"template":13,"slug":697},"devsecops-shift-left-guide",{"content":699,"config":707},{"title":700,"description":701,"authors":702,"date":703,"body":704,"category":9,"tags":705,"heroImage":706},"Cloud-Kosten systematisch steuern – mit FinOps","FinOps verbindet Finance und IT, macht Cloud-Kosten transparent und wandelt reaktive Rechnungszahlung in proaktive Wert-Optimierung um.",[18],"2025-11-19","**FinOps** ist die Disziplin, die Cloud-Kosten-Management transformiert – von reaktiver Rechnungszahlung zu proaktiver Wert-Optimierung. Sie vereint Finance-, Technical- und Business-Teams um eine gemeinsame Sprache.\n\nWährend Cloud-Nutzung intensiviert wird, kämpfen Organisationen mit Ausgaben-Kontrolle. Ein Gartner-Report zeigt: **[69% der Organisationen überschritten 2023 ihr Cloud-Budget](https://www.gartner.com/peer-community/oneminuteinsights/omi-keeping-cloud-costs-check-it-leader-perspectives-rfz)**.\n\nDiese Unvorhersagbarkeit schwächt Finance-Vertrauen und erhöht Druck auf IT-Teams. FinOps bietet strukturierte Antwort: Kosten in Echtzeit sichtbar machen, Kultur gemeinsamer Verantwortung etablieren und jede Ausgabe an generiertem Business-Wert ausrichten.\n\nMehr als reine Kostenreduktions-Strategie ist FinOps ein operativer und kultureller Rahmen. Er ermöglicht Organisationen, Kontrolle über Cloud-Budgets zurückzugewinnen ohne Agilität oder Innovation zu opfern. Dieser Ansatz wird besonders relevant, wenn er direkt in [DevOps](https://about.gitlab.com/de-de/topics/devops/)- und [CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/)-Praktiken integriert wird, die auf der [GitLab-Plattform](https://about.gitlab.com/de-de/why-gitlab/) verfügbar sind.\n\n> **[→ GitLab Ultimate und GitLab Duo Enterprise kostenlos testen.](https://about.gitlab.com/de-de/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_de_blog_de)**\n\n## FinOps: Definition\n\nDer Begriff **FinOps**, Kurzform von *Financial Operations*, bezeichnet eine Disziplin, geboren aus einfacher Erkenntnis: explodierende Cloud-Nutzung erfordert neue finanzielle Governance. Klassische Budget-Methoden reichen nicht mehr, da sie Cloud-spezifische Schwankungen und Komplexität nicht berücksichtigen.\n\nFinOps geht weit über **Kostenreduktion** hinaus. Es geht nicht nur darum, Verschwendung zu tracken oder Rabatte mit Providern zu verhandeln. Es ist ein **kultureller und organisatorischer Ansatz**, der Finance-, Technology- und Business-Teams vereint. Sein Ziel: Innovation kanalisieren ohne zu bremsen, indem allen klare Sicht auf finanzielle Impacts ihrer **Infrastruktur**- und **Operations**-Entscheidungen gegeben wird.\n\nEine FinOps-Organisation sucht nicht, weniger auszugeben, sondern **besser auszugeben**: in die richtigen Ressourcen investieren, zum richtigen Zeitpunkt, mit messbarem Business-Return.\n\n## Warum wurde FinOps unverzichtbar?\n\nMulticloud setzt sich in den meisten Organisationen durch. AWS, Azure, Google Cloud und Private-Lösungen koexistieren, jeder mit eigenen Pricing-Modellen und Rabatten. Diese Diversität macht Budget-Tracking fragmentiert und verstärkt Governance-Komplexität.\n\nZu dieser Diversität kommen **Kosten-Schwankungen**. In selbst-gehosteten (On-Premise) Systemen war Budget im Voraus fixiert. In der Cloud kann jeder Load-Spike, Test-Projekt oder beschleunigtes Deployment die Rechnung über Nacht erhöhen. Diese Unvorhersagbarkeit unterminiert klassische Finance-Methoden und schafft dringenden Bedarf nach neuen Management-Praktiken.\n\nFinance-Services verlangen inzwischen mehr als unverständliche monatliche Cloud-Rechnungen. Sie erwarten verlässliche Prognosen, klare Ausgaben-Aufschlüsselung und Management-Logik vergleichbar mit anderen Unternehmens-Investitionen.\n\nDaher wurde Abstimmung zwischen Kosten und Business-Wert zentral. Jede Ausgabe muss mit einem Produkt oder Customer-Experience verknüpfbar sein. FinOps bringt diese gemeinsame Sprache, die technische Rechnung in Business-Dashboard transformiert.\n\nIn diesem Kontext entstand FinOps als strukturierter Rahmen zur Komplexitäts-Beherrschung.\n\n## Fundamentale FinOps-Prinzipien\n\nFinOps basiert auf geteilter Kultur, strukturiert um mehrere Schlüsselprinzipien:\n\n* **Team-übergreifende Kollaboration**: Kein Akteur kann allein steuern. Finance bringt Budget-Kontrolle, Engineering technische Realität, und Business-Teams Wert-Perspektive. Gemeinsam bauen sie eine **Organisation** fähig zu ausgewogenen Entscheidungen, aber diese Sharing-Logik allein reicht nicht.\n* **Verteilte Verantwortung und Governance**: Jedes Team übernimmt Kosten seiner technischen Entscheidungen (*you build it, you run it, you pay it*), aber zentrale Funktion definiert Standards, setzt KPIs und liefert Tools zur globalen Konsistenz-Aufrechterhaltung. Diese Governance beschränkt sich nicht auf Kosten – sie betrifft auch **Management** von Umgebungen und Ressourcen.\n* **Business-Wert als Kompass**: Cloud-Ausgabe macht nur Sinn, wenn sie zu Produkt, Service oder Customer-Experience beiträgt. FinOps misst diese direkte Verknüpfung zwischen Kosten und ROI.\n* **Transparenz und Reaktivität durch Daten**: Kosten müssen in Echtzeit sichtbar sein mit klarem, actionable Reporting – idealerweise in Workflows, wo Teams bereits arbeiten. Dies ist Bedingung für schnelle Korrektur und Vertrauensaufbau.\n* **Dezentralisierte Entscheidungsfindung mit zentraler Governance**: Teams treffen Echtzeit-Entscheidungen über ihre Ressourcen im Rahmen etablierter Leitplanken statt auf Approval-Chains zu warten.\n* **Variables Cloud-Modell**: Statt Schwankungen zu erleiden, macht FinOps sie zum Asset. Ressourcen an Bedarf anpassen, Skalierung automatisieren und via Reservierungen antizipieren transformiert Flexibilität in strategischen Hebel.\n* **Kontinuierliche Optimierungs-Kultur**: FinOps ist permanente Praxis, kein punktuelles Projekt. Teams identifizieren kontinuierlich Verschwendung, optimieren Ressourcen und verfeinern Prozesse während Cloud-Nutzung evolviert.\n\nDiese Prinzipien bilden das kulturelle Fundament. Für Umsetzung braucht es klaren Rahmen und definierten Lifecycle, fähig Organisationen über Zeit zu begleiten.\n\n## FinOps-Framework und Lifecycle\n\nZur Transformation dieser Prinzipien in nachhaltige Praktiken bietet die FinOps Foundation ein anerkanntes **Framework**. Es beschreibt Action-Domänen, involvierte Rollen und Reife-Stufen.\n\n### Die drei Framework-Domänen\n\nDas FinOps Foundation Framework basiert auf drei permanenten Domänen:\n\n* **Informieren**: Kosten sichtbar und verständlich machen durch Echtzeit-Finance-Daten-Sharing.\n* **Optimieren**: Ineffizienzen identifizieren, Ressourcen anpassen und kontinuierliche Optimierungs-Logik einführen.\n* **Operieren**: Nachhaltige Governance installieren und langfristig steuern.\n\nDiese Domänen sind nicht sequenziell – sie bilden kontinuierlichen Zyklus. Je besser informiert wird, desto besser optimiert wird, und desto mehr verankert sich Governance in der Organisation.\n\n### Rollen und Organisations-Reife\n\nJede Domäne mobilisiert spezifische Akteure: Finance für Budget-Kontrolle, Engineering für technische Übersetzung, Business-Teams für Business-Wert und Governance für gemeinsame Standards.\n\nFinOps-Einführung misst sich auch an Reife-Stufen (*crawl, walk, run*), die schrittweisen Weg einer Organisation zu vollständig beherrschtem Cloud-Management abbilden.\n\n### Die \"Crawl, Walk, Run\"-Stufen\n\nDas **Crawl-Walk-Run**-Modell beschreibt Organisations-Reife:\n\n* **Crawl**: Erste Schritte, Basic-Reporting, wenige nachverfolgte KPIs.\n* **Walk**: Praktiken-Integration, regelmäßige Optimierung, erste Rituale und Automatisierungen.\n* **Run**: Fortgeschrittene Reife, komplette Automatisierung, robuste Governance, FinOps in Unternehmensstrategie integriert.\n\nDieser Rahmen gibt Organisationen einen Kompass: er ermöglicht zu wissen, wo sie stehen und wie sie zu nachhaltiger Cloud-Ausgaben-Beherrschung fortschreiten.\n\n## Warum und wie FinOps-Modell einführen?\n\nFinOps-Ansatz umzusetzen bedeutet, diese Herausforderungen zu adressieren: Kosten-Schwankungen, Budget-Druck, Transparenz-Bedarf und Effizienz-Suche. Für Erfolg muss Deployment schrittweise sein und in realen Use Cases verankert.\n\n### Cloud-Kosten-Schwankungen und -Unvorhersagbarkeit beherrschen\n\nCloud funktioniert nach Nutzung, was Kosten natürlich schwanken lässt. Um zu vermeiden, dass diese Instabilität zu Budget-Risiko wird, erfordert FinOps: Consumption-Spikes zu kartieren, Budget-Steuerungs-Regeln zu setzen und Infrastruktur-Szenarien zu modellieren. Ziel: unvorhersagbare Ausgabe in kontrollierte Ausgabe transformieren.\n\n### Kosten und Business-Wert abstimmen\n\nSobald Transparenz erreicht ist, wird die Frage: *Schafft jede Ausgabe wirklich Wert?* FinOps verknüpft Kosten mit Produkten und Services und misst sie via Unit-Indikatoren wie Kosten pro User oder pro Transaktion. Dieser Ansatz ermöglicht Investment-Priorisierung nach Business-ROI und gibt Cloud-Kosten Bedeutung.\n\n### Governance und geteilte Regeln etablieren\n\nDamit diese Logik über Zeit hält, ist klare Governance notwendig. Tagging-Standards, Ressourcen-Owner-Definition und Budget-Attribution pro Team garantieren Nachvollziehbarkeit. Arbitrage-Prozesse ergänzen diesen Rahmen, validiert auf höchster Unternehmensebene. Governance wird dann Rückgrat des Modells.\n\n### Auf dedizierte Tools und Metriken setzen\n\nGovernance funktioniert nicht ohne verlässliche Daten. Cloud-Provider bieten eigene Tracking-Tools, aber diese bleiben oft fragmentiert und schwer vergleichbar. Die Herausforderung: Information zentralisieren und in derselben Umgebung umsetzbar machen. Einfache KPIs wie Kosten pro Workload, pro User oder Effizienz pro Team zeigen bereits die Verknüpfung zwischen Nutzung und Wert. Direkt in existierende Workflows integriert werden sie konkrete tägliche Steuerungs-Hebel.\n\n### Schrittweisen Ansatz verfolgen\n\nFinOps erfordert keine Komplettumstellung. Erfolg kommt durch schrittweise Einführung: FinOps-MVP starten wie ein [DevOps-Projekt](https://about.gitlab.com/de-de/solutions/devops-platform/), schnelle Gewinne einfahren und Umfang schrittweise erweitern. Ziel ist nicht sofortige Perfektion, sondern Aufbau nachhaltiger Dynamik, die sich in Kultur verankert.\n\n### Beispiele schneller Aktionen für FinOps-Strategie-Entwicklung\n\nEine FinOps-Strategie muss Wert schnell demonstrieren. Drei einfache Aktionen reichen oft, sichtbare Einsparungen zu generieren und den Ansatz zu validieren:\n\n* **Orphan-Ressourcen eliminieren**: Vergessene Storage-Volumes, ungenutzte IPs oder inaktive Test-Umgebungen. Diese diskreten Leaks repräsentieren oft mehrere Prozent der monatlichen Rechnung.\n* **Überbereitgestellte Instances rightsizen**: Viele Ressourcen laufen auf Bruchteil ihrer Kapazität. Größen-Anpassung reduziert Kosten sofort ohne Infrastruktur-Performance-Verlust.\n* **Nicht-kritische Umgebungen automatisch stoppen**: Nachts und Wochenenden abschalten, was nicht kontinuierlich laufen muss, generiert wiederkehrende, einfache, nachhaltige Einsparungen.\n\nDiese schnellen Gesten geben klares Signal: FinOps produziert sofortige Ergebnisse und bereitet Boden für nachhaltige Einführung.\n\n> **Die FinOps Foundation**: Gegründet 2019 und an Linux Foundation angegliedert, definiert die FinOps Foundation Disziplin-Standards und föderiert globale Community. Sie verbreitet anerkanntes Framework (Inform, Optimize, Operate), bietet Trainings und Zertifizierungen und organisiert Practitioner-Austausch. Sie ist heute die Referenz zur Strukturierung und Weiterentwicklung von FinOps-Praktiken.\n\n## FinOps-Herausforderungen und -Limitationen\n\nFinOps-Ansatz zu übernehmen ist kein ruhiger Fluss. Während die Disziplin durch Transparenz- und Kontroll-Versprechen überzeugt, konfrontiert Implementierung Organisationen mit mehreren wiederkehrenden Hindernissen.\n\n### Schwieriger Kultur-Wandel\n\nDie erste Herausforderung ist kulturell. FinOps reduziert sich nicht auf Tool- oder Dashboard-Deployment – es ist primär eine **neue Art zusammenzuarbeiten**. Finance-, Technology- und Business-Teams müssen Verantwortungen teilen, was Gewohnheiten durcheinanderbringt. Wie bei jeder Transformation ist **Widerstands gegen Veränderung** oft das erste Hindernis.\n\nDiese kulturelle Schwierigkeit führt zu einer weiteren.\n\n### Organisatorische Silos bremsen Kollaboration\n\nIn vielen Organisationen bleiben Teams in Silos eingeschlossen: Finance auf einer Seite, IT auf der anderen, Business-Teams separat. Ohne reibungslose Kommunikation ist Abstimmung zwischen Kosten und Business-Wert unmöglich. FinOps-Governance zielt präzise darauf ab, diese Trennwände zu durchbrechen, aber dies erfordert **starken Management-Support** zur Änderung organisatorischer Reflexe.\n\nUnd selbst wenn Teams kooperieren, tritt ein weiteres Hindernis auf: die Daten selbst.\n\n### Partielle Sichtbarkeit und komplexe Daten-Nutzung\n\nCloud-Kosten sind notorisch schwer zu lesen, besonders in Multicloud-Umgebungen. Daten existieren, bleiben aber oft **verstreut, roh und schwer zu interpretieren**. Teams haben nicht immer die richtigen Tools zur Zentralisierung und Umsetzbarkeit. FinOps-versprochene Transparenz kann daher auf technische und analytische Grenzen stoßen.\n\nDieser Klarheits-Mangel paart sich mit Kompetenz-Mangel.\n\n### Mangel an Kompetenzen und passenden Tools\n\nFinOps ist noch junge Disziplin, und erfahrene Profile sind rar. Viele Organisationen müssen Teams intern schulen, was Einführung schrittweise aber manchmal langsam macht. Diese Kompetenz-Entwicklung ist essenziell, da Erfolg gleichermaßen auf Kultur und Technik basiert.\n\nTools repräsentieren eine weitere Herausforderung. Organisationen haben zahlreiche Tools zur Cloud-Kosten-Analyse, aber diese Lösungen sind oft verstreut und schwer in einheitliche Vision zu integrieren. Das Ergebnis ist paradox: mehr Daten, aber nicht notwendigerweise mehr Klarheit.\n\nDie wahre Herausforderung ist daher, einen Tool-Ansatz zu bauen, der einfach bleibt und auf Organisations-Reife abgestimmt ist. Schrittweise vorgehen, Lesbarkeit und Effizienz priorisieren, verhindert Transformation eines Governance-Problems in Tool-Problem.\n\n### Inhärent instabiles Cloud-Budget\n\nSelbst mit solider Governance und performanten Tools bleiben Cloud-Kosten naturgemäß instabil. Load-Spikes, Hybrid-Umgebungen oder KI-Workloads schaffen schwer vorhersagbare Schwankungen. Budget-Prognosen müssen daher permanent revidiert werden, da unerwarteter Verbrauch selbst strengste Schätzungen entgleisen lassen kann.\n\nDiese Hindernisse machen FinOps nicht ungültig – sie zeigen, warum die Disziplin weiter evolvieren muss.\n\n## FinOps-Trends und Perspektiven\n\nDer FinOps-Ansatz steht erst am Anfang seiner Geschichte. Die Disziplin evolviert kontinuierlich zur Adressierung neuer Herausforderungen, die weit über reine Kosten-Fragen hinausgehen.\n\nDer erste Trend ist **Nachhaltigkeit**. Mehr und mehr Organisationen wollen Cloud-Ausgaben optimieren und gleichzeitig Carbon-Footprint reduzieren. FinOps öffnet sich zu **GreenOps**, wo ökonomische Performance und Umwelt-Verantwortung Hand in Hand gehen.\n\nDie zweite Evolution ist **Automatisierung**. Wachsende Cloud-Komplexität macht manuelle Steuerung unmöglich. FinOps-as-Code-Praktiken und KI-Nutzung zur Verbrauchs-Analyse oder automatischen Ressourcen-Anpassung werden zur Norm.\n\nDritte Transformation: Impact von **KI-Workloads**. Diese massiven, unvorhersagbaren Loads redefinieren Cloud-Finance-Governance. Sie erzwingen neue Prognose-Methoden, neue Indikatoren und noch engere Kollaboration zwischen Finance und Engineering.\n\nDie vierte Änderung ist **Konvergenz mit Platform Engineering**. Während Organisationen interne Development-Plattformen zur Standardisierung und Beschleunigung von Software-Delivery bauen, findet FinOps seinen effizientesten Umsetzungs-Kanal. Platform-Teams integrieren Kosten-Intelligence direkt in die Struktur, wie Software gebaut und deployed wird. Durch Self-Service-Portale, \"Golden Paths\" und Infrastruktur-Templates machen sie Kosten-Optimierung zu Standard-Verhalten statt Nachgedanke. Teams erhalten Echtzeit-Kosten-Feedback in Workflows, Ressourcen-Limits werden via Policy as Code durchgesetzt, und finanzielle Guardrails werden unsichtbare Plattform-Features. Es geht nicht nur darum, Kosten-Dashboards hinzuzufügen – es geht darum, fundamental zu überdenken, wie FinOps in großem Maßstab funktioniert.\n\nSchließlich bleibt Reife noch niedrig. Viele Organisationen machen erste Schritte, oft im \"Crawl\"-Stadium. Die Herausforderung kommender Jahre: **gemeinsam Reife steigern**, damit FinOps nicht punktuelle Initiative, sondern integrierte organisatorische Kompetenz wird.\n\nFinOps ist daher kein Selbstzweck, sondern schrittweiser Ansatz. Er ermöglicht, Cloud von unvorhersagbarem Kosten-Center in strategischen Hebel zu transformieren. Direkt in DevSecOps- und CI/CD-Praktiken integriert, bringt er Finance-, Technology- und Business-Teams noch enger um gemeinsame Ziele zusammen.\n\nDieser Weg beginnt mit Integration von FinOps-Praktiken direkt in existierende Development-Workflows. Hier kommen Plattformen wie GitLab ins Spiel.\n\n## GitLab und FinOps-Ansatz\n\nGitLab trägt zum FinOps-Ansatz bei durch Sichtbarkeit auf Development-Ressourcen-Nutzung. Die Plattform ermöglicht Tracking von Compute-Minuten-Verbrauch pro Projekt und Namespace, erleichtert damit Kosten-Zuordnung zu Teams. Zudem können Admins Nutzungs-Quotas konfigurieren und Verbrauchs-Trends via Usage-Dashboards überwachen. Dieser Ansatz hilft Organisationen, ihre [CI/CD-Pipeline](https://about.gitlab.com/de-de/topics/ci-cd/cicd-pipeline/)-bezogenen Ausgaben besser zu verstehen und Runner-Nutzung zu optimieren. Durch Integration dieser Metriken in Development-Workflows sensibilisiert GitLab Technical-Teams für Impact ihrer Praktiken auf operative Kosten.\n\n> **[→ GitLab Ultimate und GitLab Duo Enterprise kostenlos testen.](https://about.gitlab.com/de-de/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_de_blog_de)**",[23,106],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1760520341/suhp5cpbgzqikafvl7p1.jpg",{"featured":12,"template":13,"slug":708},"what-is-finops",{"promotions":710},[711,725,737],{"id":712,"categories":713,"header":715,"text":716,"button":717,"image":722},"ai-modernization",[714],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":718,"config":719},"Get your AI maturity score",{"href":720,"dataGaName":721,"dataGaLocation":242},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":723},{"src":724},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":726,"categories":727,"header":729,"text":716,"button":730,"image":734},"devops-modernization",[728,9],"product","Are you just managing tools or shipping innovation?",{"text":731,"config":732},"Get your DevOps maturity score",{"href":733,"dataGaName":721,"dataGaLocation":242},"/assessments/devops-modernization-assessment/",{"config":735},{"src":736},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":738,"categories":739,"header":740,"text":716,"button":741,"image":745},"security-modernization",[684],"Are you trading speed for security?",{"text":742,"config":743},"Get your security maturity score",{"href":744,"dataGaName":721,"dataGaLocation":242},"/assessments/security-modernization-assessment/",{"config":746},{"src":747},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":749,"blurb":750,"button":751,"secondaryButton":756},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":752,"config":753},"Kostenlosen Test starten",{"href":754,"dataGaName":48,"dataGaLocation":755},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":50,"config":757},{"href":52,"dataGaName":53,"dataGaLocation":755},1772652044901]