I've been writing a lot here lately about supply chain attacks (https://t.me/maxienergy_c…

I've been writing a lot here lately about supply chain attacks ( https://t.me/maxienergy_channel/386). And the more I analyze such cases, the stronger the feeling that we are starting to lack just checking the composition of dependencies (and you should have had such an idea after my last three posts)

Because knowing what the application consists of is, of course, important. But now this is no longer enough 🤌

We are accustomed to the term SBOM. To simplify, this is a list of components from which the application is assembled (libraries, packages, versions, dependencies, etc.). SBOM is a good way to help us understand what is inside us, where a vulnerable library arrives, and what we need to look at first.

The problem is that SBOM answers primarily the question of the composition of the application, but almost does not answer the question of what all these components can (and should) do during the operation of the application. And the funny thing is that a dependency can look normal, officially installed, be present in the SBOM, pass SCA checks... and then you suddenly find out that it starts to climb into the network, read extra files, pull processes and perform actions that we did not expect

So let's talk about CBOM (Capability Bill of Materials). This is a completely new concept that only really took off last fall. As far as I know, this is the first time it has been mentioned in a work ( https://dl.acm.org/doi/10.1145/3719027.3765136) two researchers from Sweden. In essence, this is an attempt to describe not only the composition of the application, but also the permissible capabilities of its components. That is, the list of dependencies itself, and what they can do in general

A significant portion of modern supply chain attacks occur not through CVEs in Trivy output, but through the actual behavior of the dependency. Malicious postinstall, unexpected network call, reading secrets from the environment, trying to access the file system, etc.

And the CBOM concept suggests looking at dependencies not as ordinary blocks in the constructor that make up the software, but as entities with specific privileges. Roughly speaking, if a library is needed only to send HTTP requests, then it should not read keys, crawl through envs, or do anything else that no one asked it to do :)

This fits well with what I already wrote about in recent posts. Remember the case with axios ( https://t.me/maxienergy_channel/387), where the problem arrived transitively through an extra dependency and a malicious script at the installation stage. And the case with Trivy ( https://t.me/maxienergy_channel/388), where did the blow fall on the assembly and delivery infrastructure?

In all these stories one idea can be clearly seen that it is not enough for us to just know the list of components V. We also need to understand exactly how these components behave in runtime

That's why today I'm speaking at Merge Conf ( https://tatarstan2026.mergeconf.ru/speakers/development/cyber-security/knyazev)in Innopolis specifically with the CBOM theme. I want to convey to a large number of people what this concept is, why SBOM is no longer enough, how important it is to think about dependency control and why this whole concept will naturally become the next step for AppSec and DevSecOps 💯

If you're at Merge today, come to room 106. Let's discuss how to stop looking at dependencies only as a list of vulnerabilities and start perceiving them more objectively

#information_security