draft for open source risks article

.gitmodules

@@ -7,3 +7,6 @@
 [submodule "themes/hugo-mastodon-comments"]
 	path = themes/hugo-mastodon-comments
 	url = https://src.mehl.mx/mxmehl/hugo-mastodon-comments
+[submodule "themes/hugo-admonitions"]
+	path = themes/hugo-admonitions
+	url = https://github.com/KKKZOZ/hugo-admonitions.git

config.toml

@@ -1,7 +1,7 @@
 baseurl = "https://mehl.mx/"
 languageCode = "en-GB"
 title = "Max Mehl"
-theme = [ "hugo-sustain", "hugo-cloak-email", "hugo-mastodon-comments", "hugo-snap-gallery" ]
+theme = [ "hugo-sustain", "hugo-cloak-email", "hugo-mastodon-comments", "hugo-snap-gallery", "hugo-admonitions" ]
 
 [markup.highlight]
 codeFences = true

content/blog/2024-03-open-source-risks.md

@@ -0,0 +1,15 @@
+---
+title: "Managing Risks in Open Source without Ignorance and Fear"
+date: 2025-03-24
+categories:
+  - english
+tags:
+  - ospo
+headerimage: /blog/file-cabinet.jpg
+headercredits: Neatly organise your records
+---
+
+Historically, a lot of effort in the sphere of Open Source Program Offices has been spent on two things: getting accurate data about the exact usage and metadata of third-party Open Source projects and getting data about risks attached to it. Today, the barrier of creating proper SBOMs has become somewhat low and there are countless metrics that point to potential issues, and what we see is quite frustrating: a huge pile of measured problems which are hard to impossible to fix in practice. Let's explore some actionable options.
+
+> [!INFO]
+> Warning: This operation will delete all data.