<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>DevOps on Ben Petito</title><link>http://peti.to/tags/devops/</link><description>Recent content in DevOps on Ben Petito</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Mon, 27 Jul 2026 09:00:00 +0930</lastBuildDate><atom:link href="http://peti.to/tags/devops/index.xml" rel="self" type="application/rss+xml"/><item><title>The Tyranny of the Default</title><link>http://peti.to/posts/the-tyranny-of-the-default/</link><pubDate>Mon, 27 Jul 2026 09:00:00 +0930</pubDate><guid>http://peti.to/posts/the-tyranny-of-the-default/</guid><description>&lt;p&gt;This term was coined by Steve Gibson on his &lt;a href="https://www.grc.com/securitynow.htm" target="_blank" rel="noopener"&gt;Security Now&lt;/a&gt; podcast many years ago. Steve realised that most people will never touch or change the default settings/options that come with any software. As part of delivering custom software solutions to our customers, this is something I think about fairly often, as the choices we make, while we give our customers levers to pull, rarely get changed.&lt;/p&gt;
&lt;p&gt;I tripped over this last week in a slightly different situation while investigating for a customer what static analysis and CVE detection was in place for their application. We use GitHub for almost all of our projects and have a mature, well-worn CI pipeline (the thing that builds the application and runs checks and tests when new code is pushed). But for this customer, we host it in their Bitbucket repository.&lt;/p&gt;</description></item></channel></rss>