<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>CI/CD on Romano Roth</title><link>https://romanoroth.com/en/tags/ci/cd/</link><description>Recent content in CI/CD on Romano Roth</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Romano Roth</copyright><lastBuildDate>Tue, 04 Mar 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://romanoroth.com/en/tags/ci/cd/index.xml" rel="self" type="application/rss+xml"/><item><title>Continuous Security with DevSecOps and Platform Engineering</title><link>https://romanoroth.com/en/blogs/continuous-security-with-devsecops-and-platform-engineering/</link><pubDate>Tue, 04 Mar 2025 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/continuous-security-with-devsecops-and-platform-engineering/</guid><description>&lt;p>Imagine a world where security is seamlessly integrated into your development workflow from ideation until production, so that development teams can completely focus on feature development while building secure applications. That is exactly what I presented at the OWASP Chapter Meetup Switzerland. In this talk, I show how platform engineering transforms modern application security and makes DevSecOps a reality at scale.&lt;/p></description></item><item><title>GitHub DevSecOps Part 12: Our Recommendations and Lessons Learned</title><link>https://romanoroth.com/en/blogs/github-devsecops-recommendations/</link><pubDate>Tue, 13 Jun 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/github-devsecops-recommendations/</guid><description>&lt;p>After eleven sessions building a full DevSecOps pipeline with GitHub — covering Software Composition Analysis, License Compliance, SAST, Container Scanning, Secret Detection, DAST, Pull Requests, Scheduled Pipelines, and Vulnerability Management — Patrick Steger and I close the series with our recommendations. What works on GitHub, where the gaps are, and what we would tell anyone setting out to build the same pipeline.&lt;/p></description></item><item><title>GitHub DevSecOps Part 11: Scheduled Pipelines for Production Code</title><link>https://romanoroth.com/en/blogs/github-devsecops-schedule-pipeline/</link><pubDate>Mon, 05 Jun 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/github-devsecops-schedule-pipeline/</guid><description>&lt;p>Across ten sessions we wired security checks into a GitHub Actions pipeline that fires on every commit and every Pull Request. That covers code we are actively changing. It does not cover the code that is already running in production while researchers keep finding new CVEs in the libraries it uses. In Part 11 of the GitHub DevSecOps series, Patrick Steger and I add a scheduled workflow that re-scans the production branch — and we run straight into a GitHub limitation worth knowing about up front.&lt;/p></description></item><item><title>GitHub DevSecOps Part 10: Branch Protection and Pull Requests</title><link>https://romanoroth.com/en/blogs/github-devsecops-pull-request/</link><pubDate>Tue, 30 May 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/github-devsecops-pull-request/</guid><description>&lt;p>In the previous nine sessions Patrick Steger and I built a GitHub DevSecOps pipeline with build, SCA, License Compliance, SAST, Container Scanning, Secret Detection and DAST. All useful — but only if it actually runs &lt;em>before&lt;/em> code lands in main, and only if the merge is blocked when something serious shows up. In Part 10 we wire that gate together with Pull Requests and Branch Protection rules.&lt;/p></description></item><item><title>GitHub DevSecOps Part 9: Vulnerability Management</title><link>https://romanoroth.com/en/blogs/github-devsecops-vulnerability-management/</link><pubDate>Mon, 22 May 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/github-devsecops-vulnerability-management/</guid><description>&lt;p>We have spent the previous eight sessions adding scanners to our GitHub DevSecOps pipeline — SCA, SAST, container scanning, secret detection, DAST. The scanners now produce a steady stream of findings, and the question is: where do we manage them? In Part 9, Patrick Steger and I look at GitHub&amp;rsquo;s built-in Vulnerability Management — the Security Tab — and call out what it does well and what is still missing.&lt;/p></description></item><item><title>GitHub DevSecOps Part 8: Dynamic Application Security Testing (DAST)</title><link>https://romanoroth.com/en/blogs/github-devsecops-dast/</link><pubDate>Wed, 19 Apr 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/github-devsecops-dast/</guid><description>&lt;p>After seven sessions of static analysis — SCA, license compliance, SAST, container scanning, secret detection — Patrick Steger and I move into the dynamic side of the pipeline. In Part 8 we add Dynamic Application Security Testing to our GitHub Actions pipeline. DAST runs the application and then attacks it. GitHub does not ship this out of the box, so we wire in a community action built on OWASP ZAP — and we are honest about where that approach falls short for enterprise use.&lt;/p></description></item><item><title>GitHub DevSecOps Part 7: Finding Secrets in Your Code with Secret Scanning</title><link>https://romanoroth.com/en/blogs/github-devsecops-secret-detection/</link><pubDate>Tue, 14 Feb 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/github-devsecops-secret-detection/</guid><description>&lt;p>API keys, tokens, and passwords still leak into repositories all the time — sometimes by accident, sometimes by a developer who genuinely did not know better. In Part 7 of our GitHub DevSecOps series, Patrick Steger and I switch on GitHub&amp;rsquo;s built-in Secret Scanning, add a custom pattern of our own, try out push protection, and look honestly at what the feature finds and where it falls short.&lt;/p></description></item><item><title>GitHub DevSecOps Part 6: How to Use Container Scanning</title><link>https://romanoroth.com/en/blogs/github-devsecops-container-scanning/</link><pubDate>Thu, 09 Feb 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/github-devsecops-container-scanning/</guid><description>&lt;p>We have built up the GitHub Actions pipeline through five sessions: the project basics, software composition analysis, license compliance, and static application security testing. The next layer is container scanning — looking for vulnerabilities inside the Docker image we ship, not just in the source we wrote. In Part 6 of our series, Patrick Steger and I split the work into two GitHub Actions sub-workflows: one builds the image and pushes it to the registry, the other pulls it back and runs Trivy on it.&lt;/p></description></item><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>GitHub DevSecOps Part 4: How to Ensure License Compliance</title><link>https://romanoroth.com/en/blogs/github-devsecops-license-compliance/</link><pubDate>Wed, 25 Jan 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/github-devsecops-license-compliance/</guid><description>&lt;p>GitHub does not ship a license scanner out of the box, and when we went looking in the marketplace, none of the existing actions did what we needed. So we built our own with a colleague from Microsoft and published it. In Part 4 of our GitHub DevSecOps series, Patrick Steger and I plug that License Finder action into our Spring Boot pipeline, configure which licenses are acceptable, and show how to surface the results inside GitHub.&lt;/p></description></item><item><title>GitHub DevSecOps Part 3: Software Composition Analysis with Dependabot and CRDA</title><link>https://romanoroth.com/en/blogs/github-devsecops-sca/</link><pubDate>Thu, 19 Jan 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/github-devsecops-sca/</guid><description>&lt;p>GitHub does not ship a default SCA tool the way GitLab does. You have to combine two things: a platform feature called Dependabot and an SCA action from the Marketplace. In Part 3 of the GitHub DevSecOps series, Patrick Steger and I wire both into our pipeline — and find out the hard way that the Marketplace path is not as smooth as the slides suggest.&lt;/p></description></item><item><title>GitHub DevSecOps Part 2: Creating a Simple Project and Your First Workflow</title><link>https://romanoroth.com/en/blogs/github-devsecops-creating-a-project/</link><pubDate>Wed, 11 Jan 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/github-devsecops-creating-a-project/</guid><description>&lt;p>Before we plug security tools into anything, we need a repository, a pipeline, and a working build. In Part 2 of our GitHub DevSecOps series, Patrick Steger and I create a private GitHub repo for a small Java Spring Boot service, enable GitHub Actions, and wire up a two-workflow pipeline that compiles the code and runs the unit tests. This is the skeleton everything else in the series hangs on.&lt;/p></description></item><item><title>GitHub DevSecOps Part 1: What Is GitHub and Why Shift Security Left?</title><link>https://romanoroth.com/en/blogs/github-devsecops-introduction/</link><pubDate>Tue, 03 Jan 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/github-devsecops-introduction/</guid><description>&lt;p>After we finished the GitLab DevSecOps series, Patrick changed jobs — and his new team is on GitHub. The problem is the same: no security checks during development. The platform is different. In Part 1 of our GitHub DevSecOps series, we cover what GitHub is, the CI/CD vocabulary you have to share before any pipeline conversation works, and the shape of the DevSecOps pipeline we will build over the next sessions.&lt;/p></description></item><item><title>GitLab vs. GitHub: DevSecOps Pipeline</title><link>https://romanoroth.com/en/blogs/gitlab-vs-github-devsecops/</link><pubDate>Wed, 28 Dec 2022 11:25:25 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-vs-github-devsecops/</guid><description>&lt;p>by &lt;a href="https://www.linkedin.com/in/romanoroth/" target="_blank" rel="noreferrer">Romano Roth&lt;/a> and &lt;a href="https://www.linkedin.com/in/patrick-steger-ch/" target="_blank" rel="noreferrer">Patrick Steger&lt;/a>&lt;/p>
&lt;p>&lt;figure>&lt;img
 class="my-0 rounded-md"
 loading="lazy"
 decoding="async"
 fetchpriority="auto"
 alt=""
 width="1280"
 height="720"
 src="https://romanoroth.com/images/blog/gitlab-vs-github-devsecops-inline-1_hu_21f4da4944ff7974.png"
 srcset="https://romanoroth.com/images/blog/gitlab-vs-github-devsecops-inline-1_hu_21f4da4944ff7974.png 800w, https://romanoroth.com/images/blog/gitlab-vs-github-devsecops-inline-1.png 1280w"
 sizes="(min-width: 768px) 50vw, 65vw"
 data-zoom-src="https://romanoroth.com/images/blog/gitlab-vs-github-devsecops-inline-1.png">&lt;/figure>
