[{"data":1,"prerenderedAt":889},["ShallowReactive",2],{"/de-de/blog/categories/security/":3,"navigation-de-de":22,"banner-de-de":442,"footer-de-de":455,"security-category-page-de-de":665},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":15,"_type":16,"title":17,"_source":18,"_file":19,"_stem":20,"_extension":21},"/de-de/blog/categories/security","categories",false,"",{"title":9,"description":10},"Sicherheit","Browse articles related to Sicherheit on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":6},"BlogCategory","security","content:de-de:blog:categories:security.yml","yaml","Security","content","de-de/blog/categories/security.yml","de-de/blog/categories/security","yml",{"_path":23,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":25,"_id":438,"_type":16,"title":439,"_source":18,"_file":440,"_stem":441,"_extension":21},"/shared/de-de/main-navigation","de-de",{"logo":26,"freeTrial":31,"sales":36,"login":41,"items":46,"search":379,"minimal":415,"duo":429},{"config":27},{"href":28,"dataGaName":29,"dataGaLocation":30},"/de-de/","gitlab logo","header",{"text":32,"config":33},"Kostenlose Testversion anfordern",{"href":34,"dataGaName":35,"dataGaLocation":30},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":37,"config":38},"Vertrieb kontaktieren",{"href":39,"dataGaName":40,"dataGaLocation":30},"/de-de/sales/","sales",{"text":42,"config":43},"Anmelden",{"href":44,"dataGaName":45,"dataGaLocation":30},"https://gitlab.com/users/sign_in/","sign in",[47,91,189,194,300,360],{"text":48,"config":49,"cards":51,"footer":74},"Plattform",{"dataNavLevelOne":50},"platform",[52,58,66],{"title":48,"description":53,"link":54},"Die umfassendste KI-basierte DevSecOps-Plattform",{"text":55,"config":56},"Erkunde unsere Plattform",{"href":57,"dataGaName":50,"dataGaLocation":30},"/de-de/platform/",{"title":59,"description":60,"link":61},"GitLab Duo (KI)","Entwickle Software schneller mit KI in jeder Phase der Entwicklung",{"text":62,"config":63},"Lerne GitLab Duo kennen",{"href":64,"dataGaName":65,"dataGaLocation":30},"/de-de/gitlab-duo/","gitlab duo ai",{"title":67,"description":68,"link":69},"Gründe, die für GitLab sprechen","10 Gründe, warum Unternehmen sich für GitLab entscheiden",{"text":70,"config":71},"Mehr erfahren",{"href":72,"dataGaName":73,"dataGaLocation":30},"/de-de/why-gitlab/","why gitlab",{"title":75,"items":76},"Erste Schritte mit",[77,82,87],{"text":78,"config":79},"Platform Engineering",{"href":80,"dataGaName":81,"dataGaLocation":30},"/de-de/solutions/platform-engineering/","platform engineering",{"text":83,"config":84},"Entwicklererfahrung",{"href":85,"dataGaName":86,"dataGaLocation":30},"/de-de/developer-experience/","Developer experience",{"text":88,"config":89},"MLOps",{"href":90,"dataGaName":88,"dataGaLocation":30},"/de-de/topics/devops/the-role-of-ai-in-devops/",{"text":92,"left":93,"config":94,"link":96,"lists":100,"footer":171},"Produkt",true,{"dataNavLevelOne":95},"solutions",{"text":97,"config":98},"Alle Lösungen anzeigen",{"href":99,"dataGaName":95,"dataGaLocation":30},"/de-de/solutions/",[101,127,149],{"title":102,"description":103,"link":104,"items":109},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":105},{"icon":106,"href":107,"dataGaName":108,"dataGaLocation":30},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[110,114,118,123],{"text":111,"config":112},"CI/CD",{"href":113,"dataGaLocation":30,"dataGaName":111},"/de-de/solutions/continuous-integration/",{"text":115,"config":116},"KI-unterstützte Entwicklung",{"href":64,"dataGaLocation":30,"dataGaName":117},"AI assisted development",{"text":119,"config":120},"Quellcodeverwaltung",{"href":121,"dataGaLocation":30,"dataGaName":122},"/de-de/solutions/source-code-management/","Source Code Management",{"text":124,"config":125},"Automatisierte Softwarebereitstellung",{"href":107,"dataGaLocation":30,"dataGaName":126},"Automated software delivery",{"title":9,"description":128,"link":129,"items":134},"Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":130},{"href":131,"dataGaName":132,"dataGaLocation":30,"icon":133},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[135,139,144],{"text":136,"config":137},"Sicherheit und Compliance",{"href":131,"dataGaLocation":30,"dataGaName":138},"Security & Compliance",{"text":140,"config":141},"Schutz der Software-Lieferkette",{"href":142,"dataGaLocation":30,"dataGaName":143},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Compliance und Governance",{"href":147,"dataGaLocation":30,"dataGaName":148},"/de-de/solutions/continuous-software-compliance/","Compliance and governance",{"title":150,"link":151,"items":156},"Bewertung",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":30},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[157,161,166],{"text":158,"config":159},"Sichtbarkeit und Bewertung",{"href":154,"dataGaLocation":30,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"Wertstrommanagement",{"href":164,"dataGaLocation":30,"dataGaName":165},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":167,"config":168},"Analysen und Einblicke",{"href":169,"dataGaLocation":30,"dataGaName":170},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":172,"items":173},"GitLab für",[174,179,184],{"text":175,"config":176},"Enterprise",{"href":177,"dataGaLocation":30,"dataGaName":178},"/de-de/enterprise/","enterprise",{"text":180,"config":181},"Kleinunternehmen",{"href":182,"dataGaLocation":30,"dataGaName":183},"/de-de/small-business/","small business",{"text":185,"config":186},"den öffentlichen Sektor",{"href":187,"dataGaLocation":30,"dataGaName":188},"/de-de/solutions/public-sector/","public sector",{"text":190,"config":191},"Preise",{"href":192,"dataGaName":193,"dataGaLocation":30,"dataNavLevelOne":193},"/de-de/pricing/","pricing",{"text":195,"config":196,"link":198,"lists":202,"feature":287},"Ressourcen",{"dataNavLevelOne":197},"resources",{"text":199,"config":200},"Alle Ressourcen anzeigen",{"href":201,"dataGaName":197,"dataGaLocation":30},"/de-de/resources/",[203,236,259],{"title":204,"items":205},"Erste Schritte",[206,211,216,221,226,231],{"text":207,"config":208},"Installieren",{"href":209,"dataGaName":210,"dataGaLocation":30},"/de-de/install/","install",{"text":212,"config":213},"Kurzanleitungen",{"href":214,"dataGaName":215,"dataGaLocation":30},"/de-de/get-started/","quick setup checklists",{"text":217,"config":218},"Lernen",{"href":219,"dataGaLocation":30,"dataGaName":220},"https://university.gitlab.com/","learn",{"text":222,"config":223},"Produktdokumentation",{"href":224,"dataGaName":225,"dataGaLocation":30},"https://docs.gitlab.com/","product documentation",{"text":227,"config":228},"Best-Practice-Videos",{"href":229,"dataGaName":230,"dataGaLocation":30},"/de-de/getting-started-videos/","best practice videos",{"text":232,"config":233},"Integrationen",{"href":234,"dataGaName":235,"dataGaLocation":30},"/de-de/integrations/","integrations",{"title":237,"items":238},"Entdecken",[239,244,249,254],{"text":240,"config":241},"Kundenerfolge",{"href":242,"dataGaName":243,"dataGaLocation":30},"/customers/","customer success stories",{"text":245,"config":246},"Blog",{"href":247,"dataGaName":248,"dataGaLocation":30},"/de-de/blog/","blog",{"text":250,"config":251},"Remote",{"href":252,"dataGaName":253,"dataGaLocation":30},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":255,"config":256},"TeamOps",{"href":257,"dataGaName":258,"dataGaLocation":30},"/de-de/teamops/","teamops",{"title":260,"items":261},"Vernetzen",[262,267,272,277,282],{"text":263,"config":264},"GitLab-Services",{"href":265,"dataGaName":266,"dataGaLocation":30},"/de-de/services/","services",{"text":268,"config":269},"Community",{"href":270,"dataGaName":271,"dataGaLocation":30},"/community/","community",{"text":273,"config":274},"Forum",{"href":275,"dataGaName":276,"dataGaLocation":30},"https://forum.gitlab.com/","forum",{"text":278,"config":279},"Veranstaltungen",{"href":280,"dataGaName":281,"dataGaLocation":30},"/events/","events",{"text":283,"config":284},"Partner",{"href":285,"dataGaName":286,"dataGaLocation":30},"/de-de/partners/","partners",{"backgroundColor":288,"textColor":289,"text":290,"image":291,"link":295},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":292,"config":293},"the source promo card",{"src":294},"/images/navigation/the-source-promo-card.svg",{"text":296,"config":297},"Lies die News",{"href":298,"dataGaName":299,"dataGaLocation":30},"/de-de/the-source/","the source",{"text":301,"config":302,"lists":304},"Unternehmen",{"dataNavLevelOne":303},"company",[305],{"items":306},[307,312,318,320,325,330,335,340,345,350,355],{"text":308,"config":309},"Über",{"href":310,"dataGaName":311,"dataGaLocation":30},"/de-de/company/","about",{"text":313,"config":314,"footerGa":317},"Karriere",{"href":315,"dataGaName":316,"dataGaLocation":30},"/jobs/","jobs",{"dataGaName":316},{"text":278,"config":319},{"href":280,"dataGaName":281,"dataGaLocation":30},{"text":321,"config":322},"Geschäftsführung",{"href":323,"dataGaName":324,"dataGaLocation":30},"/company/team/e-group/","leadership",{"text":326,"config":327},"Team",{"href":328,"dataGaName":329,"dataGaLocation":30},"/company/team/","team",{"text":331,"config":332},"Handbuch",{"href":333,"dataGaName":334,"dataGaLocation":30},"https://handbook.gitlab.com/","handbook",{"text":336,"config":337},"Investor Relations",{"href":338,"dataGaName":339,"dataGaLocation":30},"https://ir.gitlab.com/","investor relations",{"text":341,"config":342},"Trust Center",{"href":343,"dataGaName":344,"dataGaLocation":30},"/de-de/security/","trust center",{"text":346,"config":347},"AI Transparency Center",{"href":348,"dataGaName":349,"dataGaLocation":30},"/de-de/ai-transparency-center/","ai transparency center",{"text":351,"config":352},"Newsletter",{"href":353,"dataGaName":354,"dataGaLocation":30},"/company/contact/","newsletter",{"text":356,"config":357},"Presse",{"href":358,"dataGaName":359,"dataGaLocation":30},"/press/","press",{"text":361,"config":362,"lists":363},"Kontakt",{"dataNavLevelOne":303},[364],{"items":365},[366,369,374],{"text":37,"config":367},{"href":39,"dataGaName":368,"dataGaLocation":30},"talk to sales",{"text":370,"config":371},"Support",{"href":372,"dataGaName":373,"dataGaLocation":30},"/support/","get help",{"text":375,"config":376},"Kundenportal",{"href":377,"dataGaName":378,"dataGaLocation":30},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":380,"login":381,"suggestions":388},"Schließen",{"text":382,"link":383},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":384,"config":385},"gitlab.com",{"href":44,"dataGaName":386,"dataGaLocation":387},"search login","search",{"text":389,"default":390},"Vorschläge",[391,394,399,401,406,411],{"text":59,"config":392},{"href":64,"dataGaName":393,"dataGaLocation":387},"GitLab Duo (AI)",{"text":395,"config":396},"Code Suggestions (KI)",{"href":397,"dataGaName":398,"dataGaLocation":387},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":111,"config":400},{"href":113,"dataGaName":111,"dataGaLocation":387},{"text":402,"config":403},"GitLab auf AWS",{"href":404,"dataGaName":405,"dataGaLocation":387},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":407,"config":408},"GitLab auf Google Cloud",{"href":409,"dataGaName":410,"dataGaLocation":387},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":412,"config":413},"Warum GitLab?",{"href":72,"dataGaName":414,"dataGaLocation":387},"Why GitLab?",{"freeTrial":416,"mobileIcon":421,"desktopIcon":426},{"text":417,"config":418},"Kostenlos testen",{"href":419,"dataGaName":35,"dataGaLocation":420},"https://gitlab.com/-/trials/new/","nav",{"altText":422,"config":423},"GitLab-Symbol",{"src":424,"dataGaName":425,"dataGaLocation":420},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":422,"config":427},{"src":428,"dataGaName":425,"dataGaLocation":420},"/images/brand/gitlab-logo-type.svg",{"freeTrial":430,"mobileIcon":434,"desktopIcon":436},{"text":431,"config":432},"Erfahre mehr über GitLab Duo",{"href":64,"dataGaName":433,"dataGaLocation":420},"gitlab duo",{"altText":422,"config":435},{"src":424,"dataGaName":425,"dataGaLocation":420},{"altText":422,"config":437},{"src":428,"dataGaName":425,"dataGaLocation":420},"content:shared:de-de:main-navigation.yml","Main Navigation","shared/de-de/main-navigation.yml","shared/de-de/main-navigation",{"_path":443,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"title":444,"titleMobile":444,"button":445,"config":450,"_id":452,"_type":16,"_source":18,"_file":453,"_stem":454,"_extension":21},"/shared/de-de/banner","GitLab 18 und der nächste Schritt im Bereich der intelligenten DevSecOps. Sei am 24. Juni dabei.",{"text":446,"config":447},"Jetzt registrieren",{"href":448,"dataGaName":449,"dataGaLocation":30},"/de-de/eighteen/","gitlab 18 banner",{"layout":451},"release","content:shared:de-de:banner.yml","shared/de-de/banner.yml","shared/de-de/banner",{"_path":456,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":457,"_id":661,"_type":16,"title":662,"_source":18,"_file":663,"_stem":664,"_extension":21},"/shared/de-de/main-footer",{"text":458,"source":459,"edit":465,"contribute":470,"config":475,"items":480,"minimal":653},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":460,"config":461},"Quelltext der Seite anzeigen",{"href":462,"dataGaName":463,"dataGaLocation":464},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":466,"config":467},"Diese Seite bearbeiten",{"href":468,"dataGaName":469,"dataGaLocation":464},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":471,"config":472},"Beteilige dich",{"href":473,"dataGaName":474,"dataGaLocation":464},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":476,"facebook":477,"youtube":478,"linkedin":479},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[481,504,559,588,623],{"title":48,"links":482,"subMenu":487},[483],{"text":484,"config":485},"DevSecOps-Plattform",{"href":57,"dataGaName":486,"dataGaLocation":464},"devsecops platform",[488],{"title":190,"links":489},[490,494,499],{"text":491,"config":492},"Tarife anzeigen",{"href":192,"dataGaName":493,"dataGaLocation":464},"view plans",{"text":495,"config":496},"Vorteile von Premium",{"href":497,"dataGaName":498,"dataGaLocation":464},"/de-de/pricing/premium/","why premium",{"text":500,"config":501},"Vorteile von Ultimate",{"href":502,"dataGaName":503,"dataGaLocation":464},"/de-de/pricing/ultimate/","why ultimate",{"title":505,"links":506},"Lösungen",[507,512,515,517,522,527,531,534,537,542,544,546,549,554],{"text":508,"config":509},"Digitale Transformation",{"href":510,"dataGaName":511,"dataGaLocation":464},"/de-de/solutions/digital-transformation/","digital transformation",{"text":136,"config":513},{"href":131,"dataGaName":514,"dataGaLocation":464},"security & compliance",{"text":124,"config":516},{"href":107,"dataGaName":108,"dataGaLocation":464},{"text":518,"config":519},"Agile Entwicklung",{"href":520,"dataGaName":521,"dataGaLocation":464},"/de-de/solutions/agile-delivery/","agile delivery",{"text":523,"config":524},"Cloud-Transformation",{"href":525,"dataGaName":526,"dataGaLocation":464},"/de-de/solutions/cloud-native/","cloud transformation",{"text":528,"config":529},"SCM",{"href":121,"dataGaName":530,"dataGaLocation":464},"source code management",{"text":111,"config":532},{"href":113,"dataGaName":533,"dataGaLocation":464},"continuous integration & delivery",{"text":162,"config":535},{"href":164,"dataGaName":536,"dataGaLocation":464},"value stream management",{"text":538,"config":539},"GitOps",{"href":540,"dataGaName":541,"dataGaLocation":464},"/de-de/solutions/gitops/","gitops",{"text":175,"config":543},{"href":177,"dataGaName":178,"dataGaLocation":464},{"text":180,"config":545},{"href":182,"dataGaName":183,"dataGaLocation":464},{"text":547,"config":548},"Öffentlicher Sektor",{"href":187,"dataGaName":188,"dataGaLocation":464},{"text":550,"config":551},"Bildungswesen",{"href":552,"dataGaName":553,"dataGaLocation":464},"/de-de/solutions/education/","education",{"text":555,"config":556},"Finanzdienstleistungen",{"href":557,"dataGaName":558,"dataGaLocation":464},"/de-de/solutions/finance/","financial services",{"title":195,"links":560},[561,563,565,567,570,572,574,576,578,580,582,584,586],{"text":207,"config":562},{"href":209,"dataGaName":210,"dataGaLocation":464},{"text":212,"config":564},{"href":214,"dataGaName":215,"dataGaLocation":464},{"text":217,"config":566},{"href":219,"dataGaName":220,"dataGaLocation":464},{"text":222,"config":568},{"href":224,"dataGaName":569,"dataGaLocation":464},"docs",{"text":245,"config":571},{"href":247,"dataGaName":248,"dataGaLocation":464},{"text":240,"config":573},{"href":242,"dataGaName":243,"dataGaLocation":464},{"text":250,"config":575},{"href":252,"dataGaName":253,"dataGaLocation":464},{"text":263,"config":577},{"href":265,"dataGaName":266,"dataGaLocation":464},{"text":255,"config":579},{"href":257,"dataGaName":258,"dataGaLocation":464},{"text":268,"config":581},{"href":270,"dataGaName":271,"dataGaLocation":464},{"text":273,"config":583},{"href":275,"dataGaName":276,"dataGaLocation":464},{"text":278,"config":585},{"href":280,"dataGaName":281,"dataGaLocation":464},{"text":283,"config":587},{"href":285,"dataGaName":286,"dataGaLocation":464},{"title":301,"links":589},[590,592,594,596,598,600,602,607,612,614,616,618],{"text":308,"config":591},{"href":310,"dataGaName":303,"dataGaLocation":464},{"text":313,"config":593},{"href":315,"dataGaName":316,"dataGaLocation":464},{"text":321,"config":595},{"href":323,"dataGaName":324,"dataGaLocation":464},{"text":326,"config":597},{"href":328,"dataGaName":329,"dataGaLocation":464},{"text":331,"config":599},{"href":333,"dataGaName":334,"dataGaLocation":464},{"text":336,"config":601},{"href":338,"dataGaName":339,"dataGaLocation":464},{"text":603,"config":604},"Umwelt, Soziales und Governance",{"href":605,"dataGaName":606,"dataGaLocation":464},"/de-de/environmental-social-governance/","environmental, social and governance",{"text":608,"config":609},"Vielfalt, Inklusion und Zugehörigkeit",{"href":610,"dataGaName":611,"dataGaLocation":464},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":341,"config":613},{"href":343,"dataGaName":344,"dataGaLocation":464},{"text":351,"config":615},{"href":353,"dataGaName":354,"dataGaLocation":464},{"text":356,"config":617},{"href":358,"dataGaName":359,"dataGaLocation":464},{"text":619,"config":620},"Transparenzerklärung zu moderner Sklaverei",{"href":621,"dataGaName":622,"dataGaLocation":464},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":624,"links":625},"Nimm Kontakt auf",[626,629,631,633,638,643,648],{"text":627,"config":628},"Sprich mit einem Experten/einer Expertin",{"href":39,"dataGaName":40,"dataGaLocation":464},{"text":370,"config":630},{"href":372,"dataGaName":373,"dataGaLocation":464},{"text":375,"config":632},{"href":377,"dataGaName":378,"dataGaLocation":464},{"text":634,"config":635},"Status",{"href":636,"dataGaName":637,"dataGaLocation":464},"https://status.gitlab.com/","status",{"text":639,"config":640},"Nutzungsbedingungen",{"href":641,"dataGaName":642,"dataGaLocation":464},"/terms/","terms of use",{"text":644,"config":645},"Datenschutzerklärung",{"href":646,"dataGaName":647,"dataGaLocation":464},"/privacy/","privacy statement",{"text":649,"config":650},"Cookie-Einstellungen",{"dataGaName":651,"dataGaLocation":464,"id":652,"isOneTrustButton":93},"cookie preferences","ot-sdk-btn",{"items":654},[655,657,659],{"text":639,"config":656},{"href":641,"dataGaName":642,"dataGaLocation":464},{"text":644,"config":658},{"href":646,"dataGaName":647,"dataGaLocation":464},{"text":649,"config":660},{"dataGaName":651,"dataGaLocation":464,"id":652,"isOneTrustButton":93},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",{"featuredPost":666,"allPosts":693,"totalPages":887,"initialPosts":888},{"_path":667,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":668,"content":676,"config":686,"_id":689,"_type":16,"title":690,"_source":18,"_file":691,"_stem":692,"_extension":21},"/de-de/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"title":669,"description":670,"ogTitle":669,"ogDescription":670,"noIndex":6,"ogImage":671,"ogUrl":672,"ogSiteName":673,"ogType":674,"canonicalUrls":672,"schema":675},"So verwendest du die benutzerdefinierten Compliance Frameworks von GitLab in deiner DevSecOps-Umgebung","Erfahre, wie sich regulatorische Anforderungen durch neue Frameworks zusammen mit mehr als 50 standardmäßigen Kontrollen von lästigen Checklisten in integrierte, automatisierte Workflow-Komponenten verwandeln.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097104/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097104092.png","https://about.gitlab.com/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So verwendest du die benutzerdefinierten Compliance Frameworks von GitLab in deiner DevSecOps-Umgebung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-30\",\n      }",{"title":669,"description":670,"authors":677,"heroImage":671,"date":679,"body":680,"category":14,"tags":681},[678],"Fernando Diaz","2025-04-30","Compliance ist mehr als nur ein Kontrollkästchen, sondern vielmehr eine wichtige Unternehmensfunktion, die sich von betrieblichen Risiken bis hin zum Kundenvertrauen auf jeden Bereich auswirkt. Für Entwicklungsteams kann es sich besonders schwierig gestalten, die Compliance-Anforderungen mit einer angemessenen Geschwindigkeit in Einklang zu bringen. Die [benutzerdefinierten Compliance Frameworks (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/) von GitLab ermöglichen eine einfache und direkte Integration der Compliance-Verifizierung in deinen Entwicklungsworkflow. In diesem Artikel erfährst du, worum es sich dabei im Detail handelt und wie du sie so effizient wie möglich einsetzen kannst.\n\n## Was sind die benutzerdefinierten Compliance Frameworks von GitLab?\n\nMit den benutzerdefinierten Compliance Frameworks von GitLab können Unternehmen ihre Compliance-Standards direkt in ihrer GitLab-Instanz definieren, implementieren und durchsetzen. Diese Funktion erweitert die integrierten Compliance-Funktionen von GitLab und ermöglicht den Teams die Erstellung benutzerdefinierter Frameworks, die mit den konkreten gesetzlichen Anforderungen, internen Richtlinien oder Branchenstandards übereinstimmen.\n\nDie benutzerdefinierten Compliance Frameworks bieten folgende Vorteile:\n* Weniger manuelle Nachverfolgung  \n* Schnellere Bereitschaft für Audits  \n* Native Durchsetzung von Compliance-Kontrollen\n\n![Screenshot des Compliance Centers mit einer Liste der Frameworks](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097114254.png)\n\nIm Rahmen dieser Veröffentlichung werden über 50 standardmäßig verfügbare Kontrollen bereitgestellt (weitere folgen in Kürze), die auf die individuellen Compliance-Anforderungen deines Unternehmens zugeschnitten werden können, einschließlich HIPAA im Gesundheitswesen, DSGVO für den Datenschutz, SOC 2 für Dienstleistungsunternehmen oder branchenspezifische Vorschriften. Einige Beispiele für standardmäßig verfügbare Kontrollen sind unter anderem:\n\n* Aufgabentrennung (z. B. mindestens zwei genehmigende Personen und ein(e) Autor(in) für einen Merge Request)   \n* Ausführung von Sicherheitsscannern (z. B. [SAST (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/application_security/sast/) und [Abhängigkeitssuche (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/application_security/dependency_scanning/)  \n* Authentifizierung/Genehmigung (z. B. keine öffentliche Projektsichtbarkeit und AuthSSO erforderlich)  \n* Anwendungskonfiguration (z. B. Statusprüfungen und Terraform erforderlich)\n\nDarüber hinaus kannst du externe Umgebungskontrollen über die GitLab-API konfigurieren, um den Status und die Details einer externen Umgebung zu überprüfen.\n\n## Entwickeln eines benutzerdefinierten Compliance Frameworks von Grund auf\n\nNachdem wir nun den Wert verstanden haben, wollen wir uns im nächsten Schritt ansehen, wie du benutzerdefinierte Compliance Frameworks in deiner GitLab-Umgebung implementieren kannst. Wir verwenden dazu diese Demo-Anwendung. Du kannst den Details in diesem Video folgen. \n\n**Hinweis:** Dazu ist ein GitLab-Ultimate-Abonnement erforderlich.\n\n\u003C!-- TODO: EMBED_YT_VIDEO -->\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/bSwwv5XeMdQ?si=unDwCltF4vTHT4mB\" title=\"Adhering to compliance requirements with built-in compliance controls\n\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Schritt 1: Definiere deine Compliance-Anforderungen**\n\nBevor du dein benutzerdefiniertes Framework erstellst, musst du zunächst deine Compliance-Anforderungen klar definieren:\n\n1. **Identifiziere die geltenden Vorschriften:** Bestimme, welche Vorschriften und Standards für dein Unternehmen gelten (z. B. DSGVO, PCI DSS und HIPAA). \n2. **Ordne die Anforderungen den Kontrollen zu:** Unterteile jede Vorschrift in konkrete umsetzbare Kontrollen.  \n3. **Priorisiere die Anforderungen:** Konzentriere dich auf die Bereiche mit hohem Risiko sowie die Anforderungen mit der größten Wirkung.\n\n**Schritt 2: Entwickle dein benutzerdefiniertes Compliance Framework**\n\nSo entwickelst du ein benutzerdefiniertes Compliance Framework in GitLab:\n\n1. Navigiere in deiner GitLab-Gruppe zum Abschnitt **Sichern > Compliance Center**.  \n2. Klicke auf die Schaltfläche **Neues Framework**.  \n3. Wähle **Leeres Framework erstellen** aus.\n\n![Bildschirm zum Erstellen eines benutzerdefinierten Compliance Frameworks](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097114255.png)\n\n4. Gib einen Namen, eine Beschreibung und eine Farbe für dein Framework ein.\n\n![Bildschirm „Neues Compliance Framework“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097114257.png)\n\n5. Füge dem Framework eine Anforderung hinzu:  \n   a. Scrolle nach unten zum Tab **Anforderungen**.\n\n   b. Klicke auf die Schaltfläche **Neue Anforderung**.\n\n   c. Gib einen Namen und eine Beschreibung ein.\n   d. Wähle im Abschnitt **Kontrollen** **GitLab-Kontrolle auswählen** aus.  \n   e. Wähle eine Kontrolle aus der Liste aus (z. B. mindestens zwei Genehmigungen, SAST wird ausgeführt).  \n   f. Klicke auf die Schaltfläche **Anforderung erstellen**.\n\n![Schaltfläche „Neue Anforderung erstellen“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097114258.png)\n\n6. Klicke auf die Schaltfläche **Framework erstellen**.\n\nDas Framework wird wie angegeben erstellt und kann nun zu Projekten hinzugefügt werden. Darüber hinaus können Compliance Frameworks mit einem JSON mit dem entsprechenden Schema [importiert](http://TODO) werden.\n\n**Schritt 3: Wende das Framework auf Projekte an**\n\nSobald dein Framework erstellt wurde, gehst du wie folgt vor:\n1. Wähle im Compliance Center die Registerkarte **Projekte** aus.  \n2. **Suche** mit dem Suchfeld oder **filtere** die Ergebnisse.  \n3. Wähle die Projekte aus, auf die du dein Framework anwenden möchtest.  \n4. Klicke auf die Schaltfläche **Eine Massenaktion auswählen**.  \n5. Wähle **Frameworks auf ausgewählte Projekte anwenden** aus.  \n6. Klicke auf die Schaltfläche **Frameworks auswählen**.  \n7. Wähle deine Frameworks aus der Liste aus.  \n8. Klicke auf die Schaltfläche **Anwenden**.\n\n![Compliance-Center-Fenster mit Dropdown-Liste für das SOC-2-Framework](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097114260.png)\n\nDas Framework wird nun auf das Projekt angewendet, wodurch seine Anforderungen sichtbar und nachvollziehbar werden.\n\n**Schritt 4: Überwache die Compliance und erstelle dazu entsprechende Berichte**\n\nSobald dein Framework eingerichtet ist, kannst du Folgendes tun:\n\n1. Im **Compliance Center** kannst du den Compliance-Status über alle Projekte hinweg verfolgen, einschließlich Details und vorgeschlagener Korrekturen für fehlgeschlagene Kontrollen.\n2. Erstelle **Compliance-Berichte** für Audits und Stakeholder-Reviews.  \n3. Richte **Compliance-Alarme** ein, um die Stakeholder über mögliche Compliance-Probleme zu informieren. \n4. Überprüfe **Audit Events**, um einen Überblick über die Maßnahmen zu erhalten, die im Zusammenhang mit den Compliance-Einstellungen ergriffen wurden.\n\n![Bildschirm des Compliance Centers mit SOC-2-Test-Framework](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097114263.png)\n\n## Praxisbeispiel: Implementierung eines SOC 2 Compliance Frameworks\n\nSystem and Organization Controls 2, besser bekannt als SOC 2, ist ein strenger Prüfungsstandard, der vom American Institute of Certified Public Accountants entwickelt wurde und die Kontrollen eines Dienstleistungsunternehmens in Bezug auf seine Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und seinen Datenschutz evaluiert. Weitere Informationen findest du in meinem [Leitfaden zur Erfüllung der SOC-2-Sicherheitsanforderungen mit GitLab (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab/).\n\nSehen wir uns nun ein praktisches Beispiel für die Verwendung eines benutzerdefinierten Compliance Frameworks zur Überprüfung der SOC-2-Sicherheits-Compliance an, wo folgende Anforderungen gelten:\n\n* Implementierung von Kontrollen zum Schutz vor unbefugtem Zugriff  \n* Einrichtung von Verfahren zur Identifizierung und Minderung von Risiken  \n* Einrichtung von Systemen zur Erkennung von und zum Umgang mit sicherheitsrelevanten Vorfällen\n\n**Haftungsausschlussklausel:** Dies ist nur ein Beispiel, in dem einige der möglichen Kontrollen zur Einhaltung von SOC 2 aufgezeigt werden. Konsultiere dein Sicherheits-/Compliance-Team, bevor du eine Implementierung in die Produktion überführst.\n\nEin benutzerdefiniertes Compliance Framework für SOC 2 sieht bei Verwendung einiger standardmäßiger Kontrollen von GitLab wie folgt aus:\n\n* **Name:** SOC-2-Sicherheitsanforderungen  \n* **Beschreibung:** Ergänzt die Sicherheitsanforderungen für die Einhaltung des SOC-2-Frameworks \n* **Anforderungen:**  \n  * **Implementierung von Kontrollen zum Schutz vor unbefugtem Zugriff**  \n    * Aktivierung von Auth SSO\n    * Aktivierung des CI/CD-Job-Token-Bereichs\n    * MFA auf Organisationsebene erforderlich \n   * **Richte Verfahren zur Identifizierung und Minderung von Risiken ein**\n    * Mindestens zwei genehmigende Personen\n    * Autor(in) hat den Merge Request genehmigt \n    * Die Committer haben den Merge Request genehmigt  \n    * Standard-Branch ist geschützt  \n  * **Einrichtung von Systemen zur Erkennung von und zum Umgang mit sicherheitsrelevanten Vorfällen**  \n    * Abhängigkeitssuche wird ausgeführt    \n    * SAST wird ausgeführt  \n    * DAST wird ausgeführt\n\nWenn du dieses Framework auf dein(e) Projekt(e) anwendest, kannst du überwachen, ob und wann sie nicht mehr die Compliance-Kriterien erfüllen und was getan werden kann, damit die Erfüllung der Compliance-Kriterien wieder gewährleistet ist. Beachte, dass du mehrere Compliance Frameworks für Projekte erstellen und anwenden kannst. Du kannst zum Beispiel eines für die SOC-2-Anforderungen an die Prozessintegrität implementieren.\n\n## Implementiere Sicherheitsrichtlinien, um sicherzustellen, dass die Compliance-Anforderungen erfüllt werden\n\nObwohl dies nicht erforderlich ist, können Sicherheitsrichtlinien auf Projekte angewendet werden, die ein benutzerdefiniertes Compliance Framework enthalten. So kannst du sicherstellen, dass bestimmte Compliance-Kriterien über Sicherheitsrichtlinien durchgesetzt werden. Du kannst zum Beispiel erzwingen, dass Sicherheitsscanner für Projekte ausgeführt werden, die ein benutzerdefiniertes Compliance Framework enthalten, das einen solchen Sicherheitsscan erfordert. \n\nGitLab bietet verschiedene Sicherheitsrichtlinien (Dokumentation nur in englischer Sprache verfügbar):\n\n* [Scan-Ausführungsrichtlinie](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/): Erzwingt Sicherheitsscans, entweder als Teil der Pipeline oder nach einem festgelegten Zeitplan.  \n* [Merge-Request-Approvalrichtlinie](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/): Erzwingt Einstellungen auf Projektebene und Approvalregeln auf Basis der Ergebnisse des Scans.  \n* [Pipeline-Ausführungsrichtlinie](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/): Erzwingt CI/CD-Jobs als Teil von Projekt-Pipelines. \n* [Richtlinie zum Sicherheitslückenmanagement](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/): Behebt automatisch Sicherheitslücken, die im Standard-Branch nicht mehr erkannt werden.\n\nWir wollen nun die Ausführung eines SAST-Scanners erzwingen, um automatisch alle Anforderungen zu erfüllen, die einen SAST-Scan erfordern. So erstellst du eine Sicherheitsrichtlinie und wendest sie auf ein Projekt mit einem bestimmten Framework an:\n\n1. Navigiere zu einem Projekt mit einem benutzerdefinierten Compliance Framework, das einen **SAST-Scan** erfordert. \n2. Wähle in der Seitenleiste **Sichern > Richtlinien** aus.  \n3. Klicke auf die Schaltfläche **Neue Richtlinie**.  \n4. Klicke unter **Scan-Ausführungsrichtlinien** auf die Schaltfläche **Richtlinie auswählen**. \n5. Gib den **Namen** und die **Beschreibung** ein. \n6. Wähle unter **Aktionen** **SAST** als auszuführenden Scan aus.\n\n![Aktionsbildschirm](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097114264.png)\n\n7. Wähle unter **Bedingungen** die Pipeline aus, die ausgelöst werden soll, wenn eine Pipeline für alle Branches ausgeführt wird.\n\n![Bildschirm „Bedingungen“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097114265.png)\n\n8. Klicke auf die Schaltfläche **Mit einem Merge Request konfigurieren**.  \n9. In einem separaten Projekt wird nun ein MR erstellt, der alle Sicherheitsrichtlinien enthält, die für dieses Projekt gelten.\n10. Klicke auf die Schaltfläche **Zusammenführen**.\n\nJetzt wird SAST für jeden Branch ausgeführt, um sicherzustellen, dass du im jeweiligen Bereich die Compliance-Anforderungen erfüllst. Überprüfe unbedingt die verschiedenen Sicherheitsrichtlinien, um im Detail zu erfahren, wie sie zu deinen Anforderungen passen.\n\n## 5 Best Practices, die du beachten solltest \n\nSo maximierst du den Wert benutzerdefinierter Compliance Frameworks:\n\n1. **Fang klein an:** Beginne mit einer kritischen Vorschrift oder einem Standard, bevor du sukzessive erweiterst.  \n2. **Beteilige die wichtigsten Stakeholder:** Beziehe die Compliance-, Sicherheits- und Entwicklungsteams in die Erstellung des Frameworks ein.  \n3. **Automatisiere, wo möglich:** Verwende GitLab CI/CD, um Compliance-Überprüfungen zu automatisieren.  \n4. **Sorge für eine gründliche Dokumentation:** Pflege eine klare Dokumentation darüber, wie dein Framework den gesetzlichen Anforderungen entspricht.  \n5. **Regelmäßige Überprüfungen:** Aktualisiere deine Frameworks, wenn sich die Vorschriften ändern oder neue Anforderungen entstehen.\n\n## Leg noch heute los\n\nDie benutzerdefinierten Compliance Frameworks von GitLab sind ein bedeutender Fortschritt im DevSecOps-Bereich, da mit ihnen die Compliance direkt in den Entwicklungsworkflow integriert wird. Durch die Implementierung benutzerdefinierter Frameworks können Unternehmen ihren Compliance-Aufwand reduzieren, ihr Risikomanagement verbessern und die Entwicklungszyklen beschleunigen, während sie gleichzeitig beständig die gesetzlichen Anforderungen erfüllen.\n\nDurch die Möglichkeit, benutzerdefinierte Compliance Frameworks zu definieren und durchzusetzen, erhalten die Teams die Flexibilität, die sie benötigen, um die Anforderungen ihrer konkreten regulatorischen Landschaft zu erfüllen. Gleichzeitig erhalten sie so die notwendige Struktur, um einheitliche Compliance-Praktiken im gesamten Unternehmen sicherzustellen.\n\nDa die regulatorischen Anforderungen immer komplexer werden, werden Tools wie die benutzerdefinierten Compliance Frameworks von GitLab für Unternehmen, mit denen die umfassenden Compliance-Anforderungen und eine zielführende Entwicklungsgeschwindigkeit auf nachhaltige Weise in Einklang gebracht werden sollen, immer wichtiger.\n\n> Melde dich für deine [kostenlose 60-tägige Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/) an, um die benutzerdefinierten Compliance Frameworks noch heute auszuprobieren.\n\n## Mehr erfahren \n\nIn diesen Ressourcen erfährst du mehr über benutzerdefinierte Compliance Frameworks und ihre Vorteile für dein Unternehmen:\n\n* [Dokumentation zu benutzerdefinierten Compliance Frameworks (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/compliance/compliance_center/compliance_status_report/)   \n* [Epic zu benutzerdefinierten Compliance Frameworks](https://gitlab.com/groups/gitlab-org/-/epics/13295)   \n* [Dokumentation der Sicherheitsrichtlinien (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/application_security/policies/)  \n* [Sicherheits- und Compliance-Lösungen von GitLab](https://about.gitlab.com/de-de/solutions/security-compliance/)",[14,682,683,684,685],"tutorial","DevSecOps platform","features","product",{"slug":687,"featured":93,"template":688},"how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","BlogPost","content:de-de:blog:how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","How To Use Gitlabs Custom Compliance Frameworks In Your Devsecops","de-de/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","de-de/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",[694,716,737,757,778,800,824,844,864],{"_path":695,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":696,"content":702,"config":710,"_id":712,"_type":16,"title":713,"_source":18,"_file":714,"_stem":715,"_extension":21},"/de-de/blog/enhance-application-security-with-gitlab-hackerone",{"title":697,"description":698,"ogTitle":697,"ogDescription":698,"noIndex":6,"ogImage":699,"ogUrl":700,"ogSiteName":673,"ogType":674,"canonicalUrls":700,"schema":701},"Bessere Anwendungssicherheit mit GitLab und HackerOne","Erfahre mehr über die Zusammenarbeit zwischen GitLab und HackerOne und lerne, wie du eine Integration implementierst, die die Sicherheit der Anwendungen in deinem Unternehmen verbessert.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097503/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2810%29_5ET24Q6i8ihqrAOkge7a1R_1750097503214.png","https://about.gitlab.com/blog/enhance-application-security-with-gitlab-hackerone","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Bessere Anwendungssicherheit mit GitLab und HackerOne\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-03\",\n      }",{"title":697,"description":698,"authors":703,"heroImage":699,"date":704,"body":705,"category":14,"tags":706,"updatedDate":709},[678],"2025-04-03","Sicherheit darf im Entwicklungsprozess nicht länger eine Nebensache sein. Unternehmen benötigen robuste Lösungen, mit denen die Sicherheit in den gesamten Software-Entwicklungsprozess integriert wird. Hier kommt die Zusammenarbeit zwischen HackerOne und GitLab ins Spiel, denn sie bietet eine praktische Kombination für moderne Anwendungsentwicklungsteams.\n\n[GitLab](https://about.gitlab.com/de-de/), die umfassende, KI-basierte DevSecOps-Plattform, und HackerOne, die führende Crowd-Sicherheitsplattform, sind eine Partnerschaft eingegangen, die das Beste aus beiden Welten vereint: den optimierten DevSecOps-Workflow von GitLab und die leistungsstarke Sicherheitslückenverwaltung von HackerOne.\n\nIn diesem Tutorial erfährst du, wie du die Produktivität der Entwickler(innen) und deine Sicherheitslage verbessern kannst, indem du die GitLab-Integration von HackerOne implementierst.\n\n## Eine Integration, die Entwickler(innen) befähigt\n\nDie GitLab-Integration von HackerOne ist bemerkenswert einfach und dennoch leistungsstark. Wenn Sicherheitsexpert(inn)en Sicherheitslücken über die Plattform von HackerOne entdecken, werden diese Erkenntnisse automatisch in GitLab-Tickets umgewandelt. Dadurch entsteht ein nahtloser Workflow, der folgendermaßen abläuft:\n\n* Sicherheitsexpert(inn)en identifizieren Sicherheitslücken über die Plattform von HackerOne.\n* Validierte Sicherheitslücken werden automatisch in GitLab-Tickets umgewandelt.\n* Entwicklungsteams können diese Tickets direkt in ihren bestehenden Workflows bearbeiten.\n* Der Lösungsstatus wird zwischen beiden Plattformen synchronisiert.\n\nDu kannst die Vorteile von GitLab und HackerOne nutzen, indem du die [Integration](https://docs.hackerone.com/en/articles/8571227-gitlab-integration) verwendest und GitLab-Tickets als Referenzen auf HackerOne nachverfolgst. Diese Integration bietet eine bidirektionale und nahtlose Datensynchronisierung zwischen deinem HackerOne-Bericht und dem GitLab-Ticket, wodurch die Abstimmung zwischen Entwicklungs- und Sicherheitsteams verbessert und die Behebung von Sicherheitslücken optimiert wird.\n\nFolge den Anweisungen in der [GitLab-Integrationsdokumentation von HackerOne](https://docs.hackerone.com/en/articles/10394699-gitlab-setup), um die GitLab-Integration so zu konfigurieren, dass sie Informationen zwischen deinem HackerOne-Bericht und deinem GitLab-Ticket synchronisiert. Dies umfasst folgende Schritte:\n\n1. [Einrichtung einer OAuth-2.0-Anwendung](https://docs.gitlab.com/ee/integration/oauth_provider.html) für deine GitLab-Instanz mit den bereitgestellten HackerOne-Einstellungen\n2. Verbindung von HackerOne zum neu erstellten OAuth 2.0 auf GitLab\n3. Berechtigung von HackerOne, auf die GitLab-API zuzugreifen\n4. Festlegung des GitLab-Projekts, das du zu HackerOne-Berichten eskalieren möchtest\n5. Auswahl der HackerOne-Felder, die den entsprechenden GitLab-Feldern zugeordnet werden sollen\n6. Ereigniskonfiguration für GitLab zu HackerOne und umgekehrt\n\nSobald die Integration eingerichtet wurde, kannst du Daten bidirektional und nahtlos zwischen GitLab und HackerOne synchronisieren. Dies vereinfacht den Kontextwechsel und ermöglicht es, Sicherheitslücken einfach in beiden Systemen nachzuverfolgen. Die Integration bietet die folgenden Funktionen:\n\n* **Erstellen eines GitLab-Tickets aus HackerOne:** Du kannst neue GitLab-Tickets für Berichte erstellen, die du auf HackerOne erhältst.  \n* **Verknüpfung von HackerOne-Berichten mit bestehenden GitLab-Aufgaben.**   \n* **Synchronisierung von Updates von HackerOne zu GitLab:** Die folgenden Updates eines Berichts werden als Kommentar zu GitLab synchronisiert.\n  * Berichtskommentare  \n  * Staatusänderungen  \n  * Belohnungen  \n  * Änderungen der zuständigen Person  \n  * Öffentlichmachung  \n  * Schließen von GitLab-Tickets  \n* **Synchronisierung von Updates von GitLab zu HackerOne:** Die folgenden Updates in GitLab werden in HackerOne als interner Kommentar zum jeweiligen Bericht angezeigt:  \n  * Kommentare  \n  * Statusänderungen  \n* **Zuordnung von HackerOne-Schweregraden zu GitLab-Labels**: Dadurch kannst du eine benutzerdefinierte Priorität festlegen, wenn du einen Bericht zu GitLab eskalierst.  \n* **Zuordnung von Fälligkeitsdaten:** Damit kannst du basierend auf dem Schweregrad eines Berichts automatisch ein benutzerdefiniertes Fälligkeitsdatum festlegen.\n\n![GitLab und HackerOne fügen Kommentare hinzu oder ändern den Status des Berichts in GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/sync_aHR0cHM6_1750097509644.png)\n\nDiese Funktionen vereinfachen die Abstimmung zwischen Entwicklungs- und Sicherheitsteams und optimieren die Behebung von Sicherheitslücken. Weitere Informationen zur Funktionsweise der Integration findest du in der [Integrationsdokumentation](https://docs.hackerone.com/en/articles/8571227-gitlab-integration).\n\n## Ein Blick in die Bug-Bounty-Programme von HackerOne\n\nHackerOne bietet Bug-Bounty-Programme oder Cybersicherheitsinitiativen an, bei denen man Belohnungen bekommt, wenn Sicherheitslücken in den Softwaresystemen, Websites oder Anwendungen von Kund(inn)en entdeckt und gemeldet werden. Bug-Bounty-Programme tragen auf folgende Weise zur Sicherheit einer Anwendung bei:\n\n* Sie helfen, Sicherheitsschwachstellen zu identifizieren, bevor diese missbraucht werden können.\n* Sie ermöglichen es, die vielfältige Expertise einer weltweiten Community aus Sicherheitsexpert(inn)en zu nutzen.\n* Sie sind eine kostengünstige Möglichkeit, die Cybersicherheit zu verbessern.\n* Sie ergänzen interne Sicherheitsmaßnahmen und traditionelle Penetrationstests.\n\nGitLab nutzt das Bug-Bounty-Programm von HackerOne und ermöglicht es Sicherheitsexpert(inn)en, Sicherheitslücken in den Anwendungen oder der Infrastruktur von GitLab zu melden. Dieser Crowdsourcing-Ansatz hilft GitLab, potenzielle Sicherheitsprobleme effektiver zu erkennen und zu beheben.\n\n![Bug-Bounty-Seite für GitLab auf HackerOne](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/hackerone_gitlab_bug_bounty_page_aHR0cHM6_1750097509645.png)\n\nIndem Unternehmen die Plattform und die globale Hacker(innen)-Community von HackerOne nutzen, können sie ihre Sicherheitslage deutlich verbessern, Sicherheitslücken schneller erkennen und potenziellen Bedrohungen immer einen Schritt voraus sein.\n\n## Sichere deine Anwendungen und verbessere die Effizienz mit GitLab\n\nGitLab ist eine umfassende DevSecOps-Plattform mit Funktionen für den gesamten Software-Entwicklungsprozess und enthält unter anderem auch Sicherheits- und Compliance-Tools. GitLab unterstützt die folgenden Arten von Sicherheitsscannern:\n- Statische Anwendungssicherheitstests (SAST)\n- Dynamische Anwendungssicherheitstests (DAST)\n- Container-Scanning\n- Abhängigkeitssuche\n- Infrastructure-as-Code-Scanning\n- Abdeckungsgesteuertes Fuzzing\n- Web-API-Fuzzing\n\nMit GitLab kannst du Sicherheitsscans hinzufügen, indem du einfach eine Vorlage auf deine CI/CD-Pipeline-Definitionsdatei anwendest. Ein SAST kann beispielsweise mit einigen wenigen Zeilen Code in der Datei `.gitlab-ci.yml` hinzugefügt werden:\n\n```yaml\nstage:\n  - test\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\nDadurch wird der SAST in der Testphase ausgeführt und es werden [automatisch die verwendeten Sprachen in deiner Anwendung erkannt](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks). Wenn du dann einen Merge Request erstellst, erkennt der SAST Sicherheitslücken im diff zwischen dem Feature-Branch und dem Zielbranch und stellt relevante Daten für die einzelnen Sicherheitslücken bereit, damit diese behoben werden können.\n\n![NoSQL-Injection-Sicherheitslücke im MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750097509647.png)\n\nDie Ergebnisse des SAST-Scanners können das Zusammenführen von Code blockieren, wenn Sicherheitsrichtlinien eingehalten werden müssen. Native GitLab-Benutzer(innen) können als Genehmiger(innen) festgelegt werden, sodass die erforderlichen Überprüfungen vor dem Zusammenführen von unsicherem Code durchgeführt werden müssen. Dadurch wird sichergestellt, dass alle Sicherheitslücken von den zuständigen Personen überwacht werden.\n\n![Genehmigungsrichtlinie für Merge Requests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750097509649.png)\n\nHackerOne hat GitLab auf verschiedene wichtige Arten in seine Betriebs- und Entwicklungsprozesse integriert, was zu Verbesserungen des Entwicklungsprozesses und einer verbesserten Skalierbarkeit und Zusammenarbeit geführt hat. Zu diesen Verbesserungen gehören schnellere Bereitstellungen und teamübergreifende Planung.\n\n## Hauptvorteile der GitLab-Integration von HackerOne\n\nWerden HackerOne und GitLab zusammen genutzt, erwarten dich folgende Hauptvorteile:\n\n* **Verbesserte Transparenz bei der Sicherheit:** Entwicklungsteams erhalten sofortige Einblicke in Sicherheitslücken, ohne ihre primäre Workflow-Umgebung verlassen zu müssen. Durch diese Erkenntnisse in Echtzeit können Teams Sicherheitsprobleme priorisieren und trotzdem die Entwicklung von Funktionen vorantreiben.\n* **Optimierter Prozess zur Fehlerbehebung:** Indem HackerOne-Berichte direkt in GitLab-Tickets umgewandelt werden, wird die Fehlerbehebung Teil des Standardentwicklungszyklus. Dadurch entfällt der Kontextwechsel zwischen Plattformen und Sicherheitsfixes werden zusammen mit anderen Entwicklungsarbeiten nachverfolgt.  \n* **Raschere Fehlerbehebung:** Die Integration verkürzt die Zeit zwischen der Entdeckung und der Behebung von Sicherheitslücken erheblich. Da HackerOne-Beiträge sofort in GitLab verfügbar sind, können Entwicklungsteams ohne Verzögerung mit der Behebung der Fehler beginnen und so die allgemeine Sicherheitslage verbessern.\n***Verbesserte Zusammenarbeit:** Sicherheitsexpert(inn)en, Sicherheitsteams und Entwickler(innen) können durch diese Integration effektiver kommunizieren. Kommentare und Aktualisierungen werden zwischen beiden Plattformen synchronisiert, wodurch eine kollaborative Umgebung entsteht, bei der die Verbesserung der Sicherheit im Vordergrund steht.\n* **Praktische Auswirkungen:** Unternehmen, die die Integration von HackerOne und GitLab implementiert haben, berichten von folgenden Vorteilen:  \n  * Bis zu 70 % kürzere Zeit von der Entdeckung bis zur Behebung von Sicherheitslücken\n  * Höhere Zufriedenheit der Entwickler(innen), da sie in ihrem bevorzugten Workflow bleiben können\n  * Verbesserte Transparenz hinsichtlich der Sicherheit im gesamten Unternehmen  \n  * Effektivere Zuweisung von Sicherheitsressourcen\n\n> Sieh dir jetzt die [Seite zur Einrichtung der Integration](https://docs.hackerone.com/en/articles/10394699-gitlab-setup) an, um sofort loszulegen.\n\n## Mehr erfahren\n\nWeitere Informationen zu GitLab und HackerOne sowie darüber, wie du deine Sicherheitslage verbessern kannst, findest du in den folgenden Ressourcen:\n* [Nutzung der GitLab-Integration von HackerOne (nur in englischer Sprache verfügbar)](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)  \n* [Bug-Bounty-Programm von GitLab in Zusammenarbeit mit HackerOne (nur in englischer Sprache verfügbar)](https://hackerone.com/gitlab?type=team)\n* [Sicherheits- und Compliance-Lösungen von GitLab](https://about.gitlab.com/de-de/solutions/security-compliance/)  \n* [HackerOne erreicht 5 x schnellere Implementierungen dank der integrierten Sicherheit von GitLab](https://about.gitlab.com/de-de/customers/hackerone/)  \n* [Dokumentation zur Anwendungssicherheit von GitLab](https://docs.gitlab.com/ee/user/application_security/)  \n",[14,682,235,286,683,707,708],"DevSecOps","bug bounty","2025-05-12",{"slug":711,"featured":6,"template":688},"enhance-application-security-with-gitlab-hackerone","content:de-de:blog:enhance-application-security-with-gitlab-hackerone.yml","Enhance Application Security With Gitlab Hackerone","de-de/blog/enhance-application-security-with-gitlab-hackerone.yml","de-de/blog/enhance-application-security-with-gitlab-hackerone",{"_path":717,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":718,"content":724,"config":731,"_id":733,"_type":16,"title":734,"_source":18,"_file":735,"_stem":736,"_extension":21},"/de-de/blog/self-hosting-vs-cloud",{"title":719,"description":720,"ogTitle":719,"ogDescription":720,"noIndex":6,"ogImage":721,"ogUrl":722,"ogSiteName":673,"ogType":674,"canonicalUrls":722,"schema":723},"Was du über Self-Hosting & Cloud-Hosting wissen solltest ","Self-Hosting oder Cloud? Wir zeigen dir, welche Vorteile und Nachteile diese Modell haben - und was für eine Rolle GitLab dabei spielt.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664270/Blog/Hero%20Images/AdobeStock_276584891.jpg","https://about.gitlab.com/blog/self hosting vs cloud","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was du über Self-Hosting & Cloud-Hosting wissen solltest \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2025-02-27\",\n      }",{"title":719,"description":720,"authors":725,"heroImage":721,"date":727,"body":728,"category":14,"tags":729},[726],"GitLab Germany Team","2025-02-27","# Was du über Self-Hosting und Cloud-Hosting wissen solltest\n\n„Stets online zu sein ist kein Luxus - es ist in dieser schnelllebigen Zeit eine Notwendigkeit.” Dieses anonyme Zitat bringt die Bedeutung einer sicheren, stabilen und rundum überzeugenden Web-Präsenz auf den Punkt: Mit deiner Website gewinnst und hältst du Kund(inn)en, informierst Interessierte und eröffnest ihnen Kontaktmöglichkeiten, bietest Downloads und Dienstleistungen, oder physische Produkte an. \n\nDamit wird zugleich die hohe Bedeutung des passenden Webhostings klar: Einerseits sollten deine Daten stets für Befugte zugänglich sein, andererseits müssen sie vor unerwünschten Zugriffen und Angriffen geschützt bleiben. Mit der Entscheidung des für dich richtigen Hosting-Pakets stellst du die Weichen auf Erfolg und unterstützt dein Unternehmen langfristig in seiner digitalen Strategie.\n\nDie Bedeutung des Hostings geht sogar noch über das Bereitstellen von Websites hinaus. Auch für DevOps-Teams ist die Entscheidung darüber, wie und wo welche Daten gehostet werden sollen, alles andere als eine Formalität und sollte niemals ausschließlich aufgrund der Kosten getroffen werden.\n\nStehst du gerade vor der Frage, welches Hosting für dich die beste Wahl ist? Dann lies weiter. Denn in diesem Artikel stellen wir dir die drei grundlegenden Hosting-Modelle vor und erklären dir die jeweiligen Vor- und Nachteile. Einiges davon könnte dich überraschen.\n\n## Welcher Zusammenhang besteht zwischen Webhosting und DevOps?\n\nDevOps wird eher selten im Zusammenhang mit Hosting diskutiert. Dabei besteht zwischen den beiden ein sehr enger Bezug, unabhängig davon, ob du dich für ein Self-Hosting-Modell oder Cloud-Hosting entscheidest.\n\nBeim Hosting werden Anwendungen und Inhalte auf einem Server abgelegt und kontrolliert verfügbar gemacht. Ein wichtiger Aspekt von DevOps besteht in der Automatisierung des Deployments von Informationen und Inhalten für deine Website, die auf dem Server gehostet wird. \nIn der Entwicklungspraxis werden die Anwendungen, an denen ein DevOps-Team arbeitet, auf einem gemeinsam genutzten Server gehostet. Nur, wenn das Hosting optimal funktioniert, kann DevOps optimal funktionieren.\n\nIn großen Projekten sind die Verflechtungen oftmals sogar noch enger. So stellen manche Hosting-Dienstleister in ihrem Paket Anwendungen zur Verfügung, mit denen der DevOps-Prozess skaliert und möglichst harmonisch gestaltet werden kann. So greifen die beiden Bereiche ineinander. \nWenn DevOps ein zentrales Element deiner Arbeit darstellt, empfehlen wir dir deshalb, dich intensiv mit dem Thema Hosting auseinanderzusetzen. \n\n## Was muss gutes Webhosting leisten?\n\nDer Begriff Hosting beinhaltet das Speichern und Bereitstellen von Daten über einen Server. Nutzer(innen) greifen auf die Daten zu, die auf dem Server abgelegt sind, können Bestellungen aufgeben oder über ein Kontaktformular Anfragen schicken. \nWas macht gutes Webhosting aus? \n\nAlle Seiten und Anwendungen sollten schnell abrufbar sein, fehlerfrei bleiben und rund um die Uhr zur Verfügung stehen. Die Privatsphäre der Anwender(innen) muss ebenso gewährleistet werden wie die Integrität deiner Unternehmensdaten. Eventuelle Ausfälle werden umgehend beseitigt und das System stets auf dem technisch aktuellen sowie erforderlichen Stand gehalten. \nKurz gesagt: Das zentrale Ziel sollte darin bestehen, dass die User-Experience flüssig, nahtlos und stabil ist. Das richtige Hosting garantiert diese Qualität und passt sie kontinuierlich an aktuelle Gegebenheiten und Forderungen an. \nUm das für dich richtige Hosting zu ermitteln, stellt sich zuerst eine allgemeine Frage: \n\n## Welche Hosting-Optionen stehen mir zur Verfügung?\n\nGrundsätzlich gliedert sich Hosting in drei Varianten auf: Das Self-Hosting, Hosting in der Cloud und die Private Cloud. Wenn du selbst das Hosting übernimmst, bedeutet das, dass du in deinem Unternehmen einen oder mehrere Server einrichtest und deine Websites über diese laufen lässt. Da ein Server zunächst einmal nichts anderes ist als ein regulärer Computer und dir eine Vielzahl bewährter Softwarelösungen für den Betrieb eines Servers zur Verfügung stehen, mutet Self-Hosting (beziehungsweise „On-Premise-Hosting”) nicht übermäßig komplex an. Im nächsten Abschnitt stellen wir diese Vermutung auf den Prüfstand.\n\nDas Gegenmodell zum Self-Hosting-Modell ist das Cloud-Hosting. Die Cloud, in der deine Daten eingebettet werden, ist dabei schlicht eine Server-Architektur, die von externen Anbieter(innen) bereitgestellt wird. Diese speichern die Daten ab, stellen sämtliche erforderliche Software zur Verfügung und sorgen für einen reibungslosen Ablauf. In den frühen Jahren litten Cloud-Lösungen bei vielen Entscheidungsträger(inne)n unter einem Vertrauensdefizit. Doch haben sie in den letzten Jahren zunehmend an Beliebtheit gewonnen und stellen heute den De-Facto-Standard dar. Die Gründe dafür erklären wir dir ein wenig später in diesem Artikel.\n\nDa sowohl Self-Hosting als auch Cloud-Hosting jeweils ganz bestimmte Vorteile haben, welche die andere Lösung nicht anbieten kann, ist in den letzten Jahren verstärkt der Ruf nach einer Art Fusion der beiden Ansätze lauter geworden. Das Private-Cloud-Hosting stellt den Versuch eines Ausgleichs und einer Harmonisierung der jeweiligen Vor- und Nachteile beider Hosting-Modelle dar. Das gelingt in der Regel auch sehr gut, ist aber mit entsprechend hohen Kosten verbunden.\nFalls du GitLab nutzt, besteht sogar noch eine weitere Option:\n\n## Du kannst auch direkt über GitLab hosten!\n\nWenn du bereits für deine [CI/CD-Pipeline](https://about.gitlab.com/topics/ci-cd/cicd-pipeline/) mit GitLab arbeitest, ist das Hosten über GitLab für viele Projekte die optimale Variante. Wie wir oben erwähnt haben, ist eine flüssige, nahtlose und stabile User-Experience das oberste Ziel beim Hosting. Gleiches gilt selbstverständlich auch für die Entwicklungsarbeit. Je weniger Zwischenschritte erforderlich sind, um deine Webseite aus dem Entwicklungsstadium heraus öffentlich zu machen, umso geringer das Fehlerpotential und umso effizienter der Prozess als Ganzes.\n\nAus diesem Grund entscheiden sich viele DevOps-Teams, ihre Websites direkt aus dem Repository heraus zu veröffentlichen. Dabei übernimmt GitLab die gesamte Verwaltung der Daten und viele der beim Hosting anfallenden Aufgaben. Und da wir auf das Thema Sicherheit besonders großen Wert legen, kannst du dich darauf verlassen, dass deine Daten in guten Händen sind.\nAllerdings beschränkt sich die [Hosting-Funktionalität](https://about.gitlab.com/blog/gitlab-pages-setup/) von GitLab auf statische Seiten. Wenn du damit an einem dynamischen Projekt arbeitest, lies weiter, um zu erfahren, worauf du bei der Auswahl Wert legen solltest. \n\n## Welche Kriterien gilt es beim Hosting zu beachten?\n\nHosting ist ein recht einfaches Konzept, doch in seinen Details durchaus komplex. So gibt es eine Vielzahl an Kriterien, die es bei der Auswahl des für dich passenden Modells zu beachten gilt:\n\n- __Kosten:__ Hosting erfordert den Einsatz hochwertiger Hardware und Software sowie geschulten Personals. Je höher und individueller deine Ansprüche, umso höher die Kosten. Je mehr Daten du auf dem Server zu speichern beabsichtigst und je mehr Nutzer(innen) voraussichtlich auf diese Daten zugreifen, umso höher sind die Ansprüche an die Übertragungsleistung - und folglich umso höher auch die Ansprüche an das Hosting.\n\n- __Skalierbarkeit:__ Wenn sich deine Bedürfnisse an die Serverleistung ändern, ist es stets von Vorteil, schnell Anpassungen vornehmen zu können. Je höher die Skalierbarkeit einer Hosting-Lösung, umso besser.\n- \n- __Sicherheit:__ Deine Daten sind dein Kapital. Sie sind aber auch deine Verantwortung und in vielen Fällen an sehr genaue gesetzliche Vorgaben gebunden. Aus diesem Grund genießt die Wahrung der Integrität und Zugriffssicherung persönlicher Informationen, sowie der Informationen all derer, die auf sie zugreifen, höchste Priorität.\nde- __Aktualisierbarkeit:__ Hosting ist eine hochtechnologische Dienstleistung in einem sich rapide wandelnden Umfeld. Nur, wenn du deine Server stets auf dem aktuellen Stand hältst, kannst du die bestmögliche Umsetzung der anderen Kriterien gewährleisten. \n\n- __Flexibilität:__ Es gibt inzwischen eine Vielzahl standardisierter Anwendungen für die unterschiedlichsten Aspekte des Hostings. Das senkt Kosten, kann aber zu Konflikten mit deinen persönlichen Bedürfnissen und Ansprüchen führen. Individuelle Programme und Konfigurationen bieten oftmals mehr Flexibilität. \n\n- __Implementierbarkeit:__ Zwischen Entscheidungsfindung und -Umsetzung können oftmals längere Pausen entstehen. Je schneller dieser Prozess abläuft, desto besser.\nBenutzerfreundlichkeit: Gerade was den täglichen Betrieb angeht, gibt es bei der Wahl des Hosting-Modells erhebliche Unterschiede. Ein Server, dessen Betrieb, Wartung und Aktualisierung intuitiv abläuft, reduziert deinen Aufwand.\n\nJe nachdem, wo deine Ansprüche liegen, wird sich eines der folgenden Modelle für dich als besser geeignet erweisen. Sehen wir uns die jeweiligen Vor- und Nachteile genauer an. \n\n## On-Premise-Hosting/Self-Hosting: Vorteile\n\nViele Jahre lang waren die beiden Begriffe Hosting und Self-Hosting synonym. In den ersten zwei Jahrzehnten des Internets erschien die Vorstellung einer Auslagerung der eigenen Homepage alleine schon aufgrund niedriger Datenübertragungsraten geradezu utopisch. Inzwischen hat sich das Blatt gewendet. Sogar erfahrene Hoster und IT-Experten halten Cloud-Lösungen in den meisten Fällen für die geeignetere Wahl. Dennoch gibt es bis heute unbestreitbare Vorteile des Self-Hostings, die einen genaueren Blick rechtfertigen.\n\nDie große Stärke eines Self-Hosting-Modells besteht ganz offensichtlich darin, dass alle deine Daten bei dir liegen. Du hast also direkten Zugriff und behältst jederzeit die Kontrolle über sie. Darüber hinaus kannst du die Hard- und Software optimal an deine persönlichen Bedürfnisse anpassen. \n\nSelf-Hosting bietet außerdem gewisse Sicherheitsvorteile. Es besteht beispielsweise ein weitaus geringeres Risiko, dass sich Mitarbeiter(innen) einer externen Firma Zugriff auf deine Daten verschaffen. Da du selbst die Sicherheitsmaßnahmen definierst, kannst du die Messlatte sehr hoch ansetzen, um Missbrauch auszuschließen.\nVor allem ist es auf deinen eigenen Servern möglich, für extrem sensible Daten die Einhaltung gesetzlicher Standards zu sichern, die möglicherweise in der Cloud nicht garantiert werden können. \n## On-Premise-Hosting/Self-Hosting: Nachteile\n\nDie Anfänge des Internets waren eine Pionierzeit. Die extrem hohen Anforderungen, die Self-Hosting an das technische Knowhow der Beteiligten stellte, boten gleichzeitig eine großartige Chance, zu lernen und das eigene IT-Verständnis zu verbessern. \nDieser Aspekt hat inzwischen deutlich an Relevanz eingebüßt. Webhosting stellt schlicht eine Infrastruktur zur Verfügung und die meisten Aufgaben werden automatisch von spezialisierten Anwendungen übernommen. \n\nGleichzeitig verlangt der rapide technische Wandel die regelmäßige Durchführung von Updates in sehr kurzen Abständen. Auch müssen Ausfälle unmittelbar und schnell behoben werden. Der Sicherheitsvorsprung des Self-Hosting kann sich nur dann entfalten, wenn du dir ein tiefes Wissen über die besten Lösungen und die geforderten Standards aneignest. All dies überfordert die meisten mittelständischen Unternehmen oder zwingt sie zu hohen Investitionen in Personal und Infrastruktur.Die zunehmende Dominanz des Cloud-Hosting ist darauf zurückzuführen, dass es in einigen essentiellen Punkten deutliche Vorteile gegenüber dem On-Premise-Ansatz aufweist. Sehen wir uns diese genauer an.\n\n## Cloud-Hosting: Vorteile\n\n### Was ist Cloud-Hosting?\n\nBeim Cloud-Hosting  übernimmt der Dienstleistungsanbieter die Investitionen in die Hard- und Software. Das bedeutet, dass der sehr hohe Kapitalaufwand, der beim Self-Hosting unweigerlich entsteht, sich auf mehrere Kunden verteilt. Auch verfügen diese Betriebe über Personal, welches speziell auf die Herausforderungen des Hostings geschult ist und sich dem Thema, und somit ganz konkret deinen Daten, 24 Stunden am Tag widmen kann. Updates werden routinemäßig durchgeführt, Ausfälle (in der Regel) sofort erkannt und so schnell wie möglich behoben. Und all das zu deutlich geringeren Kosten als beim Self-Hosting. \n\nGerade im Hinblick auf das wichtige Thema Skalierbarkeit ist Cloud-Hosting das Optimum. Du benötigst kurzfristig oder auch nur vorübergehend mehr Speicherplatz, weil du große Mediendateien auf dem Server unterbringen willst? Statt dir, wie beim Self-Hosting erforderlich, zusätzlichen physischen Speicherplatz anzuschaffen, kannst du in der Cloud dein Paket bequem erweitern. Das ist im Allgemeinen sogar für saisonale und vorübergehende Peaks möglich. So könntest du bei Bedarf die Ressourcennutzung wenige Monate lang erhöhen und anschließend wieder auf das ursprüngliche Niveau herunterfahren.\n\nIm direkten Vergleich von Self-Hosting vs Cloud-Hosting bietet das Cloud-Hosting somit mehr Flexibilität und Freiraum für schnelle Änderungen. Darüber hinaus besteht eine sehr natürliche Verbindung zu DevOps und [DevSecOps](https://about.gitlab.com/de-de/topics/devsecops/). \n\n## Cloud-Hosting: Nachteile\n\nGanz ohne Nachteile kommt selbstverständlich auch das Cloud-Hosting nicht aus. Gegenüber dem On-Premise-Modell ist die Cloud meist weniger flexibel im Hinblick auf individuelle Lösungen. Die meisten seiner Vorzüge zieht dieses Konzept schließlich gerade daraus, dass es auf breiter Basis und für nahezu alle Anwender funktioniert. Sonderwünsche können dabei eher selten berücksichtigt werden. In der Regel spielt das auch keine Rolle. Für alle, deren Ansprüche im Hinblick auf die Funktionalität über den üblichen Standard hinausgehen, werden Clouds aber nicht zufriedenstellend sein.\nAuch das Thema Sicherheit ist ein zweischneidiges Schwert. Hier geht nichts über einen perfekt eingerichteten, von Experten betreuten und stets aktualisierten On-Premise-Server. Demgegenüber besteht bei Cloud-Anbieter(inne)n stets die Gefahr, dass die Server nicht mit der besten Software ausgerüstet sind und somit Sicherheitslücken entstehen, durch die Daten kompromittiert werden können. \nAndererseits muss festgehalten werden: Sicherheitslücken entstehen auch beim Self-Hosting und das Aufrechterhalten der höchsten Standards ist sehr teuer. Viele Hoster wiederum haben in den letzten Jahren ihr Bemühen um höchste Security-Leistungen erhöht und beauftragen externe Dienstleister, um diese zu zertifizieren. So nähern sich die Levels der beiden Bereiche, Cloud- vs. Self-Hosting, einander an. \n\n## Public Cloud: Das Beste beider Welten?\n\nViele Vorzüge eines Modells lassen sich nicht oder nur sehr schwer auf das andere übertragen. So standen viele Firmen vor dem Dilemma, sich für einen Ansatz zu entscheiden, dabei aber auf die Vorteile des anderen verzichten zu müssen.\n\nDie Public Cloud ist der Versuch, Self-Hosting und Cloud-Hosting miteinander zu verschmelzen. Hierbei werden deine Daten auf Servern eines externen Anbieters untergebracht. Doch werden dabei jeweils komplette Hardware-Bereiche exklusiv für dich reserviert. Das bedeutet, dass auf den Rechnern, auf denen deine Webanwendungen betrieben werden, keine Daten weiterer Unternehmen liegen. Die Daten sind somit physisch und auch sicherheitstechnisch getrennt.\n\nSo wird die Sicherheit beträchtlich erhöht und nähert sich weiter dem On-Premise-Niveau an. Sie ist teurer als Cloud-Pakete, aber in der Regel günstiger als eine Self-hosted-Cloud. Unter anderem, weil du nur für genau die Ressourcen bezahlst, die du auch tatsächlich verwendest. Die Skalierbarkeit ist ebenso einfach möglich wie bei einer Cloud, wenngleich du mit gewissen Einschränkungen in Hinblick auf die Bereitstellung rechnen musst. Oftmals kannst du Sonderwünsche sogar in Absprache mit Dienstleister(innen) äußern und umsetzen.\n\nIst die Public Cloud somit die perfekte Lösung? Das wäre eine wohl zu allgemeine Aussage, denn für die meisten wird bereits der deutlich höhere Preis dieses Konzepts ein Ausschlusskriterium darstellen. Darüber hinaus ist in der Public Cloud nicht immer die Übernahme aller Wartungsmaßnahmen und Aktualisierungen im Paket inbegriffen. Solltest du diese Aspekte selbst übernehmen müssen, entsteht letzten Endes derselbe Aufwand wie bei einem Self-Hosting-Modell.\n\n## FAQ\n\n### Was ist GitLab Pages und wie unterstützt es mein Hosting?\n\nGitLab [Pages](https://docs.gitlab.com/ee/user/project/pages/) ist eine Funktionalität, die es dir erlaubt, statische Websites direkt über GitLab zu hosten. Das bedeutet, dass du die Website im Repository anlegen, bearbeiten und anschließend veröffentlichen kannst. Hierbei fallen keine weiteren Zwischenschritte an und die Wahrscheinlichkeit für Fehler sinkt. \n\nDer größte Pluspunkt besteht darin, dass du unmittelbar von allen CI/CD-Funktionalitäten, darunter beispielsweise der ständigen Versionskontrolle, Gebrauch machen, sowie Änderungen direkt aus dem Repository vornehmen kannst. Auch ein Rollback auf die vorige Version gestaltet sich als extrem unkompliziert. Bei der Nutzung von GitLab Pages entstehen zudem keine zusätzlichen Kosten. \n\n### Ist Self-Hosting sicherer als Cloud-Hosting?\n\nDie meisten Experten schätzen ein Self-Hosting-Modell als __die sicherste Option__ ein. Dies erklärt sich dadurch, dass du als Server-Betreiber die höchsten Standards setzen und einhalten kannst, die Chancen für einen unrechtmäßigen Zugriff auf die Daten sinken und individuelle Sicherheitspakete zusammengestellt werden können, die speziell auf deine Bedürfnisse zugeschnitten sind.\n\nAllerdings gilt dieser Vorteil nur, wenn das Hosting von erfahrenen Mitarbeiter(innen) übernommen wird. Diese müssen zudem über ausreichend zeitliche Reserven verfügen, um das System stets auf dem neuesten Stand zu halten und bei eventuellen Aus- oder Zwischenfällen unmittelbar eine Problemlösung durchzuführen. Ein wichtiger Punkt bei der Entscheidung über das für dich richtige Hosting ist oftmals die Frage nach der Einhaltung gewisser rechtlicher Vorgaben. Hier solltest du genau prüfen, ob dein Cloud-Anbieter die erforderlichen Kriterien erfüllen kann.\n",[730,14],"cloud native",{"slug":732,"featured":6,"template":688},"self hosting vs cloud","content:de-de:blog:self-hosting-vs-cloud.yml","Self Hosting Vs Cloud","de-de/blog/self-hosting-vs-cloud.yml","de-de/blog/self-hosting-vs-cloud",{"_path":738,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":739,"content":745,"config":751,"_id":753,"_type":16,"title":754,"_source":18,"_file":755,"_stem":756,"_extension":21},"/de-de/blog/the-ultimate-guide-to-token-management-at-gitlab",{"title":740,"description":741,"ogTitle":740,"ogDescription":741,"noIndex":6,"ogImage":742,"ogUrl":743,"ogSiteName":673,"ogType":674,"canonicalUrls":743,"schema":744},"Der ultimative Leitfaden für die Token-Verwaltung mit GitLab","Erfahre Schritt für Schritt, wie du Token identifizierst, verwaltest und schützt, um die Sicherheit in deinem gesamten Software-Entwicklungsprozess zu verbessern.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097408/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750097407860.jpg","https://about.gitlab.com/blog/the-ultimate-guide-to-token-management-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Der ultimative Leitfaden für die Token-Verwaltung mit GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Hakeem Abdul-Razak\"}],\n        \"datePublished\": \"2025-02-25\",\n      }",{"title":740,"description":741,"authors":746,"heroImage":742,"date":748,"body":749,"category":14,"tags":750},[747],"Hakeem Abdul-Razak","2025-02-25","Stell dir Folgendes vor: Du bist Entwickler(in) in einem aufstrebenden Technologieunternehmen, es ist 2 Uhr morgens und du erhältst einen dringenden Anruf. Eine wichtige Bereitstellungs-Pipeline ist fehlgeschlagen und dein Team versucht, den Grund herauszufinden. Nach stundenlangem Suchen stellst du fest, dass jemand einen persönlichen Zugriffs-Token widerrufen hat, der zu einem bzw. einer Entwickler(in) gehörte, der bzw. die schon seit Wochen nicht mehr für das Unternehmen arbeitet. Dieser Token war an mehrere Automatisierungsprozesse gekoppelt, sodass jetzt dein gesamtes System im Chaos versunken ist. Wie stellst du sicher, dass so etwas nicht nochmals passiert?\n\nFolge dieser Anleitung und erfahre Schritt für Schritt, wie du mit GitLab Token identifizieren, verwalten und schützen kannst. Dies ist eine praktische Ergänzung zur umfassenden [Token-Übersichtsdokumentation](https://docs.gitlab.com/ee/security/tokens) für GitLab-Administrator(inn)en, Entwickler(innen) und Sicherheitsteams, die eine robuste Token-Verwaltung in ihren Projekten benötigen.\n\nIn diesem Leitfaden geht es um folgende Themen:\n- [Wie wählst du den richtigen Token für den Job aus?](#how-to-select-the-right-token-for-the-job)\n- [Token-Arten](#token-types)\n- [Entdecke deine Token](#discovering-your-tokens)\n    - [Credentials Inventory](#credentials-inventory)\n- [Token im GitLab-UI und in der API verwalten](#managing-tokens-in-the-gitlab-ui-and-api)\n- [Rotation der Token und Verwaltung von Ablaufdaten](#token-rotation-and-expiration-management)\n- [Best Practices für die Token-Verwaltung](#token-management-best-practices)\n    - [Dienstkonten](#service-accounts)\n\n## Wie wählst du den richtigen Token für den Job aus?\n\nMit der Auswahl des richtigen Tokens garantierst du die für deinen Anwendungsfall optimale Sicherheit und Funktionsfähigkeit.\nToken können zur Authentifizierung von API-Anfragen, zur Automatisierung von CI/CD-Pipelines, zur Integration von externen Tools, zur Verwaltung von Bereitstellungen und Repositories und für vieles mehr verwendet werden.\n\n![Leitfaden für die Token-Verwaltung – Flussdiagramm für Token](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097434869.png)\n\nDer Einfachheit halber zeigt dieses Diagramm einen unkomplizierten Anwendungsfall, bei der nur ein(e) Benutzer(in) die Inhaberschaft hat. Weitere Informationen findest du in unsere Dokumentation zu Benutzerrollen und Berechtigungen in den einzelnen [Namensräumen](https://docs.gitlab.com/ee/user/permissions.html) (Benutzer(innen)/Gruppe) in deiner Instanz oder Hauptgruppe. Beispiele für Anwendungsfälle:\n\n- **Persönliche Zugriffs-Token** ([PAT](https://docs.gitlab.com/user/profile/personal_access_tokens/#personal-access-token-scopes)) können von Entwickler(innen) verwendet werden, wenn für eine(n) Benutzer(in) persönlicher Zugriff und persönliche Berechtigungen nötig sind. In diesem Fall folgen die Anmeldeinformationen dem Status und den Berechtigungen des Benutzers bzw. der Benutzerin, einschließlich der Entfernung des Zugriffs, wenn das Konto den Zugriff auf ein bestimmtes Projekt oder eine bestimmte Gruppe verliert (oder vollständig gesperrt wird).   \n- **Projekt-/Gruppenzugriffs-Token** ([PrAT](https://docs.gitlab.com/user/project/settings/project_access_tokens/#scopes-for-a-project-access-token)/[GrAT](https://docs.gitlab.com/user/group/settings/group_access_tokens/#scopes-for-a-group-access-token)) werden empfohlen, wenn der Zugriff auf Ressourcen in einem bestimmten Projekt oder einer bestimmten Gruppe eingeschränkt werden soll. Da diese PrAT/GrAT einem bestimmten Geltungsbereichen zugewiesen wurden, können alle auf die jeweils nötigen Ressourcen zugreifen.\n## Token-Arten\n\nUnten findest du eine Liste mit GitLab-Token und deren standardmäßigen Präfixen und Anwendungsfällen. Weitere Informationen findest du auf der [GitLab-Token-Übersichtsseite](https://docs.gitlab.com/ee/security/tokens/#available-scopes). \n\n| Token | Präfix | Beschreibung |\n| :---: | :---: | :---: |\n| Persönlicher Zugriffs-Token | glpat | Für den Zugriff auf benutzerspezifische Daten |\n| OAuth-2.0-Token |  gloas | Für die Integration mit externen Anwendungen über das OAuth2.0-Authentifizierungsprotokoll |\n| Imitations-Token | glpat | Für administrative Handlungen im Namen anderer Benutzer(innen) |\n| Projektzugriffs-Token | glpat | Für den Zugriff auf Daten eines bestimmten Projekts |\n| Gruppenzugriffs-Token | glpat | Für den Zugriff auf Daten einer bestimmten Gruppe |\n| Bereitstellungs-Token | gldt | Zum Klonen, Pushen und Pullen von Container-Registry-Images eines Projekts ohne Benutzer(in) und Passwort |\n| Bereitstellungsschlüssel | n.v. | Ermöglicht den Lese- oder Schreibzugriff auf deine Repositories |\n| Runner-Authentifizierungs-Token | glrt | Für die Authentifizierung von GitLab-Runners |\n| CI/CD-Job-Token  | glcbt | Für die Automatisierung von CI/CD-Prozessen |\n| Trigger-Token | glptt | Löst Pipelines manuell oder programmatisch aus |\n| Feed-Token | glft | Für die Authentifizierung des Zugriffs auf Paket-/RSS-Feeds |\n| Token für eingehende Mails  | glimt | Für die Verarbeitung eingehender E-Mails |\n| Token für GitLab Agent for Kubernetes | glagent | Für die Verwaltung von Kubernetes-Clustern über den GitLab Agent |\n| SCIM-Token | glsoat | Ermöglicht SCIM-Integrationen für die Benutzerbereitstellung |\n| Client-Token für Feature-Flags | glffct | Für programmatische Feature-Flags |\n| Webhook-Token | n.v. | Vom bzw. von der Benutzer(in) festgelegter geheimer Token, um Webhook-Payloads zu sichern und zu gewährleisten, dass Anfragen von GitLab stammen |\n\n## Entdecke deine Token\n\n### Credentials Inventory\n\nIn GitLab Ultimate können Administrator(inn)en (GitLab Self-Managed) und Eigentümer(innen) von Hauptgruppen eines Unternehmens (GitLab.com ab Version 17.5) die Zugangsdaten in ihrem Namensraum überwachen.\n\nDieses Inventar verfolgt Token-Details wie:\n\n* Token-Typ  \n  * Verfügbare Token auf [GitLab.com](https://docs.gitlab.com/ee/user/group/credentials_inventory.html)  \n  * Verfügbare Token auf [GitLab Self-Managed](https://docs.gitlab.com/ee/administration/credentials_inventory.html)  \n* Zugehörige Benutzerkonten  \n* Token-Geltungsbereiche sowie Erstellungs- und Ablaufdaten  \n* Zuletzt verwendete IP-Adressen des Tokens (ab GitLab 17.10)  \n* Token-Filterung basierend auf den oben genannten benutzerdefinierten Parametern  \n* Möglichkeit zum Widerrufen und Rotieren dieser Token\n\nEin gut gepflegtes Credentials Inventory hilft dabei, Token mit zu vielen Berechtigungen zu identifizieren, und gibt Aufschluss über Zugangsdaten, die möglicherweise rotiert werden müssen, um einen sicheren und effizienten Workflow zu gewährleisten.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/A9ONfnwswd0?si=4VIEUgJaD4daj81b&start=105\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line ->\n\n#### Credentials Inventory API\n\nAls Ergänzung zur UI [entwickeln wir derzeit](https://gitlab.com/groups/gitlab-org/-/epics/16343) eine Credentials Inventory API über den neuen [Endpunkt /group/:id/manage](https://docs.gitlab.com/ee/api/members.html#list-all-members-of-a-group-or-project). Die unter diesem Endpunkt zugänglichen Zugangsdaten sind auf [Enterprise-Benutzer(innen)](https://docs.gitlab.com/ee/user/enterprise_user/) beschränkt und können vom bzw. von der Eigentümer(in) der Hauptgruppe eines Unternehmens abgerufen werden. Ein Beispiel für den zukünftigen API-Aufruf wäre:\n\n```console\ncurl --header \"PRIVATE-TOKEN: \u003Cpat>\" \"https://verified_domain.com/api/v4/groups/\u003Cgroup_id>/manage/personal_access_tokens\"           \n```\n### GitLab-API\n\nMit der GitLab-API kannst du Token in deinem Unternehmen programmgesteuert auflisten und verwalten. Wichtige authentifizierungsbezogene Endpunkte unterstützen [verschiedene Token-Typen](https://docs.gitlab.com/ee/api/rest/authentication.html)), darunter persönliche Token, Gruppen-Token, CI/CD-Token und mehr. Ein Beispiel für die Verwendung eines persönlichen Zugriffs-Tokens zum Auflisten aller sichtbaren Projekte in GitLab für authentifizierte Benutzer(innen) ist:\n\n\n```console\ncurl --header \"PRIVATE-TOKEN: \u003Cyour_access_token>\" \\\n     \"https://gitlab.example.com/api/v4/projects\"\n\n```\n\nIn diesem Video erfährst du, wie du API-Aufrufe an die GitLab-API sendest.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0LsMC3ZiXkA?si=vj871YH610jwQdFc\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line ->\n\n### Finde heraus, wo Token verwendet werden\n\nKund(inn)en können auf verschiedene Arten herausfinden, wo Token verwendet werden:\n* Unter **Benutzerprofil > [Zugriffstoken](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used)**\n* Im Credentials Inventory\n* In Audit-Ereignissen\n* Über die API \n\nInformationen zur Token-Nutzung werden alle 10 Minuten für **last_used** und einmal pro Minute für **last_used_ip** aktualisiert. \n\nDie Möglichkeit, IP-Adressen anzuzeigen, wurde in GitLab 17.9 eingeführt und wird durch das Feature-Flag **:pat_ip** gesteuert. Befolge diese [Schritte, um herauszufinden, wann ein Token zuletzt verwendet wurde](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used). Außerdem werden dir seine letzten fünf eindeutigen IP-Adressen angezeigt.\n\n![Leitfaden für Token-Verwaltung – Einstellungen für persönliche Zugriffs-Token](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097434870.png)\n\n## Token im GitLab-UI und in der API verwalten\nIn der folgenden Tabelle findest du Videos, in denen gezeigt wird, wie Token im UI erstellt werden und wie sie über die API genutzt werden können.\n\n| Token     | GitLab-UI    | GitLab-API    |\n| ---------- | ---------- | ---------- |\n| Persönlicher Zugriffs-Token \u000b | [Dokumentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=3)  | [Dokumentation](https://docs.gitlab.com/ee/api/personal_access_tokens.html) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=43)  |\n| Gruppenzugriffs-Token | [Dokumentation](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#group-access-tokens) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=120)  | [Dokumentation](https://docs.gitlab.com/ee/api/group_access_tokens.html) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=157)  |\n| Projektzugriffs-Token | [Dokumentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#project-access-tokens) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=254)  | [Dokumentation](https://docs.gitlab.com/ee/api/project_access_tokens.html) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=285)  |\n\n## Rotation der Tokens und Verwaltung von Ablaufdaten\n\nIndem du Token rotierst und strikte Richtlinien für Ablaufdaten einführst, reduzierst du das Komprimittierungsrisiko und stellst die Einhaltung von Sicherheitsstandards sicher. Regelmäßige Rotation und erzwungene Abläufe verhindern, dass veraltete Zugangsdaten zu Sicherheitslücken werden.\n\nBisher wurden abgelaufene Gruppen- und Projektzugriffs-Token nach Ablauf automatisch gelöscht, was die Überwachung und Sicherheitsüberprüfung schwieriger machte, da keine Aufzeichnungen zu inaktiven Token vorlagen. Um dieses Problem zu beheben, wurde eine [neue Funktion](https://gitlab.com/gitlab-org/gitlab/-/issues/462217) eingeführt, um Aufzeichnungen zu inaktiven Gruppen- und Projektzugriffs-Token 30 Tage, nachdem sie inaktiv wurden, im UI aufzubewahren. Diese Verbesserung soll es den Teams ermöglichen, die Verwendung, den Ablauf und den Widerruf von Token zu verfolgen, um die Compliance und Überwachung zu verbessern.\n\nUm die Rotation von Token und die Verwaltung von Ablaufdaten proaktiv zu gestalten, kannst du Folgendes tun:\n\n* Rotiere deine Token aktiv über die UI oder die API. Wenn du die API verwendest, achte auf den Sicherheitsmechanismus, mit dem [wiederverwendete Token automatisch erkannt werden](https://docs.gitlab.com/ee/api/personal_access_tokens.html#automatic-reuse-detection).\n* Lege eine instanzweite [maximale Geltungsdauer](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limit-the-lifetime-of-access-tokens) für Zugriffs-Token fest.\n\n### API für die Rotation von Token\n\nBis GitLab 17.7 mussten Kund(inn)en Zugriffs-Token programmgesteuert mit der API rotieren. Die entsprechende Funktion ist jetzt im UI verfügbar. Sieh dir das Video in der folgenden Tabelle an oder lies dir die [Dokumentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#use-the-ui) durch.\n\n### Codeausschnitte für die Rotation von Token\n\nIn der folgenden Tabelle findest du Videos, in denen die Rotation von GitLab-Token erläutert wird. \n\n| Token | Voraussetzungen | GitLab-UI | GitLab-API |\n| :---: | :---: | ----- | ----- |\n| Persönliches Zugriffs-Token | Geltungsbereich: API  | [Dokumentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=76)  | [Dokumentation](https://docs.gitlab.com/ee/api/personal_access_tokens.html#rotate-a-personal-access-token) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=92)  |\n| Gruppenzugriffs-Token | Geltungsbereich: API und Rolle(n): Eigentümer(in) | [Dokumentation](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#create-a-group-access-token-using-ui) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=203)  | [Dokumentation](https://docs.gitlab.com/ee/api/group_access_tokens.html) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=214)  |\n| Projektzugriffs-Token | Geltungsbereich: API und Rolle(n): Eigentümer(in), Betreuer(in) | [Dokumentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=335)  | [Dokumentation](https://docs.gitlab.com/ee/api/project_access_tokens.html) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=349)  |\n\n## Best Practices für die Token-Verwaltung\n\n### Prinzip des geringsten Privilegs\n\nMindere Risiken, indem du Berechtigungen für Token wirklich nur für die jeweiligen unbedingt nötigen Aufgaben zuweist. Auf diese Weise kannst du Fehlerquellen in deinen Systemen proaktiv vorhersagen und beheben. Beachte dazu Folgendes:\n\n* Wähle den richtigen Token für den richtigen Job aus. Infos dazu findest du im Flussdiagramm.  \n* Weise beim Erstellen eines Tokens nur die erforderlichen Geltungsbereiche zu. Verwende beispielsweise schreibgeschützte Geltungsbereiche für Token mit Aufgaben für Auditor(innen). Siehe [Rollen](https://docs.gitlab.com/ee/user/permissions.html#roles).  \n* Vermeide es, Administratorrechte zu gewähren, wenn sie nicht unbedingt nötig sind.\n* Erzwinge eine instanzweite Standard-Token-[Lebensdauer](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#set-a-lifetime-1).\n* Überprüfe und auditiere Token-Berechtigungen regelmäßig, um sicherzustellen, dass sie den aktuellen Anforderungen deines Unternehmens entsprechen.  \n* Widerrufe Token, sobald die Aufgabe abgeschlossen ist.\n\n### Service-Konten\n\n[Dienstkonten](https://docs.gitlab.com/ee/user/profile/service_accounts.html) stellen sicher, dass Token an nicht-menschliche Entitäten gebunden sind. Dadurch werden sie von einzelnen Benutzerkonten getrennt und die Abhängigkeit von bestimmten Benutzer(inne)n wird verringert. Anstatt persönliche Konten zu verwenden, um Token für die Automatisierung zu generieren, solltest du Dienstkonten mit eingeschränktem Geltungsbereich erstellen. Zu den Vorteilen gehören:\n\n* Verwendung von Dienstkonto-Token in CI/CD-Pipelines, um Störungen durch Änderungen des Benutzerkontos zu vermeiden  \n* Programmgesteuerte Automatisierung von Rotationsprozessen, da persönliche Konten nicht betroffen sind\n* Klarere Überwachung und Prüfung der von Dienstkonten durchgeführten Aktionen  \n* Dienstkonten [ohne Ablaufdatum](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-service-account-personal-access-token-with-no-expiry-date)\n* Verbraucht keinen [Lizenzplatz](https://docs.gitlab.com/user/profile/service_accounts/#create-a-service-account)\n\nGitLab plant die Veröffentlichung einer neuen [Benutzeroberfläche für Dienstkonten](https://gitlab.com/groups/gitlab-org/-/epics/9965) als Gegenstück zur [API-basierten Erstellung](https://docs.gitlab.com/ee/api/user_service_accounts.html#create-a-service-account-user), wodurch die Verwaltung von Dienstkonten und der damit verbundenen Token vereinfacht werden soll. In der folgenden Demo wird die programmgesteuerte Verwendung von Dienstkonten erläutert.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/oZvjg0SCsqY?si=cj-0LjfeonLGXv9u\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line ->\n\n### Sicherheitslücken-Tools\n\nNutze die integrierten Sicherheitstools von GitLab, um Sicherheitslücken, die durch die Nutzung von Token entstehen, zu identifizieren und zu beheben. Für eine maximale Abdeckung wird empfohlen, alle Tools gemeinsam zu verwenden.\n\n* [Erkennung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/): Scannt dein Repository nach fest codierten Geheimnissen wie API-Token, Passwörtern und anderen vertraulichen Informationen. Sieh dir die [Liste der erkannten Geheimnisse](https://docs.gitlab.com/ee/user/application_security/secret_detection/detected_secrets.html) an.\n* [Statische Anwendungssicherheitstests (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/): Analysiert deinen Quellcode auf Sicherheitslücken und [stellt unter anderem Berichte mit UI-Ergebnissen in Merge Requests bereit](https://docs.gitlab.com/ee/user/application_security/sast/#features).\n* [Abhängigkeitssuche](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/): Stellt sicher, dass in deinem Projekt verwendete Bibliotheken von Drittanbietern keine Sicherheitslücken hinsichtlich ihrer Token aufweisen.\n\n### Audit-Protokolle und Überwachung\n\nPflege den Zustand von Token, indem du regelmäßig Audit-Protokolle und die Token-Nutzung auf Instanz- und/oder Gruppenebene überprüfst.\n\n* [Audit Events](https://docs.gitlab.com/ee/user/compliance/audit_events.html): Protokolliere Audit Events in GitLab, um Aktivitäten im Zusammenhang mit Token zu verfolgen, z. B. Erstellung, Verwendung, Löschung und ungewöhnliche API-Aufrufe (nicht zulässige Parameter in Protokollen und konsistente Auslöser des Rate Limiters). \n* [IP-Allowlisting](https://docs.gitlab.com/ee/administration/reporting/ip_addr_restrictions.html#configure-ip-address-restrictions): Verhindert, dass böswillige Benutzer(innen) ihre Aktivitäten hinter mehreren IP-Adressen verbergen.\n* [Alarme](https://docs.gitlab.com/ee/operations/incident_management/alerts.html): Richte Alarme für ungewöhnliche Aktivitäten ein (lösen z. B. Paging für Bereitschaftsrotationen aus oder verwende es, um Vorfälle zu erstellen).\n* [Credentials Inventory](https://docs.gitlab.com/ee/administration/credentials_inventory.html): Erhalte vollständige Kontrolle über alle verfügbaren Zugriffs-Token sowie die Möglichkeit, diese bei Bedarf zu widerrufen.\n* [Benachrichtigungen](https://docs.gitlab.com/ee/user/profile/notifications.html): Bearbeite proaktiv alle Ablaufbenachrichtigungen für Token (Gruppen-, Projekt- und persönliche Token), die du per E-Mail erhältst. Aufgrund der Nachfrage unserer Kund(inn)en wurde diese Funktion kürzlich um 30-Tage- und 60-Tage-Benachrichtigungen erweitert (die Standardeinstellung ist 7 Tage).   \n* [Webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#create-a-webhook): Zugriffs-Token-Webhooks können für Gruppen und Projekte konfiguriert werden, um Ereignisse sieben Tage vor Ablauf von Token auszulösen. Diese Funktion wurde kürzlich auch um 30-Tage- und 60-Tage-Benachrichtigungen hinter dem Feature-Flag **:extended_expiry_webhook_execution_setting** erweitert (standardmäßig deaktiviert).\n\n## Was kommt als Nächstes?\n\nAngesichts des großen Token-Katalogs von GitLab gibt es laufende [Pläne](https://gitlab.com/gitlab-org/gitlab/-/issues/502630) für eine Konsolidierung mit Schwerpunkt auf der Lebensdauer, detaillierten Geltungsbereichen, konsistenter Verwaltung und Nutzung. Derzeit priorisieren wir hinsichtlich der Token-Funktionen ein umfassendes UI für Dienstkonten, zusätzliche Arten von Zugangsdaten im Credentials Inventory sowie ein verbessertes Auditing für Token und Dienstkonten.\n\n> Melde dich für eine [kostenlose 60-tägige Testversion von GitLab Ultimate](https://about.gitlab.com/free-trial/) an, um die Token-Verwaltung zu nutzen.",[682,14,683,684,685],{"slug":752,"featured":93,"template":688},"the-ultimate-guide-to-token-management-at-gitlab","content:de-de:blog:the-ultimate-guide-to-token-management-at-gitlab.yml","The Ultimate Guide To Token Management At Gitlab","de-de/blog/the-ultimate-guide-to-token-management-at-gitlab.yml","de-de/blog/the-ultimate-guide-to-token-management-at-gitlab",{"_path":758,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":759,"content":765,"config":772,"_id":774,"_type":16,"title":775,"_source":18,"_file":776,"_stem":777,"_extension":21},"/de-de/blog/how-gitlab-helps-meet-nis2-requirements",{"title":760,"description":761,"ogTitle":760,"ogDescription":761,"noIndex":6,"ogImage":762,"ogUrl":763,"ogSiteName":673,"ogType":674,"canonicalUrls":763,"schema":764},"So hilft GitLab dabei, die NIS2-Anforderungen einzuhalten","Beim NIS2-Cybersicherheitsgesetz der EU geht es um Resilienz, Reaktion auf Vorfälle und Risikomanagement. Erfahre, wie GitLabs DevSecOps-Plattform helfen kann, diese Compliance-Anforderungen einzuhalten.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659437/Blog/Hero%20Images/AdobeStock_398929148.jpg","https://about.gitlab.com/blog/how-gitlab-helps-meet-nis2-requirements","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So hilft GitLab dabei, die NIS2-Anforderungen einzuhalten\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2024-08-20\",\n      }",{"title":760,"description":761,"authors":766,"heroImage":762,"date":768,"body":769,"category":14,"tags":770,"updatedDate":771},[767],"Joseph Longo","2024-08-20","Regierungen und Aufsichtsbehörden auf der ganzen Welt erlassen ständig neue Gesetze und Vorgaben, um auf die wachsenden Risiken der globalen Digitalisierung und die daraus entstehenden Bedrohungen im Bereich der Cybersicherheit einzugehen. Bei der [NIS2-Richtlinie](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:02022L2555-20221227) der EU handelt es sich um ein Gesetz, das die Cybersicherheit verbessern soll, indem Wert auf Kernkompetenzen wie Resilienz, Reaktion auf Vorfälle und Risikomanagement gelegt wird.\n\nAls umfassendste KI-gestützte DevSecOps-Plattform wird GitLab auf der ganzen Welt eingesetzt, um schneller bessere Software zu entwickeln. Durch die vielfältigen Funktionen ist GitLab ein einzigartiges, wertvolles Asset, mit dem wir viele [Sicherheits- und Compliance-Anforderungen](https://about.gitlab.com/de-de/solutions/security-compliance/) unserer Kund(inn)en erfüllen können. Sehen wir uns an, wie genau Kund(inn)en die GitLab-Plattform für ihre Maßnahmen hinsichtlich NIS2-Compliance nutzen können.\n\n## Artikel 7: Nationale Cybersicherheitsstrategie\n\n**Abschnitt 2(a) – für die Cybersicherheit in der Lieferkette für IKT-Produkte und IKT-Dienste, die von Einrichtungen für die Erbringung ihrer Dienste genutzt werden.**\n\nNIS2 verlangt von den Mitgliedstaaten, Richtlinien zu erlassen, die sich mit der Cybersicherheit in der Lieferkette befassen. Die Richtlinien müssen zwar von den einzelnen Mitgliedsstaaten erst festgelegt werden, die [Sicherungsphase](https://about.gitlab.com/features/?stage=secure) von GitLab bietet jedoch schon jetzt Funktionen, mit denen Kund(inn)en die Sicherheit ihrer angebotenen Dienste sowie ihrer Lieferkette verwalten können.\n\n- [Statische Anwendungssicherheitstests (SAST)](https://about.gitlab.com/features/?stage=secure#static_application_security_testing), [Sicherheitsscans für Infrastructure as Code](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) und [dynamische Anwendungssicherheitstests (DAST)](https://about.gitlab.com/features/?stage=secure#dynamic_application_security_testing) ermöglichen es Kund(inn)en, ihren Quellcode, Infrastrukturdefinitionsdateien und ausgeführte Anwendungen auf Sicherheitslücken zu überprüfen. Dann können die Ergebnisse entsprechend den Prozessen des jeweiligen Unternehmens priorisiert und bearbeitet werden.\n\n- Mit der Funktion [Container-Scanning](https://about.gitlab.com/features/?stage=secure#container_scanning) von GitLab können Kund(inn)en bekannte Sicherheitslücken in ihren Container-Images identifizieren.\n\n![Bericht zum Container-Scanning](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.38.54.png)\n\n- Für die Lieferkette hilft die [Abhängigkeitssuche](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), bekannte Sicherheitslücken in den Anwendungsabhängigkeiten unserer Kund(inn)en zu identifizieren. Die [Lizenzkonformität](https://docs.gitlab.com/ee/user/compliance/license_approval_policies.html) ist eine Erweiterung der Abhängigkeitssuche, denn dabei wird überprüft, ob die Lizenzen von Abhängigkeiten eine Reihe von Kriterien erfüllen, die vom Unternehmen festgelegt wurden.\n\n- Mit der [Liste der Abhängigkeiten](https://docs.gitlab.com/ee/user/application_security/dependency_list/) von GitLab können Unternehmen auch eine [CycloneDX-Software-Stückliste (SBOM)](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/) erstellen. Weitere Informationen findest du in [diesem Tutorial zum Exportieren einer SBOM](https://docs.gitlab.com/ee/tutorials/export_sbom.html). Zudem hilft dir unser [ultimativer Leitfaden zu SBOMs](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/) dabei, alles über Software Bills of Materials zu verstehen.\n\nGemeinsam bilden diese Scan-Funktionen eine ganzheitliche, starke Test-Suite, die eine robuste Anwendungsentwicklung und resiliente Lieferkettenmanagement-Prozesse ermöglicht. DAST, Abhängigkeitssuche und Lizenzkonformität sind in GitLab-Ultimate-Abonnements enthalten.\n\n> [Teste GitLab Ultimate 30 Tage lang kostenlos](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n\n## Artikel 21: Risikomanagementmaßnahmen im Bereich der Cybersicherheit\n\nNIS2 verlangt von den Mitgliedstaaten, sicherzustellen, dass Einrichtungen, die eine tragende Rolle spielen, die geeigneten technischen, organisatorischen und betrieblichen Maßnahmen ergreifen, um Risiken ordnungsgemäß zu managen. Dadurch sollen die Auswirkungen vermindert werden, mit denen sich die Benutzer(innen) ihrer Dienste aufgrund von verschiedenen Vorfällen konfrontiert sahen.\n\n**Abschnitt 2(d) – Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbieter(inne)n oder Diensteanbieter(inne)n.**\n\nWie oben erwähnt, bietet die [Sicherungsphase](https://about.gitlab.com/features/?stage=secure) von GitLab den Kund(inn)en eine große Auswahl an Funktionen, um Sicherheitslücken zu erkennen und darauf zu reagieren. So wird die Sicherheit des Codes verbessert und Risiken in der Lieferkette werden behoben.\n\nDiese Funktionen können genutzt werden, um die Anforderungen zu erfüllen, die die Mitgliedsstaaten im Rahmen dieses Gesetzesabschnittes zukünftig auf die einzelnen Unternehmen übertragen.\n\n**Abschnitt 2(e) – Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen.**\n\nAls umfassende DevSecOps-Plattform bietet GitLab Funktionen, mit denen die Lebenszyklen der Softwarebereitstellung unserer Kund(inn)en von Anfang bis Ende geschützt werden können.\n\n- Die [Planungstools](https://about.gitlab.com/features/?stage=plan) von GitLab können für das Projektmanagement verwendet werden und stellen sicher, dass die Informationssicherheit in allen Phasen des Projektlebenszyklus gewahrt wird. Weitere Informationen findest du unter [So unterstützt dich GitLab bei deiner ISO-27001-Compliance](https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey/#organizational-controls).\n\n- Durch Funktionen wie [geschützte Branches](https://docs.gitlab.com/ee/user/project/protected_branches.html), [Merge-Request-Approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/), [Push-Regeln](https://docs.gitlab.com/ee/push_rules/push_rules.html) und [unterzeichnete Commits](https://docs.gitlab.com/ee/user/project/repository/signed_commits/) bildet GitLab in der [Entwicklungsphase](https://about.gitlab.com/features/?stage=create) eine sichere Grundlage, auf deren Basis Entwickler(innen) bei der Iteration und Erstellung von sicherem Code arbeiten können.\n\n![Unterzeichnete Commits](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.34.24.png)\n\n- Die oben genannten Funktionen der [Sicherungsphase](https://about.gitlab.com/features/?stage=verify) von GitLab bilden eine auf Sicherheit fokussierte Grundlage für die [Verifizierungs-](https://about.gitlab.com/features/?stage=verify), [Paket-](https://about.gitlab.com/features/?stage=package) und [Bereitstellungsphasen](https://about.gitlab.com/features/?stage=deploy) von GitLab. Zu diesen Phasen gehören Kernfunktionen der [kontinuierlichen Integration](https://about.gitlab.com/features/?stage=verify)/[kontinuierlichen Lieferung](https://about.gitlab.com/features/?stage=deploy) wie [MR-Pipelines](https://docs.gitlab.com/ee/ci/merge_request_pipelines/) und [geschützte Runner](https://docs.gitlab.com/ee/ci/runners/#prevent-runners-from-revealing-sensitive-information) sowie mehrere Artefaktregister für organisatorische Anforderungen.\n\n- Die [Überwachungsphase](https://about.gitlab.com/features/?stage=monitor) von GitLab bietet Funktionen wie [Warnungen](https://docs.gitlab.com/ee/operations/incident_management/alerts.html) und [Vorfälle](https://docs.gitlab.com/ee/operations/incident_management/incidents.html), mit denen Unternehmen auf Vorfälle aufmerksam werden und diese bis zur Behebung in GitLab nachverfolgen können.\n\n- Die Funktionen von GitLab für die [Regulierungsphase](https://about.gitlab.com/features/?stage=govern) setzen den Standard dafür, wer eine GitLab-Instanz auf welche Weise verwenden kann. Sie tragen auch zu den allgemeinen Compliance-Bemühungen eines Unternehmens bei.\n  - Funktionen wie [SCIM](https://docs.gitlab.com/ee/administration/settings/scim_setup.html), [SSO](https://docs.gitlab.com/ee/user/group/saml_sso/) und [benutzerdefinierte Rollen](https://docs.gitlab.com/ee/user/custom_roles.html) tragen effektiv zu Authentifizierungs- und Autorisierungslebenszyklen bei.\n  - [MR-Approvalrichtlinien](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) sind ein leistungsstarkes Tool für die Implementierung eines Sicherheitstors in deinem Software-Entwicklungsprozess. Mithilfe von MR-Approvalrichtlinien kann ein Unternehmen zusätzliche Approvals für Ereignisse erfordern, z. B. wenn nach einem Commit Sicherheitslücken erkannt werden oder bestimmte Lizenztypen in Abhängigkeiten erkannt werden. Außerdem sind sie für alle MR erforderlich, die für einen bestimmten geschützten Branch erstellt wurden. MR-Approvalrichtlinien sind in GitLab-Ultimate-Abonnements enthalten.\n  - Mit [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) können Unternehmen die Funktion zum [Erklären von Sicherheitslücken](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/index.html#explaining-a-vulnerability nutzen, um:\n    - Sicherheitslücken zusammenzufassen\n    - Entwickler(inne)n und Sicherheitsanalytiker(inne)n zu helfen, die Sicherheitslücken zu verstehen und herauszufinden, wie diese ausgenutzt und behoben werden können\n    - eine Abhilfemaßnahme vorzuschlagen \n  -  [Streaming von Audit-Ereignissen](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming.html) ermöglichen es Unternehmen, Audit-Ereignisse von ihrer Hauptgruppe an einen externen Standort zu senden, um alle Ereignisse zu Gruppen, Untergruppen und Projekten zu erhalten. Das Streaming von Audit-Ereignissen ist in GitLab-Ultimate-Abonnements enthalten.\n  - Ein starkes Insider-Bedrohungsprogramm kombiniert mehrere Ebenen von erkennenden, präventiven und reaktiven Kontrollen. Die [Ratenbegrenzung von Git für die Verhinderung von Missbrauch](https://docs.gitlab.com/ee/user/group/reporting/git_abuse_rate_limit.html) benachrichtigt Administrator(inn)en automatisch, wenn ein(e) Benutzer(in) mehr als eine bestimmte Anzahl von Repositories einer Gruppe in einem bestimmten Zeitraum herunterlädt, klont, pullt, abruft oder forked. Unternehmen können noch einen Schritt weiter gehen und automatische Sperren einrichten, um Benutzer(innen) nach Verstößen aus der Gruppe und ihren Untergruppen zu verbannen. Die Ratenbegrenzung von Git für die Verhinderung von Missbrauch ist in GitLab-Ultimate-Abonnements enthalten.\n -  Das Thema “erkannte Sicherheitslücken” wird im [Sicherheitslückenbericht](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) von GitLab noch weiter vertieft und enthält auch Informationen über Sicherheitslücken aus Scans des Standard-Branchs. Wenn du dich für die Sicherheitslückenberichte interessierst, hol dir das GitLab-Ultimate-Abonnement noch heute.\n\n![Sicherheitslückenbericht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.32.02.png)\n\n**Abschnitt 2(j) – Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation sowie gegebenenfalls gesicherte Notfallkommunikationssysteme innerhalb der Einrichtung.**\n\nGitLab bietet mehrere Multi-Faktor-Authentifizierungsoptionen, um einen strengeren Authentifizierungsprozess zu unterstützen. Kund(inn)en können die [Multi-Faktor-Authentifizierungsoption](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) nutzen, die ihren Anforderungen entspricht, oder sie können [SSO](https://docs.gitlab.com/ee/user/group/saml_sso/) implementieren, um den Authentifizierungsprozess noch weiter zu verbessern.\n\n## Wie geht es weiter mit NIS2?\n\nDie Mitgliedstaaten haben zwar noch keine umfassenden Leitlinien als Reaktion auf die NIS2-Richtlinie erlassen, aber die GitLab-Plattform ist bereits jetzt gut gerüstet, um die Anforderungen für den Software-Entwicklungsprozess zu erfüllen, sobald diese eingeführt werden.\n\nWeitere Informationen zu den Funktionen in diesem Artikel findest du in unserer [Tutorial-Bibliothek](https://docs.gitlab.com/ee/tutorials/).\n\n> Um loszulegen, [melde dich für eine kostenlose 30-tägige Testversion von GitLab Ultimate an](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n",[683,14,685],"2025-03-25",{"slug":773,"featured":93,"template":688},"how-gitlab-helps-meet-nis2-requirements","content:de-de:blog:how-gitlab-helps-meet-nis2-requirements.yml","How Gitlab Helps Meet Nis2 Requirements","de-de/blog/how-gitlab-helps-meet-nis2-requirements.yml","de-de/blog/how-gitlab-helps-meet-nis2-requirements",{"_path":779,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":780,"content":786,"config":794,"_id":796,"_type":16,"title":797,"_source":18,"_file":798,"_stem":799,"_extension":21},"/de-de/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"title":781,"description":782,"ogTitle":781,"ogDescription":782,"noIndex":6,"ogImage":783,"ogUrl":784,"ogSiteName":673,"ogType":674,"canonicalUrls":784,"schema":785},"FinServ: So implementierst du die Funktion zur Aufgabentrennung von GitLab","Wie GitLab eine sichere Softwareentwicklung mit Aufgabentrennung im Finanzdienstleistungssektor gewährleistet, einschließlich der Einhaltung regulatorischer Rahmenbedingungen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097688/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%286%29_6vL96ttKF8zJLLqfPpvFs_1750097687913.png","https://about.gitlab.com/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"FinServ: So implementierst du die Funktion zur Aufgabentrennung von GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cherry Han\"},{\"@type\":\"Person\",\"name\":\"Gavin Peltz\"}],\n        \"datePublished\": \"2024-08-13\",\n      }",{"title":781,"description":782,"authors":787,"heroImage":783,"date":790,"body":791,"category":14,"tags":792,"updatedDate":793},[788,789],"Cherry Han","Gavin Peltz","2024-08-13","Während der gesamten Softwareentwicklung sind robuste Sicherheits- und Compliance-Maßnahmen erforderlich, insbesondere in Branchen wie Finanzdienstleistungen, in denen Datenintegrität und Einhaltung der Vorschriften nicht verhandelbar sind. Ein kritischer Aspekt bei der Einhaltung dieser Standards ist die **Aufgabentrennung (SoD, \"Segregation of Duties\")**.\n\n**SoD stellt sicher, dass keine Person die vollständige Kontrolle über einen Prozess vom Anfang bis zum Ende hat**, wodurch das Risiko von Fehlern und unbefugten Aktivitäten verringert wird. SoD verringert die Risiken der Software-Lieferkette, indem externe und böswillige Handlungen verhindert werden, die die Integrität des Softwareentwicklungsprozesses beeinträchtigen könnten.\n\n## Bedeutung von SoD in der Finanzdienstleistungsbranche\n\nIm Finanzdienstleistungssektor spielt SoD eine entscheidende Rolle beim Schutz sensibler Informationen und der Einhaltung der Vorschriften. So trägt SoD strategisch zur Branche bei:\n\n* **Risikominderung:** Durch die Verteilung der Verantwortlichkeiten auf verschiedene Rollen verringert SoD das Risiko von Fehlern, Betrug und unbefugten Aktivitäten, die die Systemintegrität oder die Einhaltung der Vorschriften beeinträchtigen könnten.\n* **Verbesserte Verantwortlichkeit:** Eine klare Aufteilung der Aufgaben garantiert, dass keine Person einen Prozess von Anfang bis Ende unabhängig initiieren, autorisieren und ausführen kann. Dies fördert Transparenz und Verantwortlichkeit, die für die Aufrechterhaltung des Vertrauens bei Stakeholdern und Aufsichtsbehörden von entscheidender Bedeutung sind.\n* **Einhaltung der Vorschriften:** SoD ist durch die Finanzvorschriften vorgeschrieben, sodass sensible Vorgänge unter Aufsicht und Kontrolle durchgeführt werden. Die Einhaltung dieser Standards vermeidet nicht nur Strafen, sondern schützt auch den Ruf des Unternehmens.\n* **Betriebliche Widerstandsfähigkeit:** Durch die Dezentralisierung der Entscheidungsfindung und -ausführung werden Unternehmen weniger anfällig für Störungen, die durch menschliche Fehler, böswillige Handlungen oder unerwartete Ereignisse verursacht werden.\n\n## GitLab für SoD und Best Practices\nGitLab bietet eine durchgängige Aufgabentrennung für den DevSecOps-Workflow.\n\n![FinServ SOD - Bild 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097695/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097695697.png)\n\nDas obige Diagramm veranschaulicht die Integration von Schlüsselelementen wie Genehmigungsrichtlinien für die Genehmigung von Merge Requests, geschützte Funktionen, Benutzerberechtigungen, Compliance-Frameworks und Audit-Ereignisse, die alle zusammenarbeiten, um die Prinzipien von SoD aufrechtzuerhalten. Jede dieser Komponenten wird in den folgenden Abschnitten beschrieben und zeigt, wie man eine sichere und konforme Entwicklungsumgebung einrichtet.\n\n### Merge-Request-Genehmigungsrichtlinien\n\nEine Herausforderung für die Finanzdienstleistungsbranche ist die Implementierung von Genehmigungsmechanismen, die verhindern, dass unbefugte oder unkontrollierte Änderungen integriert werden. Hier kommen [Merge-Request-Genehmigungsrichtlinien](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) ins Spiel. Diese Richtlinien erzwingen die Aufgabentrennung zwischen Sicherheit und Entwicklung und verhindern, dass einzelne Entwickler(innen) ihre eigenen Codeänderungen genehmigen, wenn sie Schwachstellen enthalten, und dass Entwicklungsteams ihren Code ohne angemessene Aufsicht direkt in Produktivumgebungen bereitstellen. \n\nBei der Erstellung einer Richtlinie ist es ratsam zu überlegen, wer eine geeignete Person für die Genehmigung wäre. Dies kann als ein(e) einzelne(r) Benutzer(in), eine Gruppe wie das Anwendungssicherheitsteam oder ein Rollentyp wie ein(e) Betreuer(in) definiert werden. Um weitere Einschränkungen zu implementieren, beachte bitte diese wichtigen Richtlinienmerkmale:\n\n- Verhindern der Genehmigung durch den bzw. die Autor(in): Diese Richtlinie legt Leitlinien fest, sodass ein(e) Merge-Request-Autor(in) seine eigenen Änderungen nicht genehmigen kann. Indem diese Richtlinie eine unabhängige Überprüfung erfordert, hilft sie, Objektivität und Unparteilichkeit im Genehmigungsprozess aufrechtzuerhalten.\n\n- Verhindern von Genehmigungen durch Benutzer(innen), die Commits hinzufügen: Benutzer(innen), die Commits zu einem Merge Request hinzugefügt haben, werden ebenfalls daran gehindert, diesen zu genehmigen. Dadurch wird das Prinzip der unabhängigen Überprüfung weiter durchgesetzt, sodass Änderungen von Teammitgliedern überprüft werden, die nicht direkt an den Änderungen beteiligt sind.\n\n- Verhindern des Bearbeitens von Genehmigungsregeln: Um die Integrität des Genehmigungsprozesses aufrechtzuerhalten, ermöglicht GitLab Administrator(inn)en, das Bearbeiten von Genehmigungsregeln auf Projekt- oder Merge-Request-Ebene zu verhindern. Dies garantiert, dass einmal definierte Genehmigungsrichtlinien nicht von unbefugten Benutzer(inne)n umgangen oder geändert werden können.\n\n- Benutzerpasswort zum Genehmigen anfordern: Für eine zusätzliche Sicherheitsebene kann GitLab von Benutzer(inne)n verlangen, dass sie ihr Passwort eingeben, um einen Merge Request zu genehmigen. \n\nUm eine klare Aufgabentrennung aufrechtzuerhalten, ist es ratsam, [eine separate Hauptgruppe zu erstellen](https://docs.gitlab.com/ee/user/application_security/policies/#enforce-policies-globally-in-gitlab-dedicated-or-your-gitlab-self-managed-instance), die sich mit der Unterbringung deiner Sicherheitsrichtlinien befasst, einschließlich der Richtlinien für die Genehmigung von Merge Requests. Dieses Setup minimiert die Anzahl der Benutzer(innen), die Berechtigungen erben, und erzwingt eine strengere Kontrolle über die Richtlinienverwaltung. Von dieser separaten Gruppe aus kannst du auf der höchsten Gruppenebene, die mit deinen Zielen übereinstimmt, den Verwaltungsaufwand für Richtlinien reduziert und eine umfassende Abdeckung Ihrer Entwicklungsumgebung bietet, [Sicherheitsrichtlinienprojekte verlinken](https://docs.gitlab.com/ee/user/application_security/policies/#link-to-a-security-policy-project).\n\nDu solltest auch beachten, dass eine Richtlinie, die standardmäßig aktiviert ist, für alle Projekte innerhalb der verlinkten Gruppen, Untergruppen und einzelnen Projekte gilt. Wenn du Richtlinien selektiver durchsetzen möchtest, empfiehlt GitLab, deine Richtlinien auf ein [Compliance-Framework-Label](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html) auszudehnen. In der Regel werden unsere stark regulierten Kund(inn)en Compliance-Labels entwerfen, die den regulatorischen Anforderungen entsprechen, wie „SOX“ und „PCI“. Dieser Link zu einem Framework ermöglicht es dem [nativen Compliance-Center](https://docs.gitlab.com/ee/user/compliance/compliance_center/) auch, Sicherheitsrichtlinien zu verwalten, die auf verschiedene Anwendungsfälle zugeschnitten sind.\n\n### Compliance-Frameworks und -Kontrollen\n\nKund(inn)en in regulierten Branchen stehen vor großen Herausforderungen bei der Einhaltung der Vorschriften in großen Unternehmen. Manuelle Prozesse sind fehleranfällig, und die konsistente Durchsetzung von Richtlinien über Teams hinweg kann schwierig sein.\n\nDurch die Verwendung der Compliance-Frameworks von GitLab können Unternehmen Präventionsmaßnahmen automatisieren und verwalten, Risiken systematisch verwalten und die Einhaltung gesetzlicher Vorschriften nahtlos durchsetzen. Diese Frameworks können Sicherheitsprotokolle und benutzerdefinierte Jobs in jeder Pipeline erzwingen. \n\nUm die Compliance-Einstellungen auf Organisationsebene zu schützen, ermöglicht GitLab nur Gruppen- oder Projekteigentümer(innen), Compliance Frameworks hinzuzufügen oder zu entfernen. Diese Maßnahme verhindert, dass Entwicklungsteams oder Führungskräfte Compliance-Konfigurationen ohne die entsprechenden Berechtigungsstufen ändern, und bietet auf diese Weise eine zusätzliche Sicherheitsebene. Dabei sollte Folgendes beachtet werden: Wenn Personen mit Betreuerberechtigung eine Untergruppe erstellen können, werden sie zu Eigentümer(innen) der jeweiligen Untergruppe und können das Compliance-Framework ändern. Dies kann verhindert werden, indem [begrenzt wird, welche Personen Untergruppen erstellen können](https://docs.gitlab.com/ee/user/group/subgroups/#change-who-can-create-subgroups), und zwar unter den Berechtigungen und Gruppeneinstellungen.\n\n## SoD durch Berechtigungen und Rollen\n\nUm die Aufgabentrennung in der Finanzdienstleistungsbranche auf effektive Weise durchzusetzen, ist entscheidend, dass eine klare und präzise Zugriffskontrolle etabliert wird. GitLab bietet ein abgestuftes [Berechtigungsmodell](https://docs.gitlab.com/ee/user/permissions.html) mit vordefinierten Rollen, zum Beispiel Gast, Reporter(in), Entwickler(in), Betreuer(in) und Eigentümer(in). Jede Rolle verfügt über eine bestimmte Reihe von Berechtigungen, damit Personen ihre Aufgaben erfüllen können, ohne Grenzen zu überschreiten, was wiederum zu Interessenskonflikten oder Sicherheitsrisiken führen könnte. GitLab empfiehlt eine entsprechende Zuweisung der jeweiligen Rollen für einen [Zugriff gemäß dem Prinzip der geringsten Privilegien](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/).\n\nWas Unternehmen mit granularen Anforderungen betrifft (dies gilt besonders für alle, die GitLab Ultimate nutzen), bieten [benutzerdefinierte Rollen](https://docs.gitlab.com/ee/user/custom_roles.html) noch mehr Flexibilität. Diese Rollen ermöglichen Unternehmen, spezifische Berechtigungen festzulegen, die ganz auf ihre individuellen Workflows und Compliance-Anforderungen zugeschnitten sind. Dies ist besonders nützlich, wenn es darum geht, die Aufgabentrennung durchzusetzen, da auf diese Weise keine Person unvereinbare Aufgaben ausführen kann.\n\nEin gängiger Anwendungsfall ist die Notwendigkeit einer Bereitstellungsrolle – dies betrifft Personen, die Jobs bereitstellen müssen, aber keinen Zugriff für das Bearbeiten oder Pushen von Code haben sollten. GitLab berücksichtigt diese Anforderung durch den Einsatz von [geschützten Umgebungen](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protecting-environments). Geschützte Umgebungen ermöglichen dir, [Gruppen einzuladen, die zur Bereitstellung von Jobs zugelassen wurden](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#deployment-only-access-to-protected-environments), während die Rolle der Nutzer(innen) auf Reporter(innen) beschränkt wird. Dabei sollte beachtet werden, dass der Bereitstellungsjob auch das Keyword für die Umgebung umfassen sollte. Mit dieser Konfiguration können Nutzer(innen) Jobs bereitstellen, ohne den Code bearbeiten zu können. Damit wird sichergestellt, dass die Compliance-Anforderungen erfüllt werden. \n\nDurch sorgfältige Festlegung und Durchsetzung von Rollen und Berechtigungen können Unternehmen eine sichere und konforme Entwicklungsumgebung schaffen. Wenn du deine Berechtigungen für Nutzer(innen) in einem breiteren Rahmen überprüfen möchtest, kannst du diesen [Bericht für Gruppenmitglieder](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/gitlab-group-member-report) nutzen, um festzustellen, wie viele Mitglieder einer Rolle in deiner Umgebung sind, und die nächsten Schritte entsprechend beurteilen.\n\n## Geschützte Funktionen\nGitLab bietet mehrere „geschützte” Funktionen, mit denen zusätzliche Ebenen für die Kontrolle über deinen Entwicklungsprozess durchgesetzt werden können. Diese Funktionen können entscheidend für die Aufrechterhaltung der SoD sein, sodass nur bestimmte Personen wesentliche Änderungen vornehmen können.\n\n- Geschützte Branches: Ein geschützter Branch beschränkt, welche Personen zum Branch pushen oder zusammenführen oder einen Push erzwingen können. Dies ist besonders vorteilhaft für Branches wie „Main“ oder „Produktion“. So können nur autorisierte Nutzer(innen) Änderungen vornehmen.\n- Geschützte Git-Tags: Diese Tags ermöglichen Kontrolle darüber, welche Personen zur Erstellung von Tags berechtigt sind. Dies verhindert versehentliche Updates oder Löschungen, nachdem das Tag erstellt wurde, sodass die Integrität deiner Versionsverwaltung erhalten bleibt.\n- Geschützte Umgebungen: Der Schutz bestimmter Umgebungen (besonders Produktionen) vor unbefugtem Zugriff ist unerlässlich. In einer geschützten Umgebung können nur Nutzer(innen) mit den entsprechenden Berechtigungen bereitstellen, wodurch die Umgebung vor unbeabsichtigten Änderungen geschützt wird. Dies basiert auf der bereits erwähnten Funktionalität der Bereitstellungsrolle, bei der Personen zwar Jobs bereitstellen, aber den Code nicht bearbeiten können, sodass Compliance und Sicherheit gewährleistet werden.\n- Geschützte Pakete: Mithilfe von Schutzregeln für Pakete wird eingeschränkt, welche Nutzer(innen) Änderungen an deinen Paketen vornehmen können. \nDiese geschützten Funktionen tragen zusammen zur Aufrechterhaltung einer sicheren und konformen Entwicklungsumgebung bei, die mit den Grundsätzen der SoD übereinstimmt.\n\n## Audit Event und Compliance Center\nNachdem wir nun die Approvalrichtlinien, Compliance Frameworks, Rollen und geschützten Funktionen behandelt haben, kommen wir zum letzten Schritt: die Frage, wie du mithilfe von GitLab diese Implementierungen überwachen und überprüfen kannst, um die Einhaltung sicherzustellen. \n\nGitLabs [Audit Events](https://docs.gitlab.com/ee/user/compliance/audit_events.html) bieten Eigentümer(innen) und Administrator(innen) eine detaillierte Aufzeichnung der Aktivitäten und Änderungen, darunter die Aktivität der Nutzer(innen) und Projektänderungen. Diese Protokollierung ist entscheidend, wenn es darum geht, die Aktionen der Nutzer(innen) zu verfolgen und unbefugtes Verhalten zu erkennen. \n\nDas [Streaming von Audit Events](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming.html) verbessert diesen Aspekt zusätzlich, indem es Unternehmen ermöglicht, Audit Events zur Echtzeitanalyse und Alarme an externe Systeme zu streamen. Auf diese Weise werden jegliche Änderungen oder Verstöße erkannt, was wiederum eine schnelle Behebung ermöglicht.\n\nDas [Compliance Center in GitLab](https://docs.gitlab.com/ee/user/compliance/compliance_center/) ist ein zentraler Punkt für die Verwaltung und Überwachung von Compliance-Aktivitäten. Es bietet einen Überblick zum Compliance-Status über diverse Projekte und Gruppen hinweg und zeigt Verstöße gegen die Approvalregeln für Merge Requests oder andere Richtlinien. Administrator(innen) können Probleme direkt beheben und sich vergewissern, dass die vordefinierten Compliance-Standards eingehalten werden. Dieser zentralisierte Ansatz vereinfacht das Compliance-Management, wobei ein hohes Maß an Beaufsichtigung und Kontrolle gewährleistet wird.\n\n> Weitere Informationen von GitLab zu den Themen SoD und Compliance findest du unter [GitLab-Regulierung der Produktrichtung](https://about.gitlab.com/direction/govern/) und der [GitLab-Compliance-Dokumentation](https://docs.gitlab.com/ee/administration/compliance.html). \n\n## Weiterlesen\n\n- [Erfülle regulatorische Standards mit dem Compliance- und Sicherheitsrichtlinien-Management von GitLab](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/) (Englischsprachiger Artikel)\n- [Die Erstellung von GitLab mithilfe von GitLab: Erweiterung unseres Portfolios an Sicherheitszertifizierungen](https://about.gitlab.com/blog/building-gitlab-with-gitlab-expanding-our-security-certification-portfolio/) (Englischsprachiger Artikel)\n- [Der Online-Händler Bol erfüllt die wachsenden Compliance-Anforderungen mit GitLab](https://about.gitlab.com/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab/) (Englischsprachiger Artikel)",[14,683,685,558],"2025-04-22",{"slug":795,"featured":6,"template":688},"finserv-how-to-implement-gitlabs-separation-of-duties-features","content:de-de:blog:finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","Finserv How To Implement Gitlabs Separation Of Duties Features","de-de/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","de-de/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"_path":801,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":802,"content":808,"config":818,"_id":820,"_type":16,"title":821,"_source":18,"_file":822,"_stem":823,"_extension":21},"/de-de/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"ogTitle":803,"schema":804,"ogImage":805,"ogDescription":806,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":807,"title":803,"canonicalUrls":807,"description":806},"GitLab Ultimate vs GitHub Security: Vergleich & Migration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Migrationsleitfaden: GitHub Advanced Security zu GitLab Ultimate\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-05-01\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666187/Blog/Hero%20Images/blog-image-template-1800x945__6_.png","GitLab Ultimate vs GitHub Security 2025: Vergleiche Features, Preise und Vorteile. Plus Schritt-für-Schritt-Anleitung für deine erfolgreiche Migration.","https://about.gitlab.com/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"heroImage":805,"body":809,"authors":810,"updatedDate":811,"date":812,"title":813,"tags":814,"description":817,"category":14},"GitLab ist die umfassendste KI-gestützte DevSecOps-Plattform. Unternehmen können mit dieser Plattform für den gesamten Lebenszyklus der Softwareentwicklung (SDLC) sicherere Software schneller bereitstellen. \n\nGitHub bietet eine Advanced Security-Erweiterung, die zusätzliche Sicherheitsfunktionen in GitHub ermöglicht. Es fehlen jedoch die Tiefe und Breite der Sicherheitsfunktionen, die GitLab nativ bereitstellt. \n\nUnternehmen, die auf GitLab Ultimate migrieren möchten, um ihre Sicherheit in allen Bereichen des SDLC zu verbessern, können diesen Leitfaden verwenden, um die beiden Angebote zu vergleichen. Er kann auch als Tutorial für den Wechsel zur GitLab-Plattform genutzt werden.\n\n**Hinweis**: Dieser Artikel wurde zuletzt im Juni 2025 aktualisiert, um die neuesten Änderungen in GitHubs Produktstrategie zu berücksichtigen.\n\nIn diesem Artikel findest du folgende Kapitel:\n\n– [Ein Vergleich zwischen GitLab Ultimate und GitHub Advanced Security](#a-comparison-between-gitlab-ultimate-and-github-advanced-security)\n– [So migrierst du ein GitHub-Repository zu GitLab](#how-to-migrate-a-github-repository-to-gitlab)\n– [So migrierst du Feature für Feature von GitHub Advanced Security zu GitLab Ultimate](#how-to-migrate-feature-by-feature)\n– [Eine Einführung in die zusätzlichen Sicherheitsfunktionen von GitLab Ultimate](#additional-gitlab-ultimate-security-features)\n\n## Ein Vergleich zwischen GitLab Ultimate und GitHub Advanced Security\n\n[GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/) ist die höchste Abonnementstufe von GitLab für Unternehmen, die sichere Software schneller bereitstellen möchten. GitHub Advanced Security ist eine Erweiterung für GitHub Enterprise und ermöglicht zusätzliche Sicherheitsfunktionen.\n\n\\### Ähnlichkeiten zwischen GitLab Ultimate und GitHub Advanced Security\n\nGitLab Ultimate und GitHub Advanced Security bieten:\n– Statische Anwendungssicherheitstests ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)), Geheimnis- und Abhängigkeitssuche\n– kontextbezogene Intelligenz von Sicherheitslücken und Lösungsberatung \n– eine Liste von Abhängigkeiten oder Software-Stückliste ([SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/))\n– Sicherheitsmetriken und -einblicke\n\n### Unterschiede zwischen GitLab Ultimate und GitHub Advanced Security\n\nWährend sich GitHubs Sicherheitstools verbessert haben (mit Push Protection, die 2024 Millionen von Secrets blockiert hat), bietet GitLab Ultimate weiterhin eine tiefere DevSecOps-Integration mit Funktionen, die in GitHubs eigenständigen Produkten nicht verfügbar sind:\n\n* [Compliance-Frameworks und Audit-Management](https://docs.gitlab.com/ee/user/compliance/compliance_center/)\n* [Sicherheits-Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) über gesamte Gruppen/Organisationen\n* Native [DAST](https://docs.gitlab.com/ee/user/application_security/dast/) und [API-Fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/)\n* Integrierter Workflow für [Schwachstellenmanagement](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/)\n* [Benutzerdefinierte Sicherheitsrichtlinien](https://docs.gitlab.com/ee/user/application_security/policies/) mit [granularen Kontrollen](https://docs.gitlab.com/ee/user/custom_roles.html)\n\nDiese integrierten Funktionen bedeuten, dass Teams weniger Zeit mit dem Wechsel zwischen Tools verbringen und mehr Zeit für die Sicherung ihrer Anwendungen haben.\n\nGitLab Ultimate bietet auch zusätzliche Sicherheits- und Konformitätsfunktionen, Portfolio- und Wertschöpfungskettenmanagement, Unterstützung bei Live-Upgrades und mehr. Weitere Informationen zu diesen zusätzlichen Funktionen findest du in der [GitLab Ultimate-Dokumentation](https://about.gitlab.com/pricing/ultimate/).RetryClaude can make mistakes. Please double-check responses.\n\n### Wichtige Änderungen bei GitHub Advanced Security (2025)\n\nSeit April 2025 hat GitHub Advanced Security in zwei separate Produkte aufgeteilt: Secret Protection (19$/Monat pro aktivem Committer) und Code Security (30$/Monat pro aktivem Committer). Obwohl dieser modulare Ansatz kosteneffektiv erscheinen mag, benötigen Organisationen in der Regel beide Produkte für umfassende Sicherheitsabdeckung, was zu 49$/Monat pro aktivem Committer führt - wodurch GitLab Ultimates einheitlicher Ansatz für Teams, die vollständige Sicherheitsfunktionen benötigen, potenziell wirtschaftlicher ist.\n\nGitHub bietet diese Sicherheitsprodukte nun auch Team-Plan-Kunden ohne Enterprise-Abonnement an. GitLabs integrierte DevSecOps-Plattform bedeutet jedoch, dass Sicherheitsfunktionen vom ersten Tag an nahtlos mit CI/CD, Projektmanagement und anderen Tools zusammenarbeiten - ohne zusätzliche Käufe oder Integrationen. Diese native Integration führt oft zu schnellerer Implementierung und besseren Sicherheitsergebnissen.\n\n## So migrierst du ein GitHub-Repository zu GitLab\n\nGitLab bietet einen integrierten Importer, mit dem du deine GitHub-Projekte entweder von GitHub.com oder GitHub Enterprise nach GitLab importieren kannst. Mit dem Importer kannst du nicht nur das GitHub-Repository nach GitLab migrieren, sondern auch verschiedene andere Objekte, einschließlich Tickets, Beteiligte (Mitglieder) und Pull Requests. Eine vollständige Liste der migrierbaren Daten findest du in der [Dokumentation zum Import von Daten von GitHub](https://docs.gitlab.com/ee/user/project/import/github.html#imported-data). Die Migration wird wie folgt durchgeführt:\n1. Wähle oben in der linken Menüleiste **Neu erstellen (+)** aus.\n2. Wähle im Abschnitt **In GitLab** **Neues Projekt/Repository**aus.\n3. Wähle  **Projekt importieren**  aus.\n\n![Projektauswahl importieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/1-Import-Project.png)\n\n4. Wähle die Schaltfläche **GitHub** aus.\n       – Wenn du GitLab Self-Managed verwendest, musst du [den GitHub-Importer aktivieren](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources).\n       – Beachte, dass andere Importer auf dieselbe Weise initiiert werden können.\n   5. Jetzt kannst du einen der folgenden Schritte ausführen:\n       – Autorisiere dich mit GitHub Oauth, indem du **Mit GitHub autorisieren** auswählst.\n       – Verwende einen persönlichen GitHub-Zugriffstoken:\n          – Gehe zu \u003Chttps://github.com/settings/tokens/new>.\n          – Gib im Feld **Hinweis** eine Token-Beschreibung ein.\n          – Wähle den **Repo**-Geltungsbereich aus.\n          – Um Beteiligte zu importieren, wähle optional den Geltungsbereich **read:org** aus.\n          – Wähle die Schaltfläche **Token generieren** aus.\n          – Füge auf der GitLab-Importseite im Feld „Persönlicher Zugriffstoken“ den persönlichen GitHub-Zugriffstoken ein.\n5. Wähle die Schaltfläche **Authentifizieren** aus.\n6. Wähle die Elemente aus, die du migrieren möchtest.\n7. Wähle die Projekte aus, die du migrieren möchtest, und wohin du sie migrieren möchtest.\n8. Wähle die Schaltfläche **Importieren** aus.\n\nDein importiertes Projekt sollte sich nun in deinem Arbeitsbereich befinden. Weitere Informationen über die Migration von GitHub zu GitLab findest du in diesem Video:\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=HEpZVy94cpfPfAky\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nDu kannst die Migration auch mit einem [persönlichen GitHub-Zugriffstoken](https://docs.gitlab.com/ee/user/project/import/github.html#use-a-github-personal-access-token) oder der [GitLab REST API(https://docs.gitlab.com/ee/user/project/import/github.html#use-the-api) durchführen. Der Importer ermöglicht auch den Import aus anderen Quellen wie Bitbucket oder Gitea. Weitere Informationen findest du in der [Importer-Dokumentation](https://docs.gitlab.com/ee/user/project/import/).\n\n\\## So migrierst du Funktion für Funktion\n\nIm Folgenden erfährst du, wie du die einzelnen Funktionen von GitHub Advanced Security in GitLab Ultimate nutzen kannst. Du benötigst eine [GitLab Ultimate-Lizenz](https://about.gitlab.com/pricing/ultimate/), um fortzufahren. GitLab bietet eine [kostenlose 30-Tage-Testversion](https://about.gitlab.com/free-trial/devsecops/), um dir den Einstieg zu erleichtern.\n\n### Scannen von Code\n\nMit dem Scannen von Code bietet GitLab kontextbezogene Intelligenz von Sicherheitslücken und Ratschläge für statischen Quellcode. Das Gleiche kannst du in GitLab erreichen, indem du [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) aktivierst. GitLab SAST-Scanner decken ein breiteres Spektrum an Programmiersprachen und Frameworks ab als [CodeQL](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql#about-codeql) von GitHub.\n\nUm das Scannen von Code in GitLab zu aktivieren, kannst du einfach die [SAST-Vorlage](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) zu deiner ‚.gitlab-ci.yml‘ hinzufügen:\n\n```yaml\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\nSobald die Vorlage hinzugefügt wurde, erkennt SAST automatisch jedes Mal, wenn neuer Code eingecheckt wird, die [Programmiersprachen](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks), die in deinem Projekt verwendet werden. Es scannt dann den Quellcode nach bekannten Schwachstellen.\n\n**Hinweis:** Sicherheitsscanner können deinem Projekt auch mithilfe der \\[Sicherheitskonfiguration] von GitLab (https://docs.gitlab.com/ee/user/application_security/configuration/) hinzugefügt werden. Diese kann automatisch einen Merge Request erstellen, um deine Pipeline zu aktualisieren. Weitere Informationen findest du in der [Dokumentation zum Konfigurieren von SAST mithilfe der UI](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-by-using-the-ui).\n\nDie SAST-Ergebnisse zwischen dem Feature-Branch und der Zielbranch werden im Merge-Request-Widget angezeigt. Das Merge Request-Widget zeigt SAST-Ergebnisse und -Auflösungen an, die durch die Änderungen im Merge Request eingeführt wurden.\n\n![Sicherheits-Scanning in Merge Request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/2-SAST-MR-View.png)\n\nJede Sicherheitslücke zeigt Daten an, die bei der Behebung helfen, einschließlich detaillierter Beschreibung, Schweregrad, Standort und Lösungsinformationen:\n\n![SAST-Sicherheitslückendetails](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/3-SAST-MR-View-Detailed.png)\n\nDu kannst Maßnahmen gegen diese Sicherheitslücken ergreifen:\n\n– **Sicherheitslücke ignorieren**: Ermöglicht es Entwickler(inne)n, die Sicherheitslücke mit einem Kommentar zu ignorieren. Dies unterstützt das Sicherheitsteam bei der Durchführung einer Review.\n– **Ticket erstellen**: Ermöglicht das Erstellen eines Tickets, um eine Sicherheitslücke zu verfolgen, die eine zusätzliche Überwachung erfordert.\n\nDiese Änderungen sind auch inline sichtbar, wenn du innerhalb des Merge Request zur Ansicht **Änderungen** wechselst.\n\n![SAST-Änderungsansicht für Sicherheitslücken](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/4-SAST-MR-View-Changes.png)\n\n#### Anpassen von SAST-Scannern\n\nMit GitLab kannst du eine SAST-Jobdefinition überschreiben und Eigenschaften wie Variablen, Abhängigkeiten oder Regeln ändern. Dazu musst du einen Job mit demselben Namen erstellen, wie der SAST-Job, den du überschreiben willst. Platziere dann diesen neuen Job nach dem Einfügen der Vorlage und gib alle zusätzlichen Schlüssel darunter an.\n\nEin Beispiel ist die folgende Konfiguration:\n– überschreibt die Version, die der ‚semgrep-sast‘-Scanner verwendet\n– führt ein Skript aus, um Module aus privaten Projekten abzurufen, bevor ‚gosec-sast‘ ausgeführt wird \n– konfiguriert alle Scanner so, dass sie in einer maximalen Tiefe von 10 suchen\n\n```yaml\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n\nvariables:\n  SEARCH_MAX_DEPTH: 10\n\nsemgrep-sast:\n  variables:\n    SAST_ANALYZER_IMAGE_TAG: \"3.7\"\n\ngosec-sast:\n  before_script:\n    - |\n      cat \u003C\u003CEOF > ~/.netrc\n      machine gitlab.com\n      login $CI_DEPLOY_USER\n      password $CI_DEPLOY_PASSWORD\n      EOF\n```\n\n**Hinweis:** Die verfügbaren SAST-Jobs findest du in der [Vorlage ‚SAST.gitlab-ci.yml‘](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml). Konfigurationen findest du in der [Dokumentation für verfügbare SAST CI/CD Variablen](https://docs.gitlab.com/ee/user/application_security/sast/#available-cicd-variables).\n\n#### Anpassen von SAST-Regelsätzen\n\nFür jeden SAST-Analysator verarbeitet GitLab den Code und verwendet dann Regeln, um mögliche Schwachstellen im Quellcode zu finden. Diese Regeln bestimmen, welche Arten von Schwachstellen der Scanner meldet.\n\n– Für Semgrep-basierte SAST-Scanner erstellt, pflegt und unterstützt GitLab die verwendeten Regeln. Es kombiniert die Open-Source-Engine Semgrep, von GitLab verwaltete Erkennungsregeln und die proprietäre Technologie von GitLab für das Verfolgen von Sicherheitslücken und die Erkennung von falschen positiven Ergebnissen.\n– Für andere SAST-Analysatoren werden die Regeln in den Upstream-Projekten für jeden Scanner definiert.\n\nDu kannst das Verhalten der SAST-Scanner anpassen, indem du eine Regelsatz-Konfigurationsdatei im gescannten Repository definierst:\n– Vordefinierte Regeln deaktivieren (für alle Analysatoren verfügbar)\n– Vordefinierte Regeln überschreiben (für alle Analysatoren verfügbar)\n– Vordefinierte Regeln ersetzen, indem du eine benutzerdefinierte Konfiguration mithilfe von Passthroughs synthetisierst\n\nWeitere Informationen und Beispiele zum Konfigurieren von SAST-Regeln findest du in den [SAST-Regeln](https://docs.gitlab.com/ee/user/application_security/sast/rules.html) und in der [Dokumentation zum Anpassen von Regelsätzen](https://docs.gitlab.com/ee/user/application_security/sast/customize_rulesets.html).\n\n### Geheimnissuche\n\nDas GitHub-Feature Geheimnissuche findet, blockiert und widerruft durchgesickerte Geheimnisse. Das Gleiche kannst du in GitLab erreichen, indem du die Funktion [Erkennung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/) aktivierst.\n\nUm die Erkennung von Geheimnissen in GitLab zu aktivieren, kannst du einfach die folgende Vorlage zu deiner ‚.gitlab-ci.yml‘ hinzufügen:\n\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n```\n\nSobald die Vorlage hinzugefügt wurde, scannt der Geheimnisscanner jedes Mal, wenn neuer Code eingecheckt wird (oder eine Pipeline ausgeführt wird), den Quellcode auf bekannte Geheimnisse. Je nach Situation scannt die Erkennung von Geheimnissen für Pipelines verschiedene Aspekte deines Codes. Für alle Methoden außer dem „Standard-Branch“ scannt die Erkennung von Geheimnissen für Pipelines Commits, nicht den Arbeitsbaum. Weitere Informationen zur Geheimnissuche findest du in der [Dokumentation zur Erkennung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#coverage).\n\nWenn du einen Merge Request erstellst, scannt die Funktion Erkennung von Geheimnissen jeden Commit, der im Quellbranch vorgenommen wurde. Genau wie in SAST liefert jede erkannte Sicherheitslücke die folgenden Informationen (z. B. Standort) und Bezeichner, um den Behebungsprozess zu unterstützen:\n\n![Sicherheitslückendetails für die Erkennung von Geheimnissen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/5-Secret-Detection-MR-Detailed.png)\n\nÄhnlich wie bei SAST kannst du Maßnahmen gegen diese Sicherheitslücken direkt aus der Merge Request heraus ergreifen, einschließlich des Ignorierens von Sicherheitslücken und des Erstellens von Tickets.\n\n#### Anpassen von Jobs der Erkennung von Geheimnissen\n\nMit GitLab kannst du eine Jobdefinition der Erkennung von Geheimnissen überschreiben, sodass du Eigenschaften wie Variablen, Abhängigkeiten oder Regeln ändern kannst. Dazu musst du einen Job mit demselben Namen erstellen, wie der Job zur Erkennung von Geheimnissen, den du überschreiben willst. Platziere dann diesen neuen Job nach dem Einfügen der Vorlage und gib alle zusätzlichen Schlüssel darunter an. Ein Beispiel ist die folgende Konfiguration:\n\n– überschreibt die Phase, auf der der Job zur Erkennung von Geheimnissen ausgeführt wird, zu  ‚security‘\n– ermöglicht Verlaufsscans\n– ändert die Analysatorversion für Geheimnisse auf 4.5\n\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n\nsecret_detection:\n  stage: security\n  variables:\n    SECRET_DETECTION_HISTORIC_SCAN: \"true\"\n    SECRETS_ANALYZER_VERSION: \"4.5\"\n```\n\n**Hinweis:** Die verfügbaren Jobs zur Erkennung von Geheimnissen findest du in der [Vorlage SAST.gitlab-ci.yml](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml). Verfügbare Konfigurationen findest du in der [Dokumentation zu verfügbaren CI/CD-Variablen der Erkennung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#customizing-analyzer-settings).\n\n#### Anpassen von Regeln für die Erkennung von Geheimnissen\n\nMit dem Analysator für die Erkennung von Geheimnissen kannst du anzupassen, welche Geheimnisse in der GitLab-UI gemeldet werden. Die folgenden Anpassungsoptionen können einzeln oder in Kombination verwendet werden:\n\n– vordefinierte Regeln deaktivieren\n– vordefinierte Regeln überschreiben\n– eine benutzerdefinierte Konfiguration synthetisieren\n– eine Remote-Konfigurationsdatei spezifizieren\n\nWenn du zum Beispiel die Datei ‚.gitlab/secret-detection-ruleset.toml‘ im Stammverzeichnis deines Projekts erstellst, wird das Standard-GitLeaks-Paket erweitert, sodass Testtoken von der Erkennung ausgeschlossen werden:\n\n```yaml\n### extended-gitleaks-config.toml\ntitle = \"extension of gitlab's default gitleaks config\"\n\n[extend]\n### Extends default packaged path\npath = \"/gitleaks.toml\"\n\n[allowlist]\n  description = \"allow list of test tokens to ignore in detection\"\n  regexTarget = \"match\"\n  regexes = [\n    '''glpat-1234567890abcdefghij''',\n  ]\n```\n\nWeitere Informationen zum Überschreiben der vordefinierten Analysatorregeln findest du in der [Dokumentation zur Erkennung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#override-predefined-analyzer-rules).\n\n#### Automatische Reaktion auf durchgesickerte Geheimnisse\n\nDie Funktion zur Erkennung von Geheimnissen von GitLab reagiert automatisch, wenn sie bestimmte Arten von durchgesickerten Geheimnissen findet. Automatische Antworten können:\n– das Geheimnis automatisch widerrufen\n– den Partner, der das Geheimnis ausgestellt hat, benachrichtigen; der Partner kann dann das Geheimnis widerrufen, seine(n) Eigentümer(in) benachrichtigen oder sich auf andere Weise vor Missbrauch schützen\n\nGitLab kann Partner auch benachrichtigen, wenn von ihnen ausgestellte Anmeldeinformationen in öffentlichen Repositorys auf GitLab.com durchgesickert sind. Wenn du ein Cloud- oder SaaS-Produkt betreibst und diese Benachrichtigungen erhalten möchtest, kannst du eine Partner-API implementieren, die von der GitLab Token Revocation API aufgerufen wird.\n\nWeitere Informationen findest du in der [Dokumentation zu automatischen Antworten für durchgesickerte Geheimnisse](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html).\n\n### Sicherheit der Lieferkette\n\nMit GitHub kannst du Software-Lieferketten mit automatisierten Sicherheits- und Versionsaktualisierungen und SBOMs mit einem Klick sichern, verwalten und Berichte darüber erstellen. GitLab kann deine Sicherheitsbedürfnisse in der Lieferkette mithilfe der Funktionen der Abhängigkeitssuche und der Liste der Abhängigkeiten (SBOM) erfüllen.\n\nUm das Scannen von Abhängigkeiten in GitLab zu aktivieren, kannst du einfach die folgende Vorlage zu deiner ‚.gitlab-ci.yml‘ hinzufügen:\n\n```yaml\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n```\n\nSobald die Vorlage hinzugefügt wurde erkennt die Abhängigkeitssuche jedes Mal, wenn neuer Code eingecheckt wird, automatisch die [Paketmanager](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers), die in deinem Projekt verwendet werden. Sie scannt dann die verwendeten Abhängigkeiten auf bekannte Schwachstellen.\n\nDie Ergebnisse der Abhängigkeitssuche zwischen dem Feature-Branch und dem Zielbranch werden im Merge-Request-Widget angezeigt. Das Merge-Request-Widget zeigt die Ergebnisse der Abhängigkeitssuche, die durch die Änderungen im Merge Request eingeführt wurden, und schlägt Lösungen vor. Innerhalb eines Merge Request werden für jede Sicherheitslücke relevante Informationen angezeigt, die bei der Behebung hilfreich sind, wie Bezeichner, Beweise und Lösungen:\n\n![Sicherheitslückendetails der Abhängigkeitssuche](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/6-Dependency-Scanner-MR-View-Detailed.png)\n\nÄhnlich wie bei SAST und der Erkennung von Geheimnissen kannst du Maßnahmen gegen diese Sicherheitslücken direkt aus dem Merge Request heraus ergreifen. Dazu gehören das Ignorieren von Sicherheitslücken und das Erstellen von Tickets.\n\n#### Konfigurieren der Abhängigkeitssuche\n\nUm eine Jobdefinition zu überschreiben (z. B. um Eigenschaften wie Variablen oder Abhängigkeiten zu ändern), erstellst du einen neuen Job mit dem gleichen Namen wie den, den du überschreiben willst. Platziere dann diesen neuen Job nach dem Einfügen der Vorlage und gib alle zusätzlichen Schlüssel darunter an. Ein Beispiel ist der folgende Code:\n\n– deaktiviert die automatische Behebung anfälliger Abhängigkeiten\n– erfordert einen Build-Job, der vor der Abhängigkeitssuche abgeschlossen werden muss\n\n```yaml\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n\ngemnasium-dependency_scanning:\n  variables:\n    DS_REMEDIATE: \"false\"\n  dependencies: [\"build\"]\n```\n\nWeitere Informationen zur Konfiguration der Abhängigkeitssuche findest du in der [Dokumentation zum Anpassen des Verhaltens des Analysators](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#customizing-analyzer-behavior).\n\n#### Das Generieren eines SBOM\n\nGitLab bietet eine Liste der Abhängigkeiten (Dependency List, SBOM), mit der du die Abhängigkeiten deines Projekts oder deiner Gruppe sowie wichtige Details zu diesen Abhängigkeiten, einschließlich ihrer bekannten Sicherheitslücken, überprüfen kannst. Diese Liste ist eine Ansammlung von Abhängigkeiten in deinem Projekt, einschließlich bestehender und neuer Resultate. Die Liste der Abhängigkeiten wird generiert, nachdem die Abhängigkeitssuche erfolgreich auf dem [Standard-Branch](https://docs.gitlab.com/ee/user/project/repository/branches/default.html) ausgeführt wurde. So greifst du auf die Liste der Abhängigkeiten zu:\n\n1. Wähle in der linken Seitenleiste **Suchen oder aufrufen** aus und suche nach deinem Projekt.\n2. Wähle **Sicher > Liste der Abhängigkeiten** aus.\n\n![Liste der Abhängigkeiten (SBOM)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/7-Dependency-List.png)\n\nHier findest du die folgenden Informationen zu deinen Abhängigkeiten:\n\n| Feld                     | Beschreibung                                                                                                                                                                                                                                                                                                                                                                             |\n| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Komponente               | Name und Version der Abhängigkeit.                                                                                                                                                                                                                                                                                                                                                       |\n| Paketerstellungs-Manager | Der Paketerstellungs-Manager, mit dem die Abhängigkeit installiert wurde.                                                                                                                                                                                                                                                                                                                |\n| Standort                 | Bei Systemabhängigkeiten wird das gescannte Image aufgelistet. Bei Anwendungsabhängigkeiten wird hier ein Link zu der für den Paketerstellungs-Manager spezifischen Lock-Datei in deinem Projekt angezeigt, in der die Abhängigkeit deklariert ist. Hier wird auch der Abhängigkeitspfad zu einer übergeordneten Abhängigkeit angegeben, falls diese vorhanden ist und unterstützt wird. |\n| Lizenz                   | Links zu den Softwarelizenzen der Abhängigen. Ein Warnhinweis, der die Anzahl der in der Abhängigkeit erkannten Sicherheitslücken enthält.                                                                                                                                                                                                                                               |\n| Projekte                 | Link zum Projekt mit der Abhängigkeit. Wenn mehrere Projekte die gleiche Abhängigkeit haben, wird die Gesamtzahl der Projekte angezeigt. So öffnest du ein Projekt mit dieser Abhängigkeit: Wähle die Projektnummer aus, suche dann nach dem Namen und wähle ihn aus. Die Projektsuche wird nur bei Gruppen unterstützt, die maximal 600 Einträge in ihrer Gruppenhierarchie haben.      |\n\n\u003Cp>\u003C/p>\n\nWeitere Informationen findest du in der [Dokumentation zur Liste der Abhängigkeiten](https://docs.gitlab.com/ee/user/application_security/dependency_list/).\n\n### Sicherheits- und Konformitätsverwaltung\n\nMit GitHub Advanced Security kannst du Sicherheitsmetriken und -einblicke anzeigen und das Sicherheitsrisiko von Code bewerten. Wir sehen uns jetzt an, wie man das gleiche mit GitLab Ultimate macht.\n\n#### Anzeigen von Sicherheitsmetriken und -einblicken\n\nGitLab bietet [Sicherheits-Dashboards](https://docs.gitlab.com/ee/user/application_security/security_dashboard/), mit denen du den Sicherheitsstatus deiner Anwendungen bewerten kannst. Diese Dashboards zeigen eine Sammlung von Metriken, Bewertungen und Diagrammen für die von den Sicherheitsscannern in deinem Projekt erkannten Sicherheitslücken:\n\n– Sicherheitslückentrends über einen Zeitraum von 30, 60 oder 90 Tagen für alle Projekte in einer Gruppe\n– eine Einstufung für jedes Projekt nach der Schwere der Sicherheitslücke\n– die Gesamtzahl der in den letzten 365 Tagen entdeckten Sicherheitslücken, einschließlich ihres Schweregrads\n\nSo greifst du auf das Sicherheits-Dashboard zu:\n\n1. Wähle in der linken Menüleiste **Suchen oder aufrufen** und suche nach deinem Projekt oder deiner Gruppe.\n2. Wähle auf dem seitlichen Tab das Dashboard **Sicher > Sicherheit** aus.\n3. Filtere und suche nach dem, was du brauchst.\n\nDie Gruppenansicht zeigt deine Sicherheitslage für alle Projekte in deiner Gruppe an:\n\n![Dashboard Gruppensicherheit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/8-SD-Group.png)\n\nDie Projektansicht zeigt deine Sicherheitslage nur für das Projekt an:\n\n![Dashboard Projektsicherheit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/9-SD-Project.png)\n\n#### Beurteile das Sicherheitsrisiko des Codes\n\nGitLab Ultimate verfügt über einen [Sicherheitslückenbericht](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/), der Informationen über Sicherheitslücken aus Scans des Standard-Branchs enthält. Er enthält kumulative Ergebnisse aller erfolgreichen Jobs, unabhängig davon, ob die Pipeline erfolgreich war. Der Sicherheitslückenbericht enthält auf allen Ebenen:\n\n– Die Gesamtanzahl der Sicherheitslücken pro Schweregrad\n– Filter für gängige Attribute für Sicherheitslücken\n– Details zu jeder Sicherheitslücke, dargestellt in einem tabellarischen Layout\n\n![Sicherheitslückenbericht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/10-Vulnerability-Report.png)\n\nWenn du auf eine Sicherheitslücke klickst, gelangst du zur [Seite der Sicherheitslücke](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/), die Details zu der Sicherheitslücke enthält, wie z. B. eine Beschreibung, den Ort, die Bezeichner und mehr. Nachfolgend findest du ein Beispiel für die Seite einer SQL Injection-Sicherheitslücke, die von unserem SAST-Scanner erkannt wurde:\n\n![Seite einer SQL Injection-Sicherheitslücke](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/11-Vulnerability-Page-1.png)\n\nAuf dieser Seite kann das Sicherheitsteam zusammenarbeiten, indem es [den Status einer Sicherheitslücke](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#change-the-status-of-a-vulnerability) zusammen mit einer Begründung ändert und [Tickets erstellt, um Änderungen besser verfolgen zu können](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#create-a-gitlab-issue-for-a-vulnerability).\n\nAuf der Seite der Sicherheitslücke kannst du auch [GitLab Duo](https://about.gitlab.com/gitlab-duo/), unsere KI-gestützte Suite von Funktionen, nutzen. Es kann dir die Sicherheitslücke erklären und [automatisch einen Merge Request für die Behebung der Sicherheitslücke erstellen](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution).\nDie \\[Erklärung der Sicherheitslücke] von GitLab Duo (https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-explanation) verwendet ein umfangreiches Sprachmodell, um:\n\n– Die Sicherheitslücke zusammenzufassen\n– Entwickler(inne)n und Sicherheitsanalyst(inn)en zu helfen, die Sicherheitslücke zu verstehen und wie sie ausgenutzt und behoben werden kann,\n– Eine vorgeschlagene Abhilfemaßnahme vorzuschlagen\n\n![Erklärung einer SQL Injection von der GitLab Duo-KI](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/13-Explain-Vulnerability.png)\n\n## Zusätzliche GitLab Ultimate-Sicherheitsfunktionen\n\nGitLab Ultimate enthält viele weitere Sicherheitsfunktionen, die in GitHub Advanced Security nicht vorhanden sind. Einige Beispiele für diese zusätzlichen Sicherheitsfunktionen sind: zusätzliche Sicherheitsscanner für den gesamten Lebenszyklus der Softwareentwicklung (SDLC), granulare Sicherheitsleitlinien und benutzerdefinierte Berechtigungen.\n\n### Sicherheitsscanner für den gesamten SDLC\n\nUnser Portfolio an Sicherheitsscannern erstreckt sich über den kompletten SDLC.\n\n| Name des Scanners                                                                                                   | Scans                                            | Gescannte Sprachen/Dateien                            |\n| ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ | ----------------------------------------------------- |\n| [Statische Anwendungssicherheitstests (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)           | Statischer Quellcode                             | C/C++, Java, Python, Go, JavaScript, C# und weitere   |\n| [Dynamische Anwendungssicherheitstests (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)          | Ausgeführte Webanwendung, Live-API               | Sprachunabhängig                                      |\n| [Scannen von Infrastructure as Code (IaC)](https://docs.gitlab.com/ee/user/application_security/iac_scanning/)      | IaC-Dateien                                      | Terraform, AWS Cloud Formation, Ansible, und weitere  |\n| [Container-Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/)                      | Statische und ausgeführte Container-Images       | Dockerfile                                            |\n| [Abhängigkeitssuche und Lizenz-Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) | Anwendungsabhängigkeiten                         | Requirements.txt, Yarn, Gradle, Npm und weitere       |\n| [Web-API-Fuzz-Testing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/)                           | Sendet zufällige/falsche Daten an die Web-API    | OpenAPI, GraphQL, HAR, Postman Collection             |\n| [Abdeckungsgesteuertes Fuzz-Testing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/)        | Sendet zufällige/fehlerhafte Daten an Funktionen | C/C++, Go, Swift, Python, Rust, Java, JavaScript, AFL |\n\n\u003Cp>\u003C/p>\n\nGitLab ermöglicht auch die Integration von [Drittanbieter-Scannern](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/) und [benutzerdefinierten Scannern](https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab/) in die Plattform. Nach der Integration werden die Scannerergebnisse automatisch an verschiedenen Stellen in GitLab angezeigt, z. B. in der Pipeline-Ansicht, im Merge-Request-Widget und im Sicherheits-Dashboard. Weitere Informationen findest du in der [Dokumentation zur Integration von Sicherheitsscannern](https://docs.gitlab.com/ee/development/integrations/secure.html).\n\n### Granulare Sicherheits- und Konformitätsrichtlinien\n\nMit den Richtlinien in GitLab können Sicherheits- und Konformitätsteams [Kontrollen weltweit in ihrem Unternehmen durchsetzen](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/). Sicherheitsteams können Folgendes sicherstellen:\n\n– Sicherheitsscanner werden in den Pipelines des Entwicklungsteams mit der richtigen Konfiguration durchgesetzt.\n– Alle Scan-Jobs werden ohne Änderungen oder Modifikationen ausgeführt.\n– Ordnungsgemäße Genehmigungen für Merge Requests werden auf der Grundlage der Ergebnisse dieser Befunde erteilt.\n\n![Sicherheitsrichtlinien für Merge Requests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/14-MR-Policy.png)\n\nKonformitätsteams können zentral mehrere Genehmigende für alle Merge Requests erzwingen und sicherstellen, dass verschiedene Einstellungen für Projekte im Rahmen der organisatorischen Anforderungen aktiviert sind, z. B. die Aktivierung oder Sperrung von Merge Requests und Repository-Einstellungen. Weitere Informationen findest du in der [GitLab-Sicherheitsrichtlinie](https://docs.gitlab.com/ee/user/application_security/policies/).\n\n### Benutzerdefinierte Rollen und granulare Berechtigungen\n\n[GitLab Ultimate bietet benutzerdefinierte Rollen](https://about.gitlab.com/blog/how-to-tailor-gitlab-access-with-custom-roles/), mit denen ein Unternehmen Benutzerrollen mit genau den Privilegien und Berechtigungen erstellen kann, die für die Bedürfnisse dieses Unternehmen erforderlich sind.\n\nZum Beispiel könnte ein(e) Benutzer(in) eine „Security Auditor“-Rolle mit Berechtigungen zum Anzeigen von Sicherheitslücken im System erstellen, mit der aber kein Quellcode angezeigt oder Änderungen im Repository vorgenommen werden kann. Dieser granulare Satz von Berechtigungen ermöglicht eine klar definierte Aufgabentrennung.\n\n![Benutzerdefinierte Rollenerstellung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/15-Custom-Roles.png)\n\nWeitere Informationen findest du in den Dokumentationen zu [benutzerdefinierten Rollen](https://docs.gitlab.com/ee/user/custom_roles.html) und [verfügbaren granularen Berechtigungen](https://docs.gitlab.com/ee/user/custom_roles/abilities.html).\n\n### Konformitäts-Center\n\nDas Konformitäts-Center ist der zentrale Ort für Konformitätsteams, um die Konformitätsstandards, die Berichterstattung über Verstöße und die Konformitätsframeworks für ihre Gruppe zu verwalten. Das Konformitäts-Center umfasst Folgendes:\n\n– Das [Dashboard zur Einhaltung von Konformitätsstandards](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_standards_adherence_dashboard.html) listet den Status der Einhaltung von Projekten auf, die dem GitLab-Standard entsprechen.\n– Der [Bericht über Konformitätsverstöße](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_violations_report.html) zeigt eine allgemeine Ansicht der Merge-Request-Aktivität für alle Projekte in der Gruppe.\n– Der [Bericht über Konformitätsframeworks](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_frameworks_report.html) zeigt alle Konformitätsframeworks einer Gruppe.\n– Der [Bericht über Konformitätsprojekte](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_projects_report.html) zeigt die Konformitätsframeworks, die auf Projekte einer Gruppe angewendet werden.\n\n![Konformitäts-Center](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/16-Compliance-Center.png)\n\nMit diesen Dashboards kannst du sicherstellen, dass die Aufgabentrennung eingehalten wird, um die Konformität in deinem Unternehmen zu optimieren. Weitere Informationen findest du in der [Konformitäts-Center-Dokumentation](https://docs.gitlab.com/ee/user/compliance/compliance_center/).\n\n## Weiterlesen\n\nDieser Artikel behandelt nur einen Teil des breiten Spektrums an Sicherheitsfunktionen, die GitLab Ultimate bietet. Schau dir diese Ressourcen an, um mehr darüber zu erfahren, wie GitLab Ultimate dazu beitragen kann, die Sicherheit deines Unternehmens und die Effizienz deiner Entwickler(innen) zu verbessern:\n\n– [Was spricht für GitLab Ultimate?\n](https://about.gitlab.com/pricing/ultimate/)\n– [Tutorial: Erste Schritte mit DevSecOps](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/)\n– [Beispielprojekt: Erste Schritte mit DevSecOps](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n– [Dokumentation: Importiere dein Projekt von GitHub in GitLab](https://docs.gitlab.com/ee/user/project/import/github.html)\n– [Dokumentation: Migration von GitHub Actions](https://docs.gitlab.com/ee/ci/migration/github_actions.html)\n– [Tutorial: Erstelle deine erste GitLab CI/CD-Pipeline und führe sie aus](https://docs.gitlab.com/ee/ci/quick_start/)\n– [Tutorial: Erstelle eine komplexe Pipeline](https://docs.gitlab.com/ee/ci/quick_start/tutorial.html)\n– [CI/CD-YAML-Syntaxreferenz](https://docs.gitlab.com/ee/ci/yaml/)",[678],"2025-06-24","2024-05-01","GitLab Ultimate vs. GitHub Security: Der vollständige Vergleich und Migrationsleitfaden 2025",[682,815,14,683,816],"zero trust","testing","GitHub hat Advanced Security in zwei teure Einzelprodukte aufgeteilt. Entdecke, wie GitLab Ultimate mehr bietet und spare dabei Geld. Inklusive vollständiger Migrationsanleitung und aktuellem Feature-Vergleich 2025.",{"slug":819,"featured":93,"template":688},"migration-guide-github-advanced-security-to-gitlab-ultimate","content:de-de:blog:migration-guide-github-advanced-security-to-gitlab-ultimate.yml","Migration Guide Github Advanced Security To Gitlab Ultimate","de-de/blog/migration-guide-github-advanced-security-to-gitlab-ultimate.yml","de-de/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"_path":825,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":826,"content":832,"config":838,"_id":840,"_type":16,"title":841,"_source":18,"_file":842,"_stem":843,"_extension":21},"/de-de/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"title":827,"description":828,"ogTitle":827,"ogDescription":828,"noIndex":6,"ogImage":829,"ogUrl":830,"ogSiteName":673,"ogType":674,"canonicalUrls":830,"schema":831},"So integrierst du benutzerdefinierte Sicherheitsscanner in GitLab","Erfahre, wie du die DevSecOps-Plattform erweiterst, indem du benutzerdefinierte Sicherheitsscanner in deine Workflows einfügst (einschließlich Tutorial).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097082/Blog/Hero%20Images/Blog/Hero%20Images/securitycheck_securitycheck.png_1750097081856.png","https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So integrierst du benutzerdefinierte Sicherheitsscanner in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-02-27\",\n      }",{"title":827,"description":828,"authors":833,"heroImage":829,"date":834,"body":835,"category":14,"tags":836,"updatedDate":837},[678],"2024-02-27","GitLab, die umfassendste DevSecOps-Plattform, bietet alles, was du zum Planen, Verwalten, Erstellen, Bereitstellen, Sichern, Steuern und Überwachen deiner Anwendungen brauchst. Dennoch gibt es Fälle, in denen du GitLab mit Tools von Drittanbietern oder eigenen Tools erweitern möchtest. Du musst zum Beispiel von separaten Lösungen auf eine DevSecOps-Plattform migrieren, Tools von Drittanbietern evaluieren oder eigene oder selbst entwickelte Lösungen in GitLab integrieren.\n\n## Folgende Themen werden hier behandelt\n\n- [Erweiterbarkeit der DevSecOps-Plattform von GitLab](#erweiterbarkeit-der-devsecops-plattform-von-gitlab)\n- [Die GitLab-Sicherheitsscanner-Integration](#die-gitlab-sicherheitsscanner-integration)\n - [Sicherheitswidget für Merge Requests](#sicherheitswidget-für-merge-requests)\n - [Pipeline-Sicherheitsbereich](#pipeline-sicherheitsbereich)\n - [Sicherheitslückenbericht](#sicherheitslückenbericht)\n - [Sicherheitslückenseiten](#sicherheitslückenseiten)\n - [Sicherheitsdashboard](#sicherheitsdashboard)\n - [Merge-Request-Approvalrichtlinien-Integration](#merge-request-approvalrichtlinien-integration)\n- [Tutorial: Integration von benutzerdefinierten Sicherheitsscannern](#tutorial-integration-von-benutzerdefinierten-sicherheitsscannern)\n - [Erstellen eines benutzerdefinierten Sicherheitsscanners](#erstellen-eines-benutzerdefinierten-sicherheitsscanners)\n - [Integrieren eines benutzerdefinierten Sicherheitsscanners in GitLab](#integrieren-eines-benutzerdefinierten-sicherheitsscanners-in-gitlab)\n- [Mehr erfahren](#mehr-erfahren)\n\n## Erweiterbarkeit der DevSecOps-Plattform von GitLab\n\nGitLab kann auf viele Arten erweitert werden, um erweiterte Funktionen zu unterstützen, die dein Unternehmen benötigt. Einige gängige Beispiele für diese Integrationen sind:\n\n- externe Anwendungsintegrationen wie Jenkins und Slack\n- externe Integrationen zur Ticketverfolgung wie Bugzilla und Jira\n- externe Integrationen von Authentifizierungsanbietern wie LDAP und SAML\n- externe Integrationen von Sicherheitsscannern wie Fortify und Checkmarx\n- die Möglichkeit, auf durchgesickerte Geheimnisse zu reagieren wie AWS- und GCP-Zugriffsschlüssel\n\nAlle verfügbaren Integrationen findest du in der [Dokumentation zur Integration mit GitLab (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/integration/). (Hinweis: Es sind nicht alle Integrationen in der Dokumentation aufgeführt.)\n\n## Die GitLab-Sicherheitsscanner-Integration\n\n[Sicherheitsscanner von Drittanbietern](https://docs.gitlab.com/ee/integration/#security-improvements) oder [benutzerdefinierte Sicherheitsscanner](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration) können in GitLab integriert werden, um das Widget für Merge Requests, den Pipeline-Sicherheitsbereich, den Sicherheitslückenbericht, die Sicherheitslückenseiten, das Sicherheitsdashboard und die Merge-Request-Approvalrichtlinien zu füllen. Sehen wir uns die einzelnen Integrationen an.\n\n### Sicherheitswidget für Merge Requests\n\nEin Merge Request enthält ein Sicherheitswidget, das eine Zusammenfassung der neu entdeckten Sicherheitslücken anzeigt.\n\n![Integration von Sicherheitsscannern – Bild 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097088837.png)\n\n\u003Ccenter>\u003Ci>Sicherheitswidget für Merge Requests\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nWenn du auf eine Sicherheitslücke klickst, wird ein Popup-Fenster angezeigt, das folgende Informationen enthält:\n- Status\n- Beschreibung\n- Projekt\n- Datei\n- Bezeichner\n- Schweregrad\n- Tool\n- Scanner-Anbieter\n\n![Integration von Sicherheitsscannern – Bild 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097088838.png)\n\n\u003Ccenter>\u003Ci>Sicherheitslücken mit Details, die behoben werden können\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p> \n\nBei diesen Sicherheitslücken kann auch reagiert werden, d. h., du kannst sie entweder ignorieren oder ein vertrauliches Ticket dafür erstellen.\n\nDie Ergebnisse eines benutzerdefinierten Scanners können in das Sicherheitswidget eingefügt werden. Die Daten zu den Sicherheitslücken werden aus dem JSON-Schema, das der Scanner ausgibt, zusammengesetzt.\n\n### Pipeline-Sicherheitsbereich\n\nAlle aktivierten Sicherheitsanalysatoren werden in der Pipeline ausgeführt und geben ihre Ergebnisse als Artefakte aus. Diese Artefakte werden verarbeitet, unter anderem durch Deduplizierung, und die Ergebnisse werden auf der Registerkarte „Pipelinesicherheit“ aufgelistet. Von hier aus kannst du auch die resultierenden JSON-Dateien herunterladen.\n\n![Integration von Sicherheitsscannern – Bild 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097088840.png)\n\n\u003Ccenter>\u003Ci>Registerkarte „Pipelinesicherheit“\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nDie Ergebnisse eines benutzerdefinierten Scanners können in die Registerkarte „Pipelinesicherheit“ eingefügt werden. Die Spalten werden anhand des JSON-Schemas, das der Scanner ausgibt, ausgefüllt.\n\n### Sicherheitslückenbericht\n\nDer Sicherheitslückenbericht enthält Informationen zu Sicherheitslücken aus Scans des default-Branch, einschließlich:\n\n- der Gesamtanzahl der Sicherheitslücken pro Schweregrad\n- Filtern für gängige Attribute für Sicherheitslücken\n- Details zu jeder Sicherheitslücke in einer Tabelle\n\n![Integration von Sicherheitsscannern – Bild 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097088842.png)\n\n\u003Ccenter>\u003Ci>Sicherheitslückenbericht\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nDie Ergebnisse eines benutzerdefinierten Scanners für den default-Branch können für den Sicherheitslückenbericht verwendet werden.\n\n### Sicherheitslückenseiten\n\nWenn du im Sicherheitslückenbericht auf eine Sicherheitslücke klickst, gelangst du zur Sicherheitslückenseite. Für jede Sicherheitslücke in einem Projekt gibt es eine Seite, auf der du Details findest, z. B:\n\n- Beschreibung\n- Wann sie erkannt wurde\n- Aktueller Status\n- Wo sie erkannt wurde\n- Verfügbare Aktionen\n- Verknüpfte Tickets\n- Aktionsprotokoll\n- Lösungen\n- Bezeichner\n- Training\n\nDu kannst die Daten auf der Seite mit den Sicherheitslücken nutzen, um eine entdeckte Sicherheitslücke einzugrenzen und sie zu beheben.\n\n![Integration von Sicherheitsscannern – Bild 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097088844.png)\n\n\u003Ccenter>\u003Ci>Sicherheitslückenseite für Sicherheitslücken, bei denen Geheimnisse erkannt wurden\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nDie Ergebnisse eines benutzerdefinierten Scanners können in die Sicherheitslückenseite eingefügt werden. Die Daten zu den Sicherheitslücken werden aus dem JSON-Schema, das der Scanner ausgibt, zusammengesetzt.\n\n### Sicherheitsdashboard\n\nSicherheitsdashboards werden verwendet, um den Sicherheitsstatus deiner Anwendungen zu bewerten. GitLab stellt dir eine Sammlung von Metriken, Bewertungen und Diagrammen für die Sicherheitslücken zur Verfügung, die von den Sicherheitsscannern in deinem Projekt entdeckt wurden. Das Sicherheitsdashboard liefert Daten wie:\n\n- Trends bei Sicherheitslücken über einen Zeitraum von 30, 60 oder 90 Tagen für alle Projekte in einer Gruppe\n- Eine Bewertung in Buchstaben für jedes Projekt, basierend auf dem Schweregrad der Sicherheitslücke\n- Die Gesamtzahl der in den letzten 365 Tagen entdeckten Sicherheitslücken und deren Schweregrad\n\n![Integration von Sicherheitsscannern – Bild 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097088846.png)\n\n\u003Ccenter>\u003Ci>Sicherheitsdashboard auf Gruppenebene\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nIm Sicherheitsdashboard auf Gruppenebene kannst du auf ein Projekt klicken, um auf das spezifische Sicherheitsdashboard zuzugreifen. So erhältst du die 365-Tage-Ansicht.\n\n![Integration von Sicherheitsscannern – Bild 7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097088847.png)\n\n\u003Ccenter>\u003Ci>Sicherheitsdashboard auf Projektebene\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n### Merge-Request-Approvalrichtlinien-Integration\n\nMerge-Request-Approvalrichtlinien werden verwendet, um eine Genehmigung auf der Grundlage der Ergebnisse eines oder mehrerer Sicherheitsscanaufträge zu verlangen. Dies kann verhindern, dass unsicherer Code in die Produktion übernommen wird. Merge-Request-Approvalrichtlinien werden nach der vollständigen Ausführung eines CI-Scanauftrags ausgewertet, wobei die Richtlinien auf der Grundlage der Job-Artefaktberichte, die in der abgeschlossenen Pipeline veröffentlicht werden, bewertet werden.\n\nDu kannst beispielsweise eine Richtlinie für Merge-Request-Approvalrichtlinien erstellen, die die Genehmigung von Projektbetreuer(inne)n erfordert, wenn ein Scanner zur Erkennung von Geheimnissen Sicherheitslücken findet. Das geht so:\n\n1. Wähle in der linken Seitenleiste **Suchen oder aufrufen** aus und suche nach dem Projekt, dem du eine Richtlinie hinzufügen möchtest.\n2. Gehe in der linken Seitenleiste des Projekts zu **Sicherheit > Richtlinien**.\n3. Wähle **Neue Richtlinie** aus.\n4. Wähle im Abschnitt **Merge-Request-Approvalrichtlinien** **Richtlinie auswählen** aus.\n5. Fülle die Felder aus:\n- Name: der Name der Richtlinie\n- Beschreibung: die Beschreibung der Richtlinie\n- Richtlinienstatus: ob sie aktiviert ist oder nicht\n- Regeln: die Bedingungen, die erfüllt sein müssen, damit eine Aktion (Approval erforderlich) ausgeführt wird\n\n![Integration von Sicherheitsscannern – Bild 8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097088849.png)\n\u003Ccenter>\u003Ci>Regeln für Merge-Request-Approvalrichtlinien\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n- Aktionen: die Aktion, die ausgeführt werden soll, wenn die Bedingungen in den Regeln (definierte Schwachstellen/erkannte Lizenzen) erfüllt sind\n\n![Integration von Sicherheitsscannern – Bild 9](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097088850.png)\n\n\u003Ccenter>\u003Ci>Aktionen für Merge-Request-Approvalrichtlinien\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n- Überschreiben von Projekt-Approvaleinstellungen: Wenn diese Option ausgewählt ist, überschreiben die folgenden Optionen die Projekteinstellungen. Dies wirkt sich jedoch nur auf die in der Richtlinie ausgewählten Branches aus.\n\n![Integration von Sicherheitsscannern – Bild 11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097088851.png)\n\n \u003Ccenter>\u003Ci>Einstellungen für Merge-Request-Approvalrichtlinien\u003C/i>\u003C/center>\n \u003Cp>\u003C/p>\n\n6. Klicke auf die Schaltfläche „Mit einem Merge Request konfigurieren“.\n\nSobald die Merge-Request-Approvalrichtlinie zusammengeführt wurde, wird die definierte Aktion ausgelöst, wenn du einen Merge Request erstellst und die in den Regeln definierten Kriterien erfüllt sind. In diesem Fall ist mindestens die Zustimmung einer Person erforderlich, bevor der Code zusammengeführt werden kann.\n\n![Integrierter Sicherheitsscanner – Bild 10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097088852.png)\n\n\u003Ccenter>\u003Ci>Merge Request aufgrund erkannter Sicherheitslücken blockiert\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nDie Ergebnisse eines benutzerdefinierten Scanners können vollständig in die Merge-Request-Approvalrichtlinien integriert werden. Wenn der benutzerdefinierte Scanner eine Sicherheitslücke entdeckt, ist ein Approval erforderlich, bevor der Code zusammengeführt werden kann. Der Scanner, den du in einer Merge-Request-Approvalrichtlinie auswählst, muss das entsprechende JSON-Schema verwenden.\n\n## Tutorial: Integration von benutzerdefinierten Sicherheitsscannern\n\nJetzt kommen wir zum spannenden Teil: der Integration eines benutzerdefinierten Sicherheitsscanners. In diesem Tutorial lernst du, wie du einen benutzerdefinierten Sicherheitsscanner erstellst und wie du ihn in GitLab integrierst. Wir werden die folgenden Projekte nutzen:\n\n- [Fern Pattern Scanner](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/fern-pattern-scanner): Er durchsucht deine Dateien nach bestimmten Mustern wie Passwörtern, privaten Schlüsseln und Sozialversicherungsnummern.\n– [Secret List](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/secret-list): Enthält eine Liste von Benutzerpasswörtern, Clients und Schlüsseln. Dieses Projekt wird verwendet, um zu zeigen, wie ein benutzerdefinierter Sicherheitsscanner in GitLab integriert werden kann.\n\nIm folgenden Video kannst du dir ansehen, wie die Anwendung erstellt wurde und wie sie im Detail verwendet wird:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/timMbl5SP-w?si=R2DKtZ5MmBR1rQFL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Erstellen eines benutzerdefinierten Sicherheitsscanners\n\nJetzt erstellen wir einen benutzerdefinierten Scanner, der in GitLab integriert werden kann. Bevor ein benutzerdefinierter Scanner vollständig in GitLab integriert werden kann, muss der Scanner:\n- Ein Verzeichnis nach definierten Mustern scannen\n- Eine JSON-Datei nach dem entsprechenden Schema ausgeben\n- Containerisiert und zugänglich sein\n- Eine Vorlage bereitstellen, damit er in einem anderen Projekt ausgeführt werden kann\n\nWenn der [Fern Pattern Scanner](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/fern-pattern-scanner) in einem Projekt mit der bereitgestellten Vorlage ausgeführt wird, führt er die folgenden Schritte aus:\n1. Er lädt einen Satz von Regeln, die Muster (Regex) definieren, die erkannt werden sollen.\n- Die Regeln können konfiguriert werden, um den sich ändernden Anforderungen deines Unternehmens gerecht zu werden.\n2. Er scannt Dateien auf definierte Muster.\n3. Er gibt einen JSON-Bericht aus, der dem Schema zur Erkennung von Geheimnissen folgt.\n- In diesem Projekt werden Go-Vorlagen verwendet, um eine JSON-Datei zu erstellen.\n- Stelle sicher, dass du das entsprechende Schema verwendest, je nachdem, wonach dein Scanner sucht.\n\nSobald der JSON-Bericht als Artefakt in GitLab geladen wurde, werden das Merge-Request-Widget, der Sicherheitslückenbericht, die Sicherheitslückenseiten, die Merge-Request-Approvalrichtlinien und die Sicherheitsdashboards wie oben definiert befüllt.\n\n### Integrieren eines benutzerdefinierten Sicherheitsscanners in GitLab\n\nSobald du deinen benutzerdefinierten Scanner erstellt hast, der alle Anforderungen für die Integration erfüllt, kannst du ihn in GitLab ausführen.\n\nDas Ausführen eines benutzerdefinierten Scanners ist so einfach wie das Hinzufügen einer Vorlage. Wir können sehen, wie die Vorlage für den Fern Pattern Scanner geladen wird, indem wir uns die Datei `.gitlab-ci.yml` im Projekt [Secret List](https://gitlab.com/gitlab-da/tutorials/security-and-governance/custom-scanner-integration/secret-list) ansehen.\n\n1. Erstelle eine [.gitlab-ci.yml-Datei (Anleitung nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/quick_start/#create-a-gitlab-ciyml-file) in dem Projekt, in dem du den Scanner ausführen möchtest.\n2. Füge die [Vorlage für einen benutzerdefinierten Scanner](https://docs.gitlab.com/ee/ci/yaml/includes.html) hinzu.\n    - Du solltest die Vorlage auch mit Umgebungsvariablen konfigurieren können.\n3. Committe die Datei in den Main-Branch.\n\nSobald die Datei übergeben wurde, kannst du sehen, dass der benutzerdefinierte Scanner in deiner Pipeline ausgeführt wird. Sobald die Pipeline abgeschlossen ist, befüllt der Scanner alle oben im Abschnitt [Die GitLab-Sicherheitsscanner-Integration](#gitlab-security-scanner-integration) definierten Bereiche.\n\n## Mehr erfahren\n\nIn diesen englischsprachigen Ressourcen erfährst du mehr über GitLab und die anderen Möglichkeiten, wie du deine DevSecOps-Plattform erweitern kannst:\n\n- [GitLab-Integration für Sicherheitsscanner](https://docs.gitlab.com/ee/development/integrations/secure.html)\n- [GitLab-Partnerintegrationen](https://docs.gitlab.com/ee/integration/)\n- [Gruppe für benutzerdefinierte Sicherheitsscanner-Projekte](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration)\n- [Automatische Reaktion auf die Veröffentlichung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html)\n",[682,14,816,683],"2025-06-10",{"slug":839,"featured":93,"template":688},"how-to-integrate-custom-security-scanners-into-gitlab","content:de-de:blog:how-to-integrate-custom-security-scanners-into-gitlab.yml","How To Integrate Custom Security Scanners Into Gitlab","de-de/blog/how-to-integrate-custom-security-scanners-into-gitlab.yml","de-de/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"_path":845,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":846,"content":852,"config":858,"_id":860,"_type":16,"title":861,"_source":18,"_file":862,"_stem":863,"_extension":21},"/de-de/blog/how-gitlab-can-support-your-iso-compliance-journey",{"title":847,"description":848,"ogTitle":847,"ogDescription":848,"noIndex":6,"ogImage":849,"ogUrl":850,"ogSiteName":673,"ogType":674,"canonicalUrls":850,"schema":851},"So unterstützt dich GitLab bei deiner ISO-27001-Compliance","GitLab ist dein strategischer Partner und hilft mit seinen Software-Sicherheitsfunktionen dabei, deine ISO-27001-Compliance sicherzustellen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662877/Blog/Hero%20Images/security-cover-new.png","https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So unterstützt dich GitLab bei deiner ISO-27001-Compliance\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2023-09-06\",\n      }",{"title":847,"description":848,"authors":853,"heroImage":849,"date":854,"body":855,"category":14,"tags":856,"updatedDate":793},[767],"2023-09-06","\nAls eine durchgängige All-Inclusive-Plattform ist es mit GitLab einfach, deinen DevSecOps-Lebenszyklus zu verwalten. Dank der Plattform von GitLab können Entwickler(innen) schneller bessere Software entwickeln. Das ist aber nicht alles, denn GitLab geht über DevSecOps hinaus.\n\nIm Oktober 2022 veröffentlichte die Internationale Organisation für Normung die neueste Version der Norm ISO 27001. ISO/IEC 27001:2022 enthält mehrere Änderungen gegenüber der vorherigen Version, darunter die neuen Control Kategorien aus Anhang A, bei denen es um sicheres Programmieren und Konfigurationsmanagement geht.\n\nWir bei GitLab nutzen unsere Plattform, um viele Aspekte unseres Sicherheitskonformitätsprogramms zu unterstützen – ein Konzept, das wir intern [Dogfooding](https://about.gitlab.com/direction/dogfooding/) nennen. Eine Übersicht über den Nachweis der Einhaltung von Vorschriften und Sicherheit findest du in unserem [Trust Center](https://about.gitlab.com/security/).\n\nSehen wir uns nun die wichtigsten Funktionen an, die du bei deiner ISO-27001-Compliance nutzen kannst.\n\n## Organisatorische Controls\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 5.3 Aufgabentrennung | Widersprüchliche Aufgaben und Verantwortungsbereiche sind zu trennen. |\n| 5.15 Zugriffskontrolle | Regeln zur Kontrolle des physischen und logischen Zugriffs auf Informationen und andere damit verbundene Vermögenswerte müssen auf der Grundlage der Geschäfts- und Informationssicherheitsanforderungen festgelegt und implementiert werden. |\n| 5.16 Identitätsmanagement | Der gesamte Lebenszyklus von Identitäten ist zu verwalten. |\n| 8.2 Privilegierte Zugriffsrechte | Die Vergabe und Nutzung von privilegierten Zugriffsrechten ist einzuschränken und zu verwalten.|\n| 8.4 Zugriff auf Quellcode | Der Lese- und Schreibzugriff auf Quellcode, Entwicklungstools und Softwarebibliotheken ist angemessen zu verwalten. |\n\nMit GitLab kannst du [Benutzer(inne)n eine Rolle zuweisen](https://docs.gitlab.com/ee/user/permissions.html), wenn du sie zu einem Projekt oder einer Gruppe hinzufügst. Die Rolle eines Benutzers/einer Benutzerin legt fest, was er/sie in deiner GitLab-Instanz ausführen kann. Folgende Rollen stehen für die Zuweisung zur Verfügung:\n* Gast (nur private und interne Projekte)\n* Reporter(in)\n* Entwickler(in)\n* Betreuer(in)\n* Eigentümer(in)\n* Minimaler Zugriff (nur für die Hauptgruppe verfügbar)\n\nMit den Rollen von GitLab kannst du die Berechtigungen eines Benutzers/einer Benutzerin gemäß dem [Prinzip der geringsten Privilegien](https://csrc.nist.gov/glossary/term/least_privilege) und deinen Geschäfts- und Informationssicherheitsanforderungen einschränken.\n\nAußerdem kannst du dank GitLab die Authentifizierungs- und Autorisierungsverantwortlichkeiten für deine GitLab-Instanz über [SAML-SSO-Integrationen](https://docs.gitlab.com/ee/user/group/saml_sso/) zentralisieren. GitLab lässt sich in eine Vielzahl von Identitätsanbietern integrieren, um die verschiedenen Technologie-Stacks unserer Kund(inn)en zu unterstützen. GitLab unterstützt auch das System für domänenübergreifendes Identitätsmanagement ([SCIM](https://docs.gitlab.com/ee/user/group/saml_sso/scim_setup.html)). Durch die SSO- und SCIM-Integrationen von GitLab kannst du den Lebenszyklus deiner Benutzeridentitäten sicher und effizient automatisieren.\n\n[SSO](https://docs.gitlab.com/ee/integration/saml.html) und [SCIM](https://docs.gitlab.com/ee/administration/settings/scim_setup.html) sind auch für selbstverwaltete Kund(inn)en von GitLab verfügbar.\n\n**Hinweis:** Die technologischen Controls 8.2 und 8.4 in Anhang 8 wurden aufgrund ihrer Nähe zu den organisatorischen Controls 5.3, 5.15 und 5.16 in die oben stehende Tabelle aufgenommen. Für die Anforderungen dieser Controls können die gleichen GitLab-Funktionen angewendet werden.\n{: .note}\n\n\u003Cbr>\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 5.8 Informationssicherheit im Projektmanagement | Informationssicherheit ist in das Projektmanagement zu integrieren. |\n\nMit GitLab kannst du unsere [Planungstools](https://about.gitlab.com/features/?stage=plan) für dein Projektmanagement nutzen und so sicherstellen, dass die Informationssicherheit in allen Phasen eines Projektlebenszyklus eingehalten wird.\n\n- Mit der [Teamplanung](https://about.gitlab.com/features/?stage=plan#team_planning) von GitLab können Benutzer(innen) Projektarbeiten von der Idee bis zur Produktion organisieren, planen, abstimmen und nachverfolgen.\n\n- [Epics](https://docs.gitlab.com/ee/user/group/epics/), [Tickets](https://docs.gitlab.com/ee/user/project/issues/) und [Aufgaben](https://docs.gitlab.com/ee/user/tasks.html) können verwendet werden, um gemeinsam an Ideen zu arbeiten, Probleme zu lösen und Arbeiten mit deinem Informationssicherheitsteam zu planen. [Beschreibungsvorlagen](https://docs.gitlab.com/ee/user/project/description_templates.html) und [Checklisten](https://docs.gitlab.com/ee/user/markdown.html#task-lists) ermöglichen es den Benutzer(inne)n, konsistente Beschreibungen und Workflows für Tickets oder [Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/index.html) einzuhalten. Mit diesen Vorlagen kann die Informationssicherheit konsistent in deinen Projektmanagement-Lebenszyklus integriert werden.\n\n- [Labels](https://docs.gitlab.com/ee/user/project/labels.html) ermöglichen es Benutzer(inne)n, Probleme so zu organisieren, wie sie es für richtig halten. Im Hinblick auf die Informationssicherheit können Label verwendet werden, um die Risikostufe eines Projekts zu identifizieren, die Phase eines Projekts anzugeben oder das Informationssicherheitsteam zu markieren, das für eine bestimmte Arbeit zuständig ist. [Labels mit begrenztem Geltungsbereich](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) können verwendet werden, um Workflows weitere Logik hinzuzufügen. Sie verhindern nämlich, dass bestimmte Labels zusammen verwendet werden. Bei GitLab nutzen wir [Labels mit begrenztem Geltungsbereich](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels), um die Arbeit, die verschiedenen Teams zugewiesen ist, die Projektphase, in der sich die Arbeit befindet, und das Produkt oder den Funktionsumfang, der mit der Arbeit verbunden ist, zu identifizieren.\n\n![Labels mit begrenztem Geltungsbereich](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/scoped-labels.png)\n\nLabels mit begrenztem Geltungsbereich\n{: .note.text-center}\n\n- Mit [Gruppen-](https://docs.gitlab.com/ee/user/project/issue_board.html#group-issue-boards) und [Projekt-](https://about.gitlab.com/stages-devops-lifecycle/issueboard/)-Issue-Übersichten kannst du deine Arbeit noch besser organisieren und eine zentrale, zusammengefasste Ansicht für alle mit einer Gruppe oder einem Projekt verbundenen Arbeiten bieten.\n\n## Technologische Controls\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 8.8 Management technischer Sicherheitslücken | Informationen über technische Sicherheitslücken der verwendeten Informationssysteme sind einzuholen, die Exposition des Unternehmens gegenüber solchen Sicherheitslücken ist zu bewerten und geeignete Maßnahmen sind zu ergreifen. |\n| 8.9 Konfigurationsmanagement | Konfigurationen von Hardware, Software, Diensten und Netzwerken, einschließlich Sicherheitskonfigurationen, müssen festgelegt, dokumentiert, implementiert, überwacht und überprüft werden. |\n| 8.25 Sicherer Entwicklungslebenszyklus | Regeln für die sichere Entwicklung von Software und Systemen müssen festgelegt und angewendet werden. |\n| 8.26 Anforderungen an die Anwendungssicherheit | Anforderungen an die Informationssicherheit müssen bei der Entwicklung oder dem Erwerb von Anwendungen identifiziert, spezifiziert und genehmigt werden. |\n| 8.27 Sichere Systemarchitektur und technische Grundsätze | Grundsätze für die Entwicklung sicherer Systeme müssen festgelegt, dokumentiert, gepflegt und bei allen Entwicklungsaktivitäten von Informationssystemen angewendet werden |\n\nMit GitLab kannst du deine Hardware- und Softwarekonfigurationen speichern, die Versionskontrolle verwalten, deine Konfigurationen über [Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/index.html) aktualisieren und die [CI/CD-Pipelines](https://docs.gitlab.com/ee/ci/pipelines/) von GitLab nutzen, um diese Konfigurationen in deine Anwendungen und Infrastruktur zu übertragen. Mit GitLab können Unternehmen [GitOps](https://about.gitlab.com/topics/gitops/) über eine einzige Plattform implementieren.\n\nMit dem [Infrastructure-as-Code-Scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) von GitLab kannst du deine IaC-Konfigurationsdateien auf bekannte Sicherheitslücken scannen. Das IaC-Scanning von GitLab unterstützt eine Vielzahl von IaC-Konfigurationsdateien und -Sprachen, wodurch es an verschiedene Technologie-Stacks angepasst werden kann.\n\nFür Compliance-Profis ermöglicht GitLab die Implementierung von Automatisierung durch [Compliance-Frameworks](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html) und [Compliance-Pipelines](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#compliance-pipelines). Dank dieser Funktionen können Benutzer(innen) kritische Projekte mit bestimmten Compliance-Anforderungen identifizieren und Konfigurationen über Pipelines an diese Projekte pushen. Sie ermöglichen eine konsistente Durchsetzung der Controls und unterstützen dadurch deine Sicherheitslage. Außerdem stellen sie sicher, dass die internen und externen Compliance-Anforderungen deines Unternehmens eingehalten werden.\n\nFür [Ultimate-Kund(inn)en](https://about.gitlab.com/pricing/ultimate/) bietet das [Compliance Center](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html) von GitLab eine zentrale Ansicht des Compliance-Zustands einer Gruppe, z. B. der verschiedenen Compliance Frameworks, die auf die Projekte in der Gruppe angewendet werden. Du kannst sogar sehen, wie gut du den [GitLab-Standard](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html#gitlab-standard) erfüllst.\n\n\u003Cbr>\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 8.15 Protokollierung | Protokolle, die Aktivitäten, Ausnahmen, Fehler und andere relevante Ereignisse aufzeichnen, sind zu erstellen, zu speichern, zu schützen und zu analysieren. | \n| 8.16 Kontrolle von Überwachungsaktivitäten | Netzwerke, Systeme und Anwendungen müssen auf anomales Verhalten überwacht und geeignete Maßnahmen zur Bewertung potenzieller Informationssicherheitsvorfälle ergriffen werden. |\n\nMit GitLab kannst du [Audit-Ereignisse](https://docs.gitlab.com/ee/administration/audit_events.html) verwenden, um wichtige Ereignisse zu verfolgen, einschließlich der Frage, wer wann die entsprechende Aktion durchgeführt hat. Audit-Ereignisse decken ein breites Spektrum von Kategorien ab, darunter:\n* Gruppenverwaltung\n* Authentifizierung und Autorisierung\n* Benutzerverwaltung\n* Compliance und Sicherheit\n* CI/CD\n* GitLab-Runner\n\n![Audit-Ereignisse](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/example-of-an-audit-event.png)\n\nBeispiel für ein Audit-Ereignis\n{: .note.text-center}\n\nFür [Ultimate-Kund(inn)en](https://about.gitlab.com/pricing/ultimate/) kann das [Audit-Ereignis-Streaming](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html) aktiviert werden. Mit dem Audit-Ereignis-Streaming können Benutzer(innen) ein Streaming-Ziel für eine Gruppe oder Instanz der obersten Ebene festlegen, um alle Audit-Ereignisse über die Gruppe, Untergruppen und Projekte als strukturierte JSON-Datei zu erhalten.\n\n\u003Cbr>\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 8.28 Sichere Programmierung | Bei der Softwareentwicklung sind die Prinzipien des sicheren Programmierens anzuwenden. |\n| 8.29 Sicherheitstests in Entwicklung und Akzeptanz | Sicherheitstestprozesse sind im Entwicklungslebenszyklus zu definieren und umzusetzen. | \n\nDu kannst die Funktionen in der [Sicherungsphase](https://about.gitlab.com/features/?stage=secure) von GitLab nutzen, um den Lebenszyklus deiner Softwareentwicklung zu verbessern und die Sicherheit deiner Produkte zu verbessern. Zu den Funktionen von GitLab in der Sicherungsphase gehören:\n* [Statische Anwendungssicherheitstests (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)\n* [Dynamische Anwendungssicherheitstests (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)\n* [Codequalität](https://docs.gitlab.com/ee/ci/testing/code_quality.html)\n* [Container-Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n* [Abhängigkeitssuche](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n\nund vieles mehr!\n\n![Ergebnisse zur Codequalität](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/code-quality-findings.png)\n\nErgebnisse zur Codequalität\n{: .note.text-center}\n\nKompromittierte Geheimnisse sind einer der führenden Katalysatoren für Sicherheitsverletzungen. Die [Erkennung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/) von GitLab scannt dein Repository, um zu verhindern, dass deine Geheimnisse aufgedeckt werden.\n\nMit der [Richtlinien-Funktion](https://docs.gitlab.com/ee/user/application_security/policies/) von GitLab können Benutzer(innen) [Scanausführungs-](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) und [Scanergebnis-Richtlinien](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) basierend auf konfigurierter Logik implementieren. Diese Richtlinien kombinieren die Scan-Funktionen in der [Sicherungsphase](https://about.gitlab.com/features/?stage=secure) mit [Freigaben für Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/), um die Compliance-Anforderungen weiter durchzusetzen.\n\nZusammen bilden die Sicherheitsfunktionen von GitLab die optimale Grundlage für einen sicheren Lebenszyklus der Softwareentwicklung und ermöglichen es dir, die Prinzipien des sicheren Programmierens sowie die Anforderungen deines Unternehmens einzuhalten.\n\n\u003Cbr>\n\n| Control-ID | Control-Beschreibung |\n| ---- | ----| \n| 8.32 Änderungsmanagement | Änderungen an Informationsverarbeitungseinrichtungen und Informationssystemen unterliegen den Änderungsmanagementverfahren. |\n\nGitLab bietet viele Funktionen, um ein umfassendes Änderungsmanagement zu unterstützen.\n\nMit der Quellcodeverwaltung von GitLab können Benutzer(innen) [geschützte Branches](https://docs.gitlab.com/ee/user/project/protected_branches.html) implementieren. Geschützte Branches ermöglichen es GitLab-Benutzer(inne)n, bestimmte Branches einzuschränken, die als kritisch für den Betrieb angesehen werden. Ein geschützter Branch steuert:\n* welche Benutzer(innen) in den Branch mergen können\n* welche Benutzer(innen) in den Branch pushen können\n* wenn Benutzer(innen) den Push in den Branch erzwingen können\n* ob Änderungen an Dateien, die in der CODEOWNERS-Datei aufgeführt sind, direkt in den Branch gepusht werden können\n* welche Benutzer(innen) den Schutz des Branches aufheben können\n\nDer [Standard-Branch](https://docs.gitlab.com/ee/user/project/repository/branches/default.html) in einem Repository wird automatisch als geschützter Branch gekennzeichnet.\n\n![Geschützte Branches](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/protected-branches-settings-within-gitlab.png)\n\nEinstellungen für geschützte Branches in GitLab\n{: .note.text-center}\n\nMerge Requests (MR) sind eine Kernkomponente des Softwareentwicklungszyklus. GitLab-Benutzer(innen) können ihre MRs so konfigurieren, dass sie erst freigegeben werden müssen, bevor sie zusammengeführt werden können. Mit MR-Genehmigungen können Benutzer(innen) die Mindestanzahl der erforderlichen Genehmigungen festlegen, bevor Arbeiten in ein Projekt zusammengeführt werden können. Einige Beispiele für Regeln, die du erstellen kannst, sind:\n* Benutzer(innen) mit bestimmten Berechtigungen können Arbeiten jederzeit genehmigen.\n* [Code-Eigentümer(innen)](https://docs.gitlab.com/ee/user/project/codeowners/index.html) können Arbeiten für Dateien genehmigen, die sie besitzen.\n* Benutzer(innen) mit bestimmten Berechtigungen können Arbeiten im Repository genehmigen, [auch wenn sie keine Merge-Rechte haben](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#merge-request-approval-segregation-of-duties).\n* Benutzer(inne)n mit bestimmten Berechtigungen kann die Möglichkeit gewährt oder verweigert werden, [Genehmigungsregeln für eine bestimmte Merge Request zu überschreiben](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#edit-or-override-merge-request-approval-rules).\n\nWie bereits erwähnt, können [Tickets](https://docs.gitlab.com/ee/user/project/issues/) und [Aufgaben](https://docs.gitlab.com/ee/user/tasks.html) verwendet werden, um Änderungsanfragen zu dokumentieren und zusammenzuarbeiten. [Beschreibungsvorlagen](https://docs.gitlab.com/ee/user/project/description_templates.html) ermöglichen es den Benutzer(inne)n, konsistente Beschreibungen für Tickets oder [MRs](https://docs.gitlab.com/ee/user/project/merge_requests/index.html) einzuhalten. Mit diesen Vorlagen kann ein konsistenter Ansatz verfolgt werden, um Änderungen in einer Weise anzufordern, die am besten zu deinem Unternehmen passt.\n\n## Mehr erfahren\nAls umfassende DevSecOps-Plattform unterstützt GitLab ein breites Spektrum an Anforderungen. ISO hat in der Version 2022 der ISO-Norm zusätzliche Controls für sicheres Programmieren und Konfigurationsmanagement hinzugefügt. Dies zeigt, dass Zertifizierungsstellen insgesamt einen verstärkten Fokus auf die Softwaresicherheit legen. Als strategischer Partner kann GitLab dir dabei helfen, die ISO 27001 einzuhalten und schneller bessere Software zu entwickeln.\n\nWeitere Informationen zu diesen Funktionen findest du in unserer [Tutorial-Bibliothek](https://docs.gitlab.com/ee/tutorials/).",[14,684,857],"customers",{"slug":859,"featured":6,"template":688},"how-gitlab-can-support-your-iso-compliance-journey","content:de-de:blog:how-gitlab-can-support-your-iso-compliance-journey.yml","How Gitlab Can Support Your Iso Compliance Journey","de-de/blog/how-gitlab-can-support-your-iso-compliance-journey.yml","de-de/blog/how-gitlab-can-support-your-iso-compliance-journey",{"_path":865,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":866,"content":872,"config":881,"_id":883,"_type":16,"title":884,"_source":18,"_file":885,"_stem":886,"_extension":21},"/de-de/blog/the-ultimate-guide-to-sboms",{"title":867,"description":868,"ogTitle":867,"ogDescription":868,"noIndex":6,"ogImage":869,"ogUrl":870,"ogSiteName":673,"ogType":674,"canonicalUrls":870,"schema":871},"Der ultimative Leitfaden zu SBOM","Erfahre, was eine Software Bill of Materials (SBOM) ist und warum sie zu einem integralen Bestandteil der modernen Softwareentwicklung geworden ist.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664571/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","https://about.gitlab.com/blog/the-ultimate-guide-to-sboms","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Der ultimative Leitfaden zu SBOM\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-10-25\",\n      }",{"title":867,"description":868,"authors":873,"heroImage":869,"date":875,"body":876,"category":14,"tags":877,"updatedDate":880},[874],"Sandra Gittlen","2022-10-25","In der heutigen digitalen Landschaft ist der Fokus auf Anwendungssicherheit innerhalb der Softwarebereitstellungskette kritischer denn je. Die Integration von Abhängigkeiten in Software erfordert Transparenz und Sicherheitsmaßnahmen, die oft komplex in der Implementierung und Verwaltung sind. Hier wird eine Software Bill of Materials (SBOM) unverzichtbar.\n\nUnser Leitfaden taucht tief in die Welt der SBOMs ein, beleuchtet ihre zentrale Rolle in einer multifunktionalen [DevSecOps-Strategie](https://about.gitlab.com/de-de/topics/devsecops/) und zeigt auf, wie du die SBOM-Gesundheit deiner Anwendung verbessern kannst – mit dem Ziel, die Cybersecurity deines Unternehmens zu stärken.\n\n## Inhalt - Der ultimative Guide zu SBOMs\n\n- [Was ist eine SBOM?](#was-ist-eine-software-bill-of-materials%3F)\n- [Warum sind SBOMs wichtig?](#warum-sind-sboms-wichtig%3F)\n- [Arten von SBOM-Datenaustauschstandards](#arten-von-sbom-datenaustauschstandards)\n- [Vorteile der Kombination von SBOMs und Software-Vulnerability-Management](#vorteile-der-kombination-von-sboms-und-software-vulnerability-management)\n- [Dynamische GitLab SBOMs](#dynamische-gitlab-sboms)\n- [SBOM-Generierung und -Verwaltung skalieren](#sbom-generierung-und-sbom-verwaltung-skalieren)\n- [SBOMs einlesen und zusammenführen](#sboms-einlesen-und-zusammenführen)\n- [Schwachstellen schneller beheben](#schwachstellen-schneller-beheben)\n- [Kontinuierliche SBOM-Analyse](#kontinuierliche-sbom-analyse)\n- [Vertrauen in SBOMs aufbauen](#vertrauen-in-sboms-aufbauen)\n- [Die Zukunft der SBOM-Funktionalität von GitLab](#die-zukunft-der-sbom-funktionalität-von-gitlab)\n- [Erste Schritte mit SBOMs](#erste-schritte-mit-sboms)\n- [SBOM-FAQ](#sbom-faq)\n\n## Was ist eine Software Bill of Materials?\n\nEine SBOM dient als umfassende [Liste der Komponenten](https://www.cisa.gov/sbom#), die Software ausmachen. Sie beleuchtet das Netzwerk von Bibliotheken, Tools und Prozessen, die im gesamten Entwicklungslebenszyklus verwendet werden. In Kombination mit Tools zum Management von Sicherheitslücken offenbart eine SBOM nicht nur genau diese potenziellen Sicherheitslücken in Softwareprodukten, sondern ebnet auch den Weg für strategische Risikominderung. \n\nEine SBOM ist ein verschachteltes Inventar oder eine Liste von Punkten, die Softwarekomponenten ausmachen. Zusätzlich zu den Komponenten selbst enthalten SBOMs wichtige Informationen über die Bibliotheken, Tools und Prozesse, die zur Entwicklung, zum Aufbau und zur Bereitstellung eines Software-Artefakts verwendet werden.\n\nDas Konzept des SBOM existiert seit mehr als einem Jahrzehnt. Im Rahmen der Bemühungen, die im Jahr 2023 veröffentlichte Nationale Cyber-Strategie umzusetzen, hilft CISA Secure by Design-Softwareherstellern, Sicherheitsprinzipien zu übernehmen und Cybersicherheit in ihre Produkte zu integrieren. Die [deutsche Regierung](https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/TR-03183-2-SBOM-Anforderungen.html) hat bewährte Verfahren herausgegeben, die Softwareentwickler(innen) im öffentlichen Sektor dazu bewegen, SBOMs in ihre Softwarepakete aufzunehmen. Auch auf dem privaten Sektor sindSBOMs immer mehr auf dem Vormarsch.\n\nObwohl SBOMs oft mit eigenständiger Software erstellt werden, integrieren Plattformen wie GitLab die SBOM-Generierung schon früh in den DevSecOps-Workflow.\n\n![supply chain security sdlc](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/supply_chain_security_sdlc.png)\n\n## Warum sind SBOMs wichtig?\n\nModerne Softwareentwicklung ist darauf fokussiert, Anwendungen schneller und effizienter zu liefern. Das führt oft dazu, dass Entwickler(innen) Code aus Open-Source-Repositories oder proprietären Paketen in ihre Anwendungen einbauen. Laut dem [Open Source Security and Risk Analysis-Bericht 2024 von Synopsys](https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-2024.pdf), der über 1.000 kommerzielle Codebasen aus 17 Branchen im Jahr 2023 untersuchte, enthielten 96 % der gesamten Codebasen Open Source und 84 % der bewerteten Codebasen zeigten deutlicheSicherheitslücken.\n\nDie Einbindung von Code aus unbekannten Repositories erhöht das Risiko von Schwachstellen, die von Hackern ausgenutzt werden können. Tatsächlich wurde der [Angriff auf SolarWinds im Jahr 2020](https://www.spektrum.de/news/solarwinds-ein-hackerangriff-der-um-die-welt-geht/1819187) durch die Aktivierung einer bösartigen Code-Injektion in einem Paket ausgelöst, das von SolarWinds Orion-Produkt verwendet wurde. Kunden entlang der gesamten Softwarebereitstellungskette waren erheblich davon betroffen. Andere Angriffe, einschließlich der log4j-Schwachstelle, die mehrere kommerzielle Softwareanbieter traf, unterstrichen die Notwendigkeit einer genauen Untersuchung von Anwendungsabhängigkeiten, um Risiken in der gesamten [Softwarebereitstellungskette](https://about.gitlab.com/de-de/solutions/supply-chain/) zu bewerten.\n\nDarüber hinaus stellt das Auffinden und Beheben einer Sicherheitslücke einen Kostenfaktor dar –was die Bedeutung von SBOMs weiter unterstreicht. SBOMs ermöglichen Transparenz in Bezug auf Abhängigkeiten und können dazu genutzt werden, Schwachstellen sowie Lizenzen zu identifizieren, die nicht den internen Vorgaben entsprechen.\n\n## Arten von SBOM-Datenaustauschstandards   \n\nSBOMs sind am effektivsten, wenn die Generierung und Verarbeitung von Informationen wie Name, Version, Packager und weiteren Daten automatisiert erfolgen kann. Dies wird optimal erreicht, wenn alle Beteiligten ein standardisiertes Format für den Datenaustausch verwenden.\n\nEs gibt zwei wesentliche Standards für den SBOM-Datenaustausch:\n\n- [OWASP CycloneDX](https://cyclonedx.org/capabilities/sbom/)\n- [SPDX](https://spdx.dev/)\n\nGitLab setzt für die SBOM-Generierung auf CycloneDX, da dieser Standard präzise und benutzerfreundlich ist, komplexe Abhängigkeiten vereinfacht und durch seine Erweiterbarkeit auch spezialisierte sowie zukünftige Anwendungsfälle abdeckt.\n\n## Vorteile der Kombination von SBOMs und Software-Vulnerability-Management\n\nSBOMs sind für DevSecOps-Teams und Software-Nutzer(innen) aus mehreren Gründen äußerst vorteilhaft:\nSie ermöglichen einen Standardansatz, um zu verstehen, welche zusätzlichen Softwarekomponenten in einer Anwendung enthalten sind und wo sie deklariert sind.\nSie bieten einen kontinuierlichen Einblick in den Entstehungsprozess einer Anwendung, einschließlich Details über die Herkunft des Codes von Drittanbietern und Host-Repositories.\nSie bieten ein hohes Maß an Sicherheitstransparenz, sowohl für den von Erstanbietern entwickelten Code als auch für die übernommene Open-Source-Software.\nDie Details, die SBOMs bieten, ermöglichen es einem [DevOps-Team](https://about.gitlab.com/de-de/topics/devops/), Schwachstellen zu identifizieren, die potenziellen Risiken zu bewerten und sie dann zu entschärfen.\nSBOMs können die Transparenz liefern, die die Käufer von Anwendungen heute verlangen.\n\n## Dynamische GitLab-SBOMs \n\nDamit SBOMs ihr volles Potenzial entfalten können, müssen sie automatisch generiert, mit Anwendungssicherheitsscans verbunden, in Dashboards integriert und kontinuierlich aktualisiert werden. GitLab unterstützt all diese Ziele und bietet dabei umfassende Funktionen zur Sicherung der Softwarebereitstellungskette.\n\n![Dynamic SBOM management](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/Screenshot_2024-05-03_at_10.53.28_AM.png)\n\n### SBOM-Generierung und SBOM-Verwaltung skalieren\n\nZur Einhaltung interner Richtlinien und Vorschriften ist es wichtig, über genaue und umfassende SBOMs zu verfügen, die Open-Source-, Drittanbieter- und unternehmenseigene Software abdecken. Um SBOMs für jede Komponente und Produktversion effektiv zu verwalten, ist ein rationalisierter Prozess für die Erstellung, Zusammenführung, Validierung und Genehmigung von SBOMs erforderlich. Die Abhängigkeitslistenfunktion von GitLab fasst bekannte Schwachstellen- und Lizenzdaten in einer einzigen Ansicht auf der GitLab-Benutzeroberfläche zusammen. Die Informationen des Abhängigkeitsdiagramms werden auch als Teil des Abhängigkeits-Scanberichts generiert. Dadurch erhalten Benutzer(innen) einen umfassenden Einblick in Abhängigkeiten und Risiken innerhalb ihrer Projekte oder in Projektgruppen. Darüber hinaus kann in der CI-Pipeline ein JSON-Artefakt im CycloneDX-Format erzeugt werden. Diese API bietet einen differenzierteren und anpassbaren Ansatz für die SBOM-Erstellung. SBOMs können über die Benutzeroberfläche, eine bestimmte Pipeline oder ein Projekt oder über die GitLab-API exportiert werden.\n\n### SBOMs einlesen und zusammenführen\n\nGitLab kann SBOMs von Drittanbietern einlesen und bietet eine umfängliche Sicherheitstransparenz sowohl für Drittanbieter-Code als auch für eingebundene Open-Source-Software. Mit GitLab kannst du einen CI/CD-Job verwenden, um mehrere CycloneDX-SBOMs nahtlos in eine einzige SBOM zusammenzuführen. Durch die Verwendung implementierungsspezifischer Details in den CycloneDX-Metadaten jeder SBOM, wie etwa die Position von Build- und Sperrdateien, werden doppelte Informationen aus der resultierenden Datei entfernt. Diese Daten werden auch automatisch mit Lizenz- und Schwachstelleninformationen für die in der SBOM enthaltenen Komponenten angereichert.\n\n### Schwachstellen schneller beheben\n\nDie schnellere Entwicklung hochwertiger Produkte erfordert aussagekräftige Sicherheitsergebnisse, damit Entwickler(innen) die kritischsten Schwachstellen beheben können. GitLab hilft bei der Sicherung deiner Bereitstellungskette, indem es nach Schwachstellen im Quellcode, in Containern, Abhängigkeiten und laufenden Anwendungen sucht. GitLab bietet einen umfassenden Sicherheitsscanner mit Funktionen für statische Anwendungssicherheitstests (SAST), dynamische Anwendungssicherheitstests (DAST), Containerscans und Softwarekompositionsanalysen (SCA), um dich umfassend vor neuen Bedrohungen zu schützen. Um Entwickler(innen) und Sicherheitsingenieur(innen) zu helfen, Schwachstellen besser zu verstehen und effizienter zu beheben, bietet GitLab Duo Vulnerability Explanation, eine KI-gestützte Funktion. Sie erläutert eine bestimmte Schwachstelle, wie sie ausgenutzt werden kann und empfiehlt vor allem, wie die Schwachstelle zu beheben ist. In Kombination mit GitLab Duo Vulnerability Resolution können DevSecOps-Teams Schwachstellen mit nur wenigen Klicks intelligent identifizieren, analysieren und beheben.\n\nDie Plattform unterstützt auch die Erstellung neuer Richtlinien (und die Durchsetzung der Compliance), die auf neu entdeckten Schwachstellen basieren.\n\n### Kontinuierliche SBOM-Analyse\n\nGitLab Continuous Vulnerability Scanning löst Scans in allen Projekten aus, bei denen entweder Container-Scans, Abhängigkeits-Scans oder beide aktiviert sind, unabhängig von einer Pipeline. Wenn neue Common Vulnerabilities and Exposures (CVEs) in der National Vulnerability Database (NVD) gemeldet werden, müssen die Benutzer(innen) ihre Pipelines nicht neu starten, um die neuesten Feeds zu erhalten. GitLabs Vulnerability Research Team fügt diese CVEs zur GitLab Advisory Database hinzu – und diese Hinweise werden automatisch als Schwachstellen in GitLab gemeldet. Dadurch wird GitLabs SBOM dynamisch.\n\n### Vertrauen in SBOMs aufbauen\n\nOrganisationen, die [Compliance-Funktionen](https://about.gitlab.com/de-de/solutions/compliance/) benötigen, können GitLab verwenden, um Bestätigungen für alle Build-Artefakte zu erstellen, die vom [GitLab Runner](https://docs.gitlab.com/runner/) produziert werden. Der Prozess ist sicher, da er vom GitLab Runner selbst durchgeführt wird, ohne dass Daten an einen externen Dienst übergeben werden müssen.\n\n### Die Zukunft der SBOM-Funktionalität von GitLab\n\nDie Sicherheit der [Softwarebereitstellungskette](https://about.gitlab.com/direction/supply-chain/) bleibt aufgrund der häufigen Angriffe auf große Softwareanbieter und der gezielten Bemühungen von Angreifern im Open-Source-Ökosystem ein kritisches Thema in der Cybersecurity- und Softwareindustrie. Auch wenn sich die SBOM-Branche schnell weiterentwickelt, gibt es weiterhin Bedenken, wie SBOMs generiert werden, wie häufig diese Generierung erfolgt, wo sie gespeichert werden, wie man mehrere SBOMs für komplexe Anwendungen kombiniert, wie man sie analysiert und wie man sie für Anwendungen nutzt.\n\nGitLab hat SBOMs zu einem integralen Bestandteil seiner Softwarebereitstellungskettenstrategie gemacht und verbessert kontinuierlich seine SBOM-Fähigkeiten innerhalb der DevSecOps-Plattform, einschließlich der Planung neuer Funktionen und Funktionalitäten. Zu den jüngsten Verbesserungen gehören die Automatisierung der Bestätigungserstellung, die digitale Signierung von Build-Artefakten und die Unterstützung extern generierter SBOMs. \n\nDarüber hinaus hat GitLab innerhalb der Plattform ein solides [SBOM Maturity Model](https://handbook.gitlab.com/handbook/security/security-assurance/dedicated-compliance/sbom-plan/) , etabliert, das Schritte wie die automatische SBOM-Generierung, das Sourcing von SBOMs aus der Entwicklungsumgebung, die Analyse von SBOMs für Artefakte und die Förderung der digitalen Signierung von SBOMs umfasst. GitLab plant auch die Einführung der automatischen digitalen Signatur von Build-Artefakten in zukünftigen Versionen.\n\n### Erste Schritte mit SBOMs\n\nDie Nachfrage nach SBOMs ist bereits hoch. Behörden empfehlen oder verlangen zunehmend die Erstellung von SBOMs von Softwareanbietern, Entwickler(innen) von Bundessoftware und sogar Open-Source-Communities. \n\nInformiere dich über die SBOM-Funktionen für GitLab Ultimate in der DevSecOps-Plattform von GitLab, um diese Anforderungen zu erfüllen.\n\n## SBOM-FAQ\n### Was ist eine SBOM?\n\nEine SBOM (Software Bill of Materials) ist eine detaillierte Liste aller Komponenten, Bibliotheken und Abhängigkeiten, die in einer Software verwendet werden. Sie bietet Transparenz über die verwendeten Elemente, um Sicherheitslücken zu identifizieren und die Software-Compliance sicherzustellen. SBOMs helfen, Schwachstellen zu erkennen und Software-Supply-Chain-Risiken zu minimieren.\n\n### Warum sind SBOMs wichtig?  \n\nSBOMs sind aus mehreren Gründen entscheidend:\nEinblick in Abhängigkeiten: Das Verständnis der Bestandteile deiner Software hilft, Risiken in Verbindung mit Drittanbieter-Komponenten zu identifizieren und zu mindern.\nErhöhte Sicherheit: Mit detaillierten Einblicken in die Komponenten einer Anwendung können Organisationen Schwachstellen schnell identifizieren und beheben.\nRegulatorische Compliance: Zunehmend fordern Vorschriften und Best Practices eine SBOM für Softwarepakete, insbesondere im öffentlichen Sektor.\nEffiziente Entwicklung: Entwickler(innen) können auf eine SBOM zurückgreifen, um Einblicke in verwendete Bibliotheken und Komponenten zu erhalten, was Zeit spart und Fehler im Entwicklungszyklus reduziert.\n\n### Welche Standards werden für den SBOM-Datenaustausch verwendet?\n\nEs gibt zwei vorherrschende Standards:\n\n- CycloneDX: CycloneDX ist für seine benutzerfreundliche Herangehensweise bekannt, die es ermöglicht, komplexe Beziehungen zwischen Softwarekomponenten zu vereinfachen und spezielle Anwendungsfälle zu unterstützen. Der Standard ist erweiterbar und eignet sich gut für zukünftige Anforderungen.\n- SPDX: Ein weiteres weit verbreitetes Framework für den SBOM-Datenaustausch, das detaillierte Informationen über die in der Softwareumgebung enthaltenen Komponenten bereitstellt.\n\nGitLab verwendet speziell CycloneDX für die SBOM-Generierung, da es aufgrund seiner Präskriptivität und Erweiterbarkeit gut für zukünftige Anforderungen geeignet ist.\n\n### Wie geht GitLab mit SBOMs um?\n\nGitLab legt besonderen Wert auf die Erstellung dynamischer SBOMs, die:\nAutomatisch generiert werden: So wird sichergestellt, dass stets aktuelle Informationen über die Softwarezusammensetzung vorliegen.\nIn Tools integriert sind: SBOMs werden mit Sicherheits-Scanning-Tools verbunden, um umfassende Risikobewertungen zu ermöglichen.\nEinfach zu verwalten sind: GitLab unterstützt die Einlesung und das Zusammenführen von SBOMs für eine umfassende Analyse.\nKontinuierlich analysiert werden: Die Plattform bietet fortlaufende Scans von Projekten, um neu auftretende Schwachstellen frühzeitig zu erkennen.\n\n### Wie kann ich SBOMs in meinem Unternehmen implementieren?\n\nDie steigende Nachfrage nach SBOMs spiegelt die zunehmende Bedeutung von Softwaresicherheit und Integrität der Lieferkette wider. Für Unternehmen, die bereit sind, SBOMs einzuführen, bietet das Ultimate-Paket von GitLab eine robuste Plattform zur Erstellung und Verwaltung von SBOMs innerhalb eines DevSecOps-Workflows. Durch den Einsatz der GitLab-Tools können Teams die Einhaltung von Vorschriften gewährleisten, die Sicherheit verbessern und Entwicklungsverfahren optimieren.\n\n[\nTeste GitLab Ultimate jetzt 30 Tage kostenlos.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/blog/&glm_content=default-saas-trial)\n\n---\n\nDisclaimer \n*Dieser Blog enthält Informationen zu zukünftigen Produkten, Features und Funktionen. Bitte beachte, dass die Informationen in diesem Blogbeitrag nur zu Informationszwecken dienen. Sie sollten nicht als Grundlage für Kauf- oder Planungsentscheidungen verwendet werden. Wie bei allen Projekten unterliegen die in diesem Blog erwähnten Elemente und verlinkten Seiten Änderungen oder Verzögerungen. Die Entwicklung, Veröffentlichung und das Timing von Produkten, Features oder Funktionen liegen im alleinigen Ermessen von GitLab.*\n",[14,707,878,879,188],"performance","open source","2025-04-01",{"slug":882,"featured":6,"template":688},"the-ultimate-guide-to-sboms","content:de-de:blog:the-ultimate-guide-to-sboms.yml","The Ultimate Guide To Sboms","de-de/blog/the-ultimate-guide-to-sboms.yml","de-de/blog/the-ultimate-guide-to-sboms",1,[694,716,737,757,778,800,824,844,864],1751548582819]