Do you like coffee? Personally, I adore it in completely different versions. Be it a latt…

Do you like coffee? Personally, I adore it in completely different versions. Be it a latte, be it a raf, be it with water or with almond ( As a representative of the zoomer generation, and also a resident of Moscow, I have to feed stereotypes ). But today we’re not really going to talk about coffee. 😉

Mine just came out on Habré new article, in which I tried to talk about supply chain security ( Supply Chain Security in the language of Shakespeare ) through the metaphor of the coffee making process. I came to write it quite simply: SBOM is often explained as a list of products or ingredients, and when I thought about supply chain attacks ( crazy thoughts really love my head ), I was drinking coffee. All these components became friends in my skull and created an idea that I was able to develop into a full-fledged article

In a nutshell, the idea of the article is this: grains ( code and dependencies ), roasting ( CI/CD and build ), filter ( SBOM ), water ( infrastructure ) and barista ( people and processes ) work together to create the coffee you drink without overseeing each individual component and step. You just trust this whole chain. And if somewhere along the way you were mixed with “something extra”, the result may be something normal in appearance, but terrible in taste ( or even unsafe for health ). You can read more about my thoughts in the article, and here we move on to why I wanted to write this post in the first place ( well, besides just telling you about the publication of my article, of course 😏 )

I think the industry has finally stopped pretending that modern development is just writing software. Now development is more like assembling a product. We no longer write software so much as construct a solution based on a huge number of ready-made foreign parts, which in turn live a life of their own. The dependencies we added to the project pull transitive dependencies ( about which we are not necessarily and not always aware ). Packages are updated without our approval ( so I don’t recommend using latest anywhere ). There is a lot to describe here

But in the end, it all comes to the point that the security of this complex, complex product is no longer equal to the security of your repository. You can lick your code to a shine, triage all the SAST-findings, close yourself with rules... and still get and an incident, because the weak link was not on our side at all, but somewhere in the dependency that someone unsuccessfully updated 🤌

That’s why supply chain attacks are so annoying. You seem to have done everything correctly, but they break you through “tool”, “plugin”, “package”, “update”, “image” ( underline what is necessary), and not through what you yourself wrote. And it seems to me that the main shift in recent years is that we are gradually moving away from the killer concept of the “Safety as a bonus” level to "Security by design"

Modern security is not about deploying one scanner and checking a box on a report. You need to see your supply chain as a complete system. Understand where the trust points begin, who can influence the assembly, which components we actually check, etc. And Security by design in the context of the supply chain ( and in general ) is rather a habit of thinking not only about the code we write, but also about the path that this code takes before being sold

Because the user only sees a cup of coffee. He does not have to understand beans, filters and roasting. He would just like to drink normal coffee. And if something goes wrong, he will not figure out at what stage the error occurred. Responsibility will always remain with the one who prepared this coffee for him. ☕️

P.S. I would be very grateful if you read the article and share your opinion in the comments ( here or on Habré )

#information_security