<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Semgrep on Romano Roth</title><link>https://romanoroth.com/de/tags/semgrep/</link><description>Recent content in Semgrep on Romano Roth</description><generator>Hugo -- gohugo.io</generator><language>de</language><copyright>Romano Roth</copyright><lastBuildDate>Wed, 01 Feb 2023 00:00:00 +0000</lastBuildDate><atom:link href="https://romanoroth.com/de/tags/semgrep/index.xml" rel="self" type="application/rss+xml"/><item><title>GitHub DevSecOps Teil 5: Static Application Security Testing (SAST)</title><link>https://romanoroth.com/de/blogs/github-devsecops-sast/</link><pubDate>Wed, 01 Feb 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/de/blogs/github-devsecops-sast/</guid><description>&lt;p>SCA hat unsere Dependencies abgedeckt. License Compliance hat geklärt, was wir ausliefern dürfen. SAST ist die Stelle, an der wir die Scanner auf den Code richten, den wir selbst geschrieben haben. In Teil 5 unserer GitHub DevSecOps Serie integrieren Patrick Steger und ich Static Application Security Testing in die Pipeline — und merken auf die harte Tour, dass es auf GitHub drei Actions braucht statt einer.&lt;/p></description></item><item><title>GitLab DevSecOps Teil 5: Static Application Security Testing (SAST)</title><link>https://romanoroth.com/de/blogs/gitlab-devsecops-sast/</link><pubDate>Wed, 31 Aug 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/de/blogs/gitlab-devsecops-sast/</guid><description>&lt;p>Software Composition Analysis kümmert sich um die Bibliotheken, die du einbindest. Aber was ist mit dem Code, den dein Team selbst schreibt? Genau dafür ist Static Application Security Testing da. In Teil 5 unserer GitLab DevSecOps Serie integrieren Patrick Steger und ich SAST in die Pipeline, bauen ein paar realistische Schwachstellen in unser Spring-Boot-Beispiel ein und schauen zu, wie GitLab sie aufgreift.&lt;/p></description></item></channel></rss>