“Forking” open source components

 

Note: My book “Introduction to SBOM and VEX” should be available on Amazon within 1-2 weeks (I’ll let you know when it’s available, of course). This is a section from the book. It addresses a topic I’ve always meant to address in a blog post – now I get two for the price of one!

Software suppliers often edit open source components before they incorporate them into their product. This is called “forking” the component, since the supplier has now created a different component from the one they started with. They do this for multiple reasons, including fixing a vulnerability in a component and making a change to the functionality of a component. Of course, under most open source product licenses, this is a completely legitimate practice.

However, when they do this, the supplier needs to keep in mind that they should no longer list the original component in their SBOM. This is because the altered code means there can no longer be any assurance that the forked component in the product is subject to the same vulnerabilities as the original component – and that the forked component is not subject to vulnerabilities that the original component is not subject to.

The supplier has the option of renaming the forked component and setting it up as a separate project on GitHub; they would then need to report vulnerabilities for it, make patches publicly available, etc. However, it will probably be much easier for the supplier just to treat the forked component as part of their own code, meaning from now on they will report all vulnerabilities under the product’s identifier.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.

I lead the OWASP SBOM Forum. If you would like to join or contribute to our group, please go here, or email me with any questions.