This episode is not about tools. This time we will take a look on the SBOM itself. We discussed basics of SBOMs, it is time to go a little bit deeper.
First thing which needs explanation is what is the difference between Software Composition Analysis (SCA) and SBOM? Both are analyzing the dependencies!
Well, not exactly.
SCA is an automated process to identify open source components in code base and evaluate these components against licenses, vulnerabilitites, security issues, etc. SBOM is the report generated by the SCA software. SBOM is highly defined and structured document and not all SCA tools generate their reports in the acceptable as SBOM way. These SBOMs are then compared with multiple up-to-dated databases to ensure the report quality.
So, in very simple way we can say that SCA is a tool where SBOM is a data. SBOM contains list of used components with some specific information. But SBOM itself doesn't care how its generation was done.
We talk here about different aspects of one approach to ensure security and quality which can be applied in C-SCRM in the organization.
I read a lot about it currently and I saw many reports where authors predict some numbers related to percentage of companies which will be use SCA and SBOMs in next few years. Honestly, I do not believe in these predictions. The awareness of these solutions is quite low now and implementation even lower. Yes, we are more aware of SCA, but SBOM, which looks like natural extension to the process, is not very well known. That is my personal opinion :)
How the SBOM should look is described, as I mentioned, in quite strict way in standard. If you like to go deeper, here is the link.
Let's take a look on three main perspectives (as it is called), where SBOM is very useful. The perspectives are
- Produce
- Choose
- Operate
Produce software
The company who creates the software, by attaching the SBOM to their package will gain not only external (sell) benefits, but internal (development) as well. For example, by monitoring of the vulnerabilities in used packages, by knowing potential end date of lofe of specific component used in their software, by knowing all dependencies included in the code.
What is the benefit for external use? Well, simple - it gives the better possibilities to the partners to know "what is inside" and also creates, let's call it, "better picture" of the seller. Another words - "They know what they sell".
Below is a representation of areas of interest in Produce software perspective.
Choose software
Now, the ball flies to the second side of the field. The company interested in buying the product is able to (also) verify vulnerabilities, control and be aware of lifetime of the used components, control and understand licenses of the components, can target security analysis towards already defined targets.
Operate software
Final phase is when software is about to be bought and then operated. In this perspective the organization can use SBOM analysis as one of the decisive elements. During the operationa phase SBOM can help with independent mitigations (so the organization does not rely solely on the vendor), can better administer its assets and evaluate risks and usage.
That's conclude the second theory lesson in this series.
Top comments (0)