<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Merge Request on Romano Roth</title><link>https://romanoroth.com/de/tags/merge-request/</link><description>Recent content in Merge Request on Romano Roth</description><generator>Hugo -- gohugo.io</generator><language>de</language><copyright>Romano Roth</copyright><lastBuildDate>Wed, 02 Nov 2022 00:00:00 +0000</lastBuildDate><atom:link href="https://romanoroth.com/de/tags/merge-request/index.xml" rel="self" type="application/rss+xml"/><item><title>GitLab DevSecOps Teil 10: Wie man einen Merge Request richtig macht</title><link>https://romanoroth.com/de/blogs/gitlab-devsecops-merge-request/</link><pubDate>Wed, 02 Nov 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/de/blogs/gitlab-devsecops-merge-request/</guid><description>&lt;p>In den vorherigen neun Sessions haben Patrick Steger und ich eine GitLab DevSecOps-Pipeline gebaut, die SAST, Secret Detection, Software Composition Analysis, Container Scanning und DAST ausführt. Nützlich — aber nur dann, wenn sie Probleme tatsächlich findet, &lt;em>bevor&lt;/em> der Code im Default-Branch landet. In Teil 10 schliessen wir diesen Loop: Wir hängen die Pipeline an Merge Requests, sodass jede Änderung gescannt wird, die Deltas gegen den Default-Branch sichtbar sind, und Freigaben erforderlich werden, wenn neue High- oder Critical-Vulnerabilities auftauchen.&lt;/p></description></item></channel></rss>