<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>GitHub Actions on Romano Roth</title><link>https://romanoroth.com/en/tags/github-actions/</link><description>Recent content in GitHub Actions on Romano Roth</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Romano Roth</copyright><lastBuildDate>Tue, 13 Jun 2023 00:00:00 +0000</lastBuildDate><atom:link href="https://romanoroth.com/en/tags/github-actions/index.xml" rel="self" type="application/rss+xml"/><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 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 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 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 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></channel></rss>