Supply chain attacks.

diff --git a/content/posts/supply-chain-attacks-industry-never-learns.md b/content/posts/supply-chain-attacks-industry-never-learns.md
new file mode 100644 (file)
index 0000000..a7a828b
--- /dev/null
+++ b/content/posts/supply-chain-attacks-industry-never-learns.md
@@ -0,0 +1,64 @@
+---
+title: "Supply chain attacks & how industry never learns"
+date: 2022-09-22T20:45:00+03:00
+description: "If you have been in the industry for the last several years, you may have noticed an ever-increasing trend of convenience package managers. They all come riddled with design flaws at expense of your security (or lack thereof)."
+tags: ['rant','opinion']
+type: blog
+draft: false
+---
+
+If you have been in the industry for the last several years, you may have noticed an ever-increasing trend of
+"convenient package managers for your favourite programming language". It's very much relevant in languages
+such as Python, JavaScript, Rust and almost every new emerging programming language. However,
+[all](https://thehackernews.com/2022/09/malicious-npm-package-caught-mimicking.html) [of](https://thehackernews.com/2022/05/researchers-uncover-rust-supply-chain.html)
+[them](https://jfrog.com/blog/python-wheel-jacking-in-supply-chain-attacks/) [are](https://thehackernews.com/2022/04/npm-bug-allowed-attackers-to-distribute.html) [very](https://thehackernews.com/2022/07/over-1200-npm-packages-found-involved.html)
+[much](https://thehackernews.com/2022/07/researchers-uncover-malicious-npm.html)
+[possible](https://thehackernews.com/2022/05/malicious-npm-packages-target-german.html) [targets](https://thehackernews.com/2022/03/over-200-malicious-npm-packages-caught.html)
+[of](https://snyk.io/blog/open-source-maintainer-pulls-the-plug-on-npm-packages-colors-and-faker-now-what/)
+[supply](https://thehackernews.com/2021/07/several-malicious-typosquatted-python.html)
+[chain](https://thehackernews.com/2021/11/11-malicious-pypi-python-libraries.html)
+[attacks](https://thehackernews.com/2022/03/a-threat-actor-dubbed-red-lili-has-been.html).
+Those are just *some* of the examples. There are countless instances of this happening and they will continue to
+happen due to low effort, high value and medium success.
+
+## Surely this isn't as common?
+It is much more common than you think. All a hacker needs to do is either hijack an existing registry user or
+"typosquat" a package on very popular packages. This is further made easier by registries listing statistics such
+as the "Weekly Downloads" and "Total Downloads" giving you a rough idea of how large of a pie you could poison.
+All of this is doable by social engineering or betting on people making typos, which we all do make.
+
+## What's your proposed solution?
+Reduce amount of dependencies in your code. That's the easiest thing you can do to minimize attack vectors.
+Usually libraries are created with "cover-all" functionality in mind, rather than just catering to your specific
+use case, and even if it does cater to your use case, chances are it's overengineered. You will much more benefit
+in performance, security and code quality by creating a lot of those said dependencies yourself - an added bonus
+is becoming a much more versed programmer.
+
+Another solution is to fork the dependencies if you do need them, **audit the code of what you're going to be using**,
+use **direct verifiable links rather than just package name** and if the package manger supports any form of hash checking
+or other means to do so, use it!
+
+Which brings me to another point, the way a lot of current registries work are on blind trust basis - you trust the registry
+to retrieve you code by a simple prompt - the package name and version, you do not ask for any hash verification, neither do you
+ask for means to verify the author. You can't even be sure that package v0.0.1 is the same thing as it was a week ago, because that
+data can be overwritten by the package author. There are so many clear design flaws with these package managers that are essentially
+dumb downloaders without any regard to safety.
+
+Even the simplest sha256 check would improve the situation, if nothing else. ReactOS Applications Manager is a lot more secure
+by design compared to all of the afforementioned package managers just by the hash check alone.
+
+## Okay, but how does the industry "never learn"?
+Simple, the package managers are still growing in popularity, there is no blowback, new developers are still being lead to use
+NPM, PyPi, Rust crates, public CDN CSS/JavaScript libraries, etc. There is no practice of auditing the code you are pulling at all.
+The industry is increasing their bet on blind trust to save a penny in developer hour cost to achieve their desired result.
+In this industry, money speaks, so reducing costs by using fewer developers and shortcuts with these package managers is going to
+be the standard going forward. Maybe this will one day change with more rapid supply chains that cost companies millions or more per
+year in ransoms.
+
+
+### Hater.
+Yes. You can't always skip the hard work. If this post offended you, I'm not sorry either.
+
+# 
+Thanks for reading,
+- Cernodile