<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Security on Adur</title>
    <link>https://adurr.gitlab.io/tags/security/</link>
    <description>Recent content in Security on Adur</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>&lt;a href=&#34;https://creativecommons.org/licenses/by-nc/4.0/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;CC BY-NC 4.0&lt;/a&gt;</copyright>
    <lastBuildDate>Wed, 27 May 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://adurr.gitlab.io/tags/security/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Secure Pipeline Template</title>
      <link>https://adurr.gitlab.io/projects/secure-pipeline-template/</link>
      <pubDate>Wed, 27 May 2026 00:00:00 +0000</pubDate>
      <guid>https://adurr.gitlab.io/projects/secure-pipeline-template/</guid>
      <description>&lt;p&gt;&lt;strong&gt;&amp;ldquo;Six Gates to Production&amp;rdquo;&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Most CI/CD templates stop at build-and-deploy. This one treats every commit as untrusted until six independent security tools have examined it. It is the pipeline I wish every client already had.&lt;/p&gt;&#xA;&lt;h2 id=&#34;what-problem-this-solves&#34;&gt;What problem this solves&lt;/h2&gt;&#xA;&lt;p&gt;A container image landing in production without being scanned is a liability. But bolting a scanner onto an existing pipeline is fragile: the scanner runs, the output gets ignored, and the deployment continues anyway. This template makes security gates non-negotiable. A critical finding in Semgrep, Trivy, or any other tool blocks the pipeline. A warning gets logged to a SARIF report. The deployment only proceeds when every gate passes.&lt;/p&gt;</description>
    </item>
    <item>
      <title>AI-Assisted DevSecOps Workflows</title>
      <link>https://adurr.gitlab.io/projects/ai-devsecops-workflows/</link>
      <pubDate>Mon, 18 May 2026 00:00:00 +0000</pubDate>
      <guid>https://adurr.gitlab.io/projects/ai-devsecops-workflows/</guid>
      <description>&lt;p&gt;&lt;strong&gt;&amp;ldquo;Putting LLMs in the Deployment Pipeline&amp;rdquo;&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Should an LLM read your infrastructure code? Should it suggest Terraform changes? Should it triage security alerts? This guide answers those questions. It is not a tutorial. It is a living document that records what works, what breaks, and what security controls are non-negotiable when AI assistants touch production systems.&lt;/p&gt;&#xA;&lt;h2 id=&#34;what-this-is&#34;&gt;What this is&lt;/h2&gt;&#xA;&lt;p&gt;A Hugo + Docsy documentation site that covers:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Core architecture patterns for AI-assisted operations&lt;/li&gt;&#xA;&lt;li&gt;A comparison of LLM assistant frameworks (oh-my-opencode-slim, Aider, Claude Code, ShellGPT, AIChat)&lt;/li&gt;&#xA;&lt;li&gt;Security concerns specific to AI in DevSecOps: prompt injection, data exfiltration, over-privileged agent permissions&lt;/li&gt;&#xA;&lt;li&gt;Three paradigms: orchestrated multi-agent, single-agent pair programming, and CLI command generation&lt;/li&gt;&#xA;&lt;li&gt;Production-ready configuration templates for OpenCode Go&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h2 id=&#34;the-zero-trust-principles&#34;&gt;The zero-trust principles&lt;/h2&gt;&#xA;&lt;p&gt;AI assistants in DevSecOps must follow the same principles as any other automated system with production access:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