&lt;/p>
&lt;p>This video series will show you how to build up an enterprise-ready DevSecOps Pipeline with GitLab and GitHub and compare the two platforms.&lt;/p></description></item><item><title>GitLab DevSecOps Part 12: Our Recommendations and Lessons Learned</title><link>https://romanoroth.com/en/blogs/gitlab-devsecops-recommendations/</link><pubDate>Wed, 16 Nov 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-devsecops-recommendations/</guid><description>&lt;p>After eleven sessions building a full DevSecOps pipeline with GitLab — from Software Composition Analysis to Container Scanning, SAST, Secret Detection, DAST, merge request integration, and scheduled pipelines — Patrick Steger and I close the series with our recommendations. What worked, what tripped us up, and what we would tell anyone setting out to build the same pipeline today.&lt;/p></description></item><item><title>GitLab DevSecOps Part 11: Scheduled Pipelines for Production Code</title><link>https://romanoroth.com/en/blogs/gitlab-devsecops-schedule-pipeline/</link><pubDate>Wed, 09 Nov 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-devsecops-schedule-pipeline/</guid><description>&lt;p>Over ten sessions we wired six security tools into a GitLab pipeline that fires on every commit and every Merge Request. So are we done? Not quite. Code in production sits there for weeks or months, and during that time researchers keep finding new CVEs in the dependencies you are already shipping. In Part 11 of the GitLab DevSecOps series, Patrick Steger and I add a scheduled pipeline so the production branch gets re-scanned automatically — without anyone having to push a commit.&lt;/p></description></item><item><title>GitLab DevSecOps Part 10: How to Do a Merge Request the Right Way</title><link>https://romanoroth.com/en/blogs/gitlab-devsecops-merge-request/</link><pubDate>Wed, 02 Nov 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-devsecops-merge-request/</guid><description>&lt;p>In the previous nine sessions Patrick Steger and I built a GitLab DevSecOps pipeline that runs SAST, secret detection, software composition analysis, container scanning and DAST. Useful — but only if it actually catches issues &lt;em>before&lt;/em> they reach the default branch. In Part 10 we close that loop: we wire the pipeline into Merge Requests so every change is scanned, the deltas against the default branch are visible, and approvals are required when new high or critical vulnerabilities appear.&lt;/p></description></item><item><title>GitLab DevSecOps Part 9: Overcoming Vulnerability Management Challenges</title><link>https://romanoroth.com/en/blogs/gitlab-devsecops-vulnerability-management/</link><pubDate>Wed, 12 Oct 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-devsecops-vulnerability-management/</guid><description>&lt;p>After eight sessions of adding scanners to our GitLab pipeline — SAST, secret detection, SCA, license compliance, container scanning, DAST — we now have a different problem. We have hundreds of vulnerability findings. In Part 9, Patrick Steger and I look at GitLab&amp;rsquo;s built-in Vulnerability Management: what it gives you, where it falls short, and how to actually triage findings without losing your mind.&lt;/p></description></item><item><title>GitLab DevSecOps Part 8: Dynamic Application Security Testing (DAST)</title><link>https://romanoroth.com/en/blogs/gitlab-devsecops-dast/</link><pubDate>Wed, 05 Oct 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-devsecops-dast/</guid><description>&lt;p>Everything we have done in the GitLab DevSecOps pipeline so far has been static — analysis of source code, dependencies, containers and configuration. In Part 8, Patrick Steger and I cross the line into Continuous Delivery and add Dynamic Application Security Testing. DAST means we deploy the application, start it, and then attack it from the outside with an automated penetration testing tool. GitLab ships this capability out of the box, powered by OWASP ZAP.&lt;/p></description></item><item><title>GitLab DevSecOps Part 7: Finding Secrets in Your Code with Secret Detection</title><link>https://romanoroth.com/en/blogs/gitlab-devsecops-secret-detection/</link><pubDate>Wed, 28 Sep 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-devsecops-secret-detection/</guid><description>&lt;p>Hard-coded passwords and API keys are still one of the most common ways credentials leak. They get committed by accident, stay in the git history forever, and only show up when someone is already exploiting them. In Part 7 of our GitLab DevSecOps series, Patrick Steger and I add Secret Detection to the same pipeline we have been growing — one line of YAML — and then look at what GitLeaks actually finds, what it quietly misses, and what to do about it.&lt;/p></description></item><item><title>GitLab DevSecOps Part 6: How to Use Container Scanning</title><link>https://romanoroth.com/en/blogs/gitlab-devsecops-container-scanning/</link><pubDate>Tue, 06 Sep 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-devsecops-container-scanning/</guid><description>&lt;p>We have already wired SAST, secret detection, and software composition analysis into the GitLab pipeline. Those checks cover the source code and its dependencies — but the artifact we actually ship is a container image. Operating system packages, the base image, and everything copied in along the way can carry vulnerabilities of their own. In Part 6 of our series, Patrick Steger and I add container scanning to the pipeline, build a Docker image from the jar we compiled earlier, and push it through Trivy and Grype.&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><item><title>GitLab DevSecOps Part 4: How to Ensure License Compliance</title><link>https://romanoroth.com/en/blogs/gitlab-devsecops-license-compliance/</link><pubDate>Wed, 24 Aug 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-devsecops-license-compliance/</guid><description>&lt;p>You ship a Java application that depends on Spring Boot, which depends on dozens of other libraries, each with its own license — and most teams cannot tell you what those licenses actually are. In Part 4 of our GitLab DevSecOps series, Patrick Steger and I add license compliance to the pipeline so the question is answered automatically on every commit. The good news: with GitLab Ultimate, this is one template line away.&lt;/p></description></item><item><title>GitLab DevSecOps Part 3: Software Composition Analysis with Gemnasium</title><link>https://romanoroth.com/en/blogs/gitlab-devsecops-sca/</link><pubDate>Wed, 17 Aug 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-devsecops-sca/</guid><description>&lt;p>Your code is the small part. The libraries you pull in are the big part — and that is where most of your CVEs live. In Part 3 of the GitLab DevSecOps series, Patrick Steger and I bring up a tiny Spring Boot demo, wire it into a GitLab pipeline, and then add Software Composition Analysis with a single include line.&lt;/p></description></item><item><title>GitLab DevSecOps Part 1: What Is GitLab and Why Shift Security Left?</title><link>https://romanoroth.com/en/blogs/gitlab-devsecops-introduction/</link><pubDate>Wed, 10 Aug 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-devsecops-introduction/</guid><description>&lt;p>Why does security still get bolted on at the end of the development process, and how do we move it earlier without slowing teams down? In Part 1 of our GitLab DevSecOps series, Patrick Steger and I set the stage: what GitLab is, what shifting security left really means, and which CI/CD concepts you have to understand before you can build a DevSecOps pipeline that actually works.&lt;/p></description></item><item><title>GitLab DevSecOps Part 2: Creating a Simple Project and Your First Pipeline</title><link>https://romanoroth.com/en/blogs/gitlab-devsecops-creating-a-project/</link><pubDate>Wed, 10 Aug 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-devsecops-creating-a-project/</guid><description>&lt;p>Before we can shift any security checks left, we need a project, a repository, and a pipeline that actually builds something. In Part 2 of our GitLab DevSecOps series, Patrick Steger and I log into GitLab, create a new .NET Core project from a template, and look at the &lt;code>.gitlab-ci.yml&lt;/code> file that GitLab generates for us — including the build and test jobs that will become the foundation for everything we add later.&lt;/p></description></item><item><title>DevOps Explained: What do &amp;quot;DevOps Engineers&amp;quot; actually do at Zühlke?</title><link>https://romanoroth.com/en/blogs/devops-explained-what-do-devops-engineers-actually-do-at-zuehlke/</link><pubDate>Fri, 17 Jun 2022 15:59:46 +0000</pubDate><guid>https://romanoroth.com/en/blogs/devops-explained-what-do-devops-engineers-actually-do-at-zuehlke/</guid><description>&lt;p>Have you ever wondered what “DevOps Engineers” actually do? What does “DevOps” even mean actually? This blog post aims to explain the concept of DevOps and the value that it&lt;/p></description></item><item><title>Feature Toggles: What, Why, How?</title><link>https://romanoroth.com/en/blogs/feature-toggles-what-why-how/</link><pubDate>Wed, 30 Mar 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/feature-toggles-what-why-how/</guid><description>&lt;p>Feature toggles are one of those concepts that sound simple on the surface but unlock enormous power in practice. In this DevOps Meetup Zurich session, I team up with Ben Rometsch, founder of Flagsmith, to explain the what, why, and how of feature toggles. We cover the foundational concepts of CI/CD that make feature toggles necessary, the difference between deployment and release, and how modern feature flagging platforms enable progressive rollouts, user segmentation, and A/B testing.&lt;/p></description></item><item><title>What Is Continuous Deployment (CD)?</title><link>https://romanoroth.com/en/blogs/what-is-continuous-deployment/</link><pubDate>Thu, 06 Aug 2020 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/what-is-continuous-deployment/</guid><description>&lt;p>Continuous Deployment is the final, most aggressive step in the CI/CD progression. CI proves the code builds and the unit tests pass. Continuous Delivery proves the artifact works in a production-like environment. Continuous Deployment removes the last manual checkpoint: if every test along the way is green, the change goes straight to production. No &amp;ldquo;deploy&amp;rdquo; button, no Friday-afternoon release window, no human in the loop for the final step.&lt;/p></description></item><item><title>What Is Continuous Delivery (CD)?</title><link>https://romanoroth.com/en/blogs/what-is-continuous-delivery/</link><pubDate>Wed, 05 Aug 2020 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/what-is-continuous-delivery/</guid><description>&lt;p>Continuous Integration ends with a tested artifact. That sounds great, but a green build does not mean the software actually works in a realistic environment. Unit tests run in isolation. Integration tests run against mocks. Until you put the software somewhere that looks like production and exercise it under real conditions, you have not really proven anything. Continuous Delivery is the step that closes that gap.&lt;/p></description></item><item><title>What is CI/CD?</title><link>https://romanoroth.com/en/blogs/what-is-ci-cd/</link><pubDate>Tue, 04 Aug 2020 18:49:47 +0000</pubDate><guid>https://romanoroth.com/en/blogs/what-is-ci-cd/</guid><description>&lt;p>In traditional software development, software is merged and tested by all developers in one big single integration step that usually takes weeks or even months. Since this only happens every few months, this step is very time-consuming.&lt;/p></description></item><item><title>What Is Continuous Integration (CI)?</title><link>https://romanoroth.com/en/blogs/what-is-continuous-integration/</link><pubDate>Tue, 04 Aug 2020 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/what-is-continuous-integration/</guid><description>&lt;p>In traditional software development, integration was a single, painful event. Every developer worked in isolation for weeks or months, and at the end the team merged everything in one big bang. The integration step took weeks, sometimes months. Conflicts piled up, bugs hid in the seams between modules, and nobody could say with confidence whether the system actually worked. Continuous Integration was invented to make that pain disappear.&lt;/p></description></item></channel></rss>