diff --git a/apps/website/public/images/golang-supply-chain-attacks.png b/apps/website/public/images/golang-supply-chain-attacks.png
new file mode 100644
index 00000000..869bca4a
Binary files /dev/null and b/apps/website/public/images/golang-supply-chain-attacks.png differ
diff --git a/apps/website/src/content/posts/supply-chain-attacks-in-the-golang-open-source-ecosystem.md b/apps/website/src/content/posts/supply-chain-attacks-in-the-golang-open-source-ecosystem.md
new file mode 100644
index 00000000..534608f0
--- /dev/null
+++ b/apps/website/src/content/posts/supply-chain-attacks-in-the-golang-open-source-ecosystem.md
@@ -0,0 +1,67 @@
+---
+title: "Supply Chain Attacks in the Golang Open-Source Ecosystem"
+description: "Learn how a typo-squatted supply chain attack silently compromised Golang packages for years, and discover essential tips to secure your open-source dependencies."
+createdAt: 1742942499926
+updatedAt: 1742942499926
+authors: ["david"]
+category: "After Work Talks"
+editors: ["velimir"]
+abstract: "Supply chain attacks pose an escalating threat within the open-source software ecosystem, as illustrated vividly by the recent compromise of the Golang module proxy. For over three years, attackers exploited a typo-squatted Golang package—boltdb-go/bolt—to infiltrate countless development projects undetected. Leveraging weaknesses in Go's module mirror caching mechanisms, malicious actors embedded harmful code, rebased repositories to conceal their tracks, and persisted invisibly in widely-used software stacks. This incident underscores critical vulnerabilities stemming from developers' implicit trust in package managers and official mirrors optimized primarily for speed and reliability rather than security. The attack not only exposed severe shortcomings in dependency management but also serves as a stark reminder that widely-used packages are not inherently secure. This article delves into the anatomy of the Golang supply chain attack, exploring how attackers executed their strategy, why it went unnoticed for so long, and what systemic weaknesses made this compromise possible. Additionally, it outlines actionable steps developers can take immediately—such as leveraging dependency auditing tools, enforcing strict version control, and adopting checksum verification—to significantly reduce exposure to similar threats. Ultimately, addressing the rising threat of supply chain attacks requires a collective shift towards proactive security practices across the software development lifecycle, reaffirming that security vigilance remains paramount in an open-source-dependent industry."
+image: "/images/golang-supply-chain-attacks.png"
+draft: false
+---
+
+## A Wake-Up Call for Go Developers: Supply Chain Attacks in the Open-Source Ecosystem
+
+If you've been paying attention to software security news lately, you've probably heard about the [Go Module Mirror](https://proxy.golang.org/) serving a backdoored package for over three years. 
+
+Yeah, you read that right... **three years**. The attack leveraged a typo-squatted package and a fundamental flaw in how Go's module proxy caches dependencies. 
+
+Thanks to [Socket's excellent article](https://socket.dev/blog/malicious-package-exploits-go-module-proxy-caching-for-persistence), we can dig a bit deeper into this attack.
+
+### The Anatomy of the Attack
+
+Here's what went down:
+
+Attackers created a typo-squatted package named `boltdb-go/bolt` instead of the legitimate and widely used `boltdb/bolt`, deceiving thousands of developers. They then uploaded a malicious version of this package to GitHub, embedding a hidden remote access mechanism. The Go Module Mirror, designed for caching packages , inadvertently cached and stored the malicious version.
+
+After ensuring the malicious package was cached, the attackers quietly rebased the repository back to a clean version, misleading manual reviewers into believing everything was safe. Developers continued unknowingly installing the compromised version because the Go Module Mirror never verified subsequent updates to cached packages, allowing the attack to be undetected for years.
+
+This is a textbook case of a supply chain attack. It's an attack that poisons the well that many developers drink from. The attacker injects malicious code at the package level and waits for unsuspecting developers to install it.
+
+## The Trust in Open Source
+
+The core issue here is that our entire industry is built on the assumption that package managers and mirrors will "just work" safely. 
+
+But here’s the uncomfortable truth: **we’re outsourcing trust to systems that weren’t built with security as a first-class concern.**
+
+Go’s module proxy is designed for performance and availability, not security. Once a package version is cached, it stays available, even if the original source is later modified or removed. That’s great for reliability but terrible when an attacker exploits it to persist malicious code for years.
+
+This isn’t just a Go problem. We’ve seen similar attacks across **npm, PyPI, and Cargo**. The pattern is the same: developers rely on third-party dependencies, package managers optimize for performance over security, and attackers take advantage of it.
+
+## What you can do right now
+
+It’s easy to say "just audit your dependencies," but let’s be real, no one is manually checking every package they install. So, what practical steps can we take?
+
+- Go’s default module proxy has no built-in malware scanning. Consider using tools like [Socket](https://socket.dev/), [deps.dev](https://deps.dev/), or any other dependency analysis tools.
+
+- Instead of relying on `latest` package version, explicitly define which version you should be using. This won’t prevent all attacks, but it limits exposure.
+
+- Run automated dependency analysis like `govulncheck`, `npm audit`, or `pip-audit`. These tools won’t catch everything but provide an extra layer of defense.
+
+- Use checksums and signature verification where possible. If your build pipeline supports it, enforce checksum verification on dependencies.
+
+## The Bigger Picture
+
+This incident is another wake-up call for the entire software industry. 
+
+**We can’t blindly trust third-party code, even when it’s hosted on official mirrors.** 
+
+Supply chain security is a real-world problem that has already led to major breaches and compromises.
+
+Google has since removed the malicious package and added it to the Go vulnerability database, but the damage is already done. This attack reminds us that while Go, Rust, Python, and JavaScript all have safeguards to prevent classic memory safety issues, the real risk is in the dependencies we import without question.
+
+Just because a package is widely used doesn’t mean it’s safe. It’s on us, developers, to be more proactive about security.
+
+Stay safe out there, and check your dependencies before shipping.
+