<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Application Security on Romano Roth</title><link>https://romanoroth.com/de/tags/application-security/</link><description>Recent content in Application Security on Romano Roth</description><generator>Hugo -- gohugo.io</generator><language>de</language><copyright>Romano Roth</copyright><lastBuildDate>Mon, 22 May 2023 00:00:00 +0000</lastBuildDate><atom:link href="https://romanoroth.com/de/tags/application-security/index.xml" rel="self" type="application/rss+xml"/><item><title>GitHub DevSecOps Teil 9: Vulnerability Management</title><link>https://romanoroth.com/de/blogs/github-devsecops-vulnerability-management/</link><pubDate>Mon, 22 May 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/de/blogs/github-devsecops-vulnerability-management/</guid><description>&lt;p>Wir haben in den letzten acht Sessions Scanner in unsere GitHub DevSecOps Pipeline eingebaut — SCA, SAST, Container Scanning, Secret Detection, DAST. Die Scanner produzieren jetzt einen kontinuierlichen Strom von Findings, und die Frage lautet: Wo managen wir sie? In Teil 9 schauen Patrick Steger und ich uns das eingebaute Vulnerability Management von GitHub an — den Security Tab — und benennen, was funktioniert und was fehlt.&lt;/p></description></item><item><title>GitHub DevSecOps Teil 7: Secrets im eigenen Code finden mit Secret Scanning</title><link>https://romanoroth.com/de/blogs/github-devsecops-secret-detection/</link><pubDate>Tue, 14 Feb 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/de/blogs/github-devsecops-secret-detection/</guid><description>&lt;p>API-Keys, Tokens und Passwörter rutschen nach wie vor regelmässig in Repositories — manchmal aus Versehen, manchmal weil Entwickler es ehrlich nicht besser wussten. In Teil 7 unserer GitHub DevSecOps Serie schalten Patrick Steger und ich GitHubs eingebautes Secret Scanning ein, definieren ein eigenes Pattern, probieren Push Protection aus und schauen offen hin, wo die Funktion liefert und wo sie noch nicht hält, was sie verspricht.&lt;/p></description></item><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 9: Vulnerability Management Herausforderungen meistern</title><link>https://romanoroth.com/de/blogs/gitlab-devsecops-vulnerability-management/</link><pubDate>Wed, 12 Oct 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/de/blogs/gitlab-devsecops-vulnerability-management/</guid><description>&lt;p>Nach acht Sessions, in denen wir Scanner in unsere GitLab-Pipeline eingebaut haben — SAST, Secret Detection, SCA, License Compliance, Container Scanning, DAST — haben wir jetzt ein anderes Problem. Wir haben hunderte von Vulnerability-Findings. In Teil 9 schauen Patrick Steger und ich uns das eingebaute Vulnerability Management von GitLab an: was es liefert, wo es schwächelt und wie man Findings tatsächlich triagiert, ohne den Überblick zu verlieren.&lt;/p></description></item><item><title>GitLab DevSecOps Teil 7: Secrets im eigenen Code finden mit Secret Detection</title><link>https://romanoroth.com/de/blogs/gitlab-devsecops-secret-detection/</link><pubDate>Wed, 28 Sep 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/de/blogs/gitlab-devsecops-secret-detection/</guid><description>&lt;p>Hardcodierte Passwörter und API-Keys sind nach wie vor einer der häufigsten Wege, auf denen Credentials nach aussen gelangen. Sie werden versehentlich committet, bleiben für immer in der Git-History und tauchen meist erst dann auf, wenn sie schon ausgenutzt werden. In Teil 7 unserer GitLab DevSecOps Serie ergänzen Patrick Steger und ich die bestehende Pipeline um Secret Detection — eine Zeile YAML — und schauen dann ehrlich hin: Was findet GitLeaks tatsächlich, was übersieht es still, und was tun wir damit?&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><item><title>Was ist Build? | SAFe DevOps Health Radar</title><link>https://romanoroth.com/de/blogs/was-ist-build-safe-devops-health-radar/</link><pubDate>Sun, 12 Sep 2021 20:59:21 +0000</pubDate><guid>https://romanoroth.com/de/blogs/was-ist-build-safe-devops-health-radar/</guid><description>&lt;p>Build ist der Schritt im SAFe for DevOps Health Radar, in dem committed Code kontinuierlich integriert, getestet und zu einem deploybaren Artefakt mit eingebauter Qualität verarbeitet wird. In diesem Video erkläre ich, was der Build-Schritt umfasst, warum Continuous Integration wichtig ist und wie Techniken wie Gated Commits und statische Sicherheitsanalyse helfen, Qualität bei hoher Geschwindigkeit aufrechtzuerhalten.&lt;/p></description></item></channel></rss>