<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Secrets-Management on F. Latini - IT Engineer</title><link>https://latini.dev/tags/secrets-management/</link><description>Recent content in Secrets-Management on F. Latini - IT Engineer</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 30 Jul 2026 08:00:00 +0000</lastBuildDate><atom:link href="https://latini.dev/tags/secrets-management/index.xml" rel="self" type="application/rss+xml"/><item><title>Your Security Policy Needs a Paved Road</title><link>https://latini.dev/posts/your-security-policy-needs-a-paved-road/</link><pubDate>Thu, 30 Jul 2026 08:00:00 +0000</pubDate><guid>https://latini.dev/posts/your-security-policy-needs-a-paved-road/</guid><description>&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; - Almost every security control I meet in the wild was shipped as a rule and never as a road. The policy exists, the scanner runs, the build fails, and there is still a long-lived API key in a &lt;code&gt;.env&lt;/code&gt; file, because nobody ever built the thing a developer is supposed to do &lt;em&gt;instead&lt;/em&gt;. A rule without a road is a tax you levy on developers, and taxes get evaded, creatively and quietly. Treat secrets and policy the way you&amp;rsquo;d treat any other platform capability: distribute identity instead of secret values so the credential is short-lived and nobody handles it; ship every new control with a default that already satisfies it, an error message that names the fix, and a migration for what already exists; roll it out observe, then warn, then enforce; and make exceptions a first-class artefact that expires. The security team writes the rule. The platform team owes the road. Ship them in the same change or don&amp;rsquo;t ship the rule.&lt;/p&gt;</description></item></channel></rss>