<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Hardcoded Credentials on guy@secdev.uk</title>
    <link>https://www.secdev.uk/blog/tags/hardcoded-credentials/</link>
    <description>Recent content in Hardcoded Credentials on guy@secdev.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <copyright>Guy Dixon | guy@secdev.uk</copyright>
    <lastBuildDate>Sat, 17 Jan 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.secdev.uk/blog/tags/hardcoded-credentials/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Secrets in Source Code: Finding and Eliminating Hardcoded Credentials</title>
      <link>https://www.secdev.uk/blog/technology/2026-01-17-secrets-in-source-code/</link>
      <pubDate>Sat, 17 Jan 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2026-01-17-secrets-in-source-code/</guid>
      <description>&lt;p&gt;Hardcoded credentials are one of the most common and most preventable vulnerability classes out there. API keys, database passwords, encryption keys, and service tokens embedded directly in source code end up in version control, build artifacts, container images, and log files. Once a secret reaches a Git repository, it persists in the history even after the offending line is deleted. When I started researching how often this happens in practice, the numbers were staggering, public reports of leaked credentials on GitHub alone run into the millions per year. In this post I&amp;rsquo;ll cover the patterns that lead to hardcoded secrets, the tools that detect them, and the architecture changes that eliminate them for good.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
