Chances are that if you are building any type of non-trivial software product, you are standing on the shoulders of giants and rely on an existing ecosystem of open source or commercial components. You cannot really compile even the simplest Hello World in C without leaning on the common C library.
Therefore, any software project is likely to have a supply chain, which simply put, means the set of open source and commercial components your product relies on. Some software stacks such as Node.js and Python, for instance, are notorious for bringing in a rather massive chain of dependencies.

(Image credit: Unknown)
With the dependencies, you are more than likely to bring in vulnerabilities. In addition to actively battling vulnerabilities in your own codebase, you need to track the vulnerabilities in your chain of dependencies. Besides making sense, vulnerability management is required to gain compliance with standards such as IEC 62443 and the upcoming EU Cyber Resilience act. Our very own Henry has written extensively about the CRA legislation on our blog (part 1 – overview, part 2 – comparison to IEC 62443 and part 3 – practical implications).
What is vulnerability management?
Vulnerability management is a continuous process to keep your products and customers safe from cyberattacks. Managing vulnerabilities involves multiple parts of your organisation from product development to product and security testing as well as from customer communications to the product delivery organisation. Threats needs to be identified, analysed and addressed. Security fixes need to be communicated and delivered to the customers, with an appropriate sense of urgency.
The aforementioned posts have covered the legislative aspects and practical implications of the CRA and vulnerability management extensively. In this series of articles, I will be concentrating on the part which is the dearest to me – vulnerability management in product development. In other words, the technical and process enablers to have your software teams managing their supply chain actively, effectively and natively integrated to their product development activity.
Vulnerability management in product development
Based on our experience, the general steps to take control of your supply chain within product development are:
- Pruning your dependencies. Is an external dependency really needed, or could it be replaced with code under your own control?
- Create an inventory of your dependencies. Luckily, the world has semi-standardised on a mechanism called Software Bill of Materials (SBOM), which is supported by many software stacks and package ecosystems.
- Track your vulnerabilities using the SBOM. More details on related analysis tools will be provided in later articles.
- Develop mechanisms for updating your product and delivering the update to your customers, with appropriate communication.
When considering vulnerability management, it is vital to take a systemic view of the product development process and follow time-tested DevOps practices. If applied carelessly, vulnerability management can become a chore which is easily forgot, neglected or even deprioritised. Similarly to other aspects of the development process, vulnerability management should be scrutinised in the spirit of continuous improvement, and it should involve seamless collaboration between teams and individuals. Everything that can be automated should be automated, and failures should be treated as learning opportunities. Most importantly, the feedback loops need to be tight – is is much cheaper to fix a vulnerability before it leaves your Git branch compared to fixing it at a customer site.
The next installment of this article series will concentrate on managing your supply chain inventory and tracking the vulnerabilities, including practical tips on tools and mechanisms available for vulnerability managements. Stay tuned!