<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>SAST on Romano Roth</title><link>https://romanoroth.com/en/tags/sast/</link><description>Recent content in SAST on Romano Roth</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Romano Roth</copyright><lastBuildDate>Wed, 01 Feb 2023 00:00:00 +0000</lastBuildDate><atom:link href="https://romanoroth.com/en/tags/sast/index.xml" rel="self" type="application/rss+xml"/><item><title>GitHub DevSecOps Part 5: Static Application Security Testing (SAST)</title><link>https://romanoroth.com/en/blogs/github-devsecops-sast/</link><pubDate>Wed, 01 Feb 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/github-devsecops-sast/</guid><description>&lt;p>SCA covered our dependencies. License compliance covered what we are allowed to ship. SAST is where we point the scanners at the code we wrote ourselves. In Part 5 of our GitHub DevSecOps series, Patrick Steger and I add Static Application Security Testing to the pipeline — and find out the hard way that on GitHub it takes three Actions, not one.&lt;/p></description></item><item><title>GitLab DevSecOps Part 5: Static Application Security Testing (SAST)</title><link>https://romanoroth.com/en/blogs/gitlab-devsecops-sast/</link><pubDate>Wed, 31 Aug 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-devsecops-sast/</guid><description>&lt;p>Software composition analysis takes care of the libraries you pull in. But what about the code your own team writes? That is where Static Application Security Testing comes in. In Part 5 of our GitLab DevSecOps series, Patrick Steger and I add SAST to the pipeline, plant a few realistic vulnerabilities in our Spring Boot sample, and watch GitLab pick them up.&lt;/p></description></item></channel></rss>