Download NIS2 Checklist
Feeling lost about where to start when it comes to the NIS2 Directive? That is why we decided to equip you with actionable steps on how to kick off your compliance journey and reach full compliance with ASEE.
At this year’s ALERT cybersecurity conference I had the opportunity to explore one of the most persistent questions in our field: is open source or proprietary software more secure — and how does software supply chain security reshape that conversation?
The debate over which is more secure — open source or proprietary software — has been ongoing for decades. Neither model is immune to cyberattack. Historically both have been compromised — especially via software supply chain attacks, which have surged dramatically over the past five years. For a long time, software supply chains remained invisible and underestimated but today, new regulatory mandates from the EU: NIS2, DORA and CRA are changing the rules of the game.
Today’s applications are rarely written from scratch. Instead, we construct modern software — like building with LEGO blocks — by combining components, libraries, frameworks, build tools, CI/CD pipelines, and external services. In fact, modern applications are composed of 70% to 90% open source code, and the estimated value of open source in 2024 exceeds $8 trillion dollars according to a Harvard Business School study.
Despite the dominance of open source, proprietary software has also been an entry point for attackers. High-profile examples include the 2020 SolarWinds breach or ByBit 2025.
A software supply chain attack is one where the attacker doesn’t target the victim directly, but instead compromises a third-party dependency — such as a software vendor, an open source project, or a build tool — which the victim inherently trusts. Malicious code is inserted into software and is then distributed to the real targets — often thousands of users and organizations.
Given the complexity of modern development and the creativity of attackers, these are now considered some of the most silent and most dangerous types of cyberattacks.
In response to the growing threat of software supply chain attacks, the EU has introduced several regulatory initiatives to improve software security across the board. The NIS2 Directive, the Cyber Resilience Act (CRA), and the Digital Operational Resilience Act (DORA) all aim to shift security expectations from optional best practices to legal obligations.
What’s crucial is that the conversation is no longer about which is “better” or “safer” — open source or proprietary. That debate has evolved. Today, the cybersecurity focus is on transparency, process maturity, continuous monitoring, and clear accountability. Whether code is open or closed matters less than how it’s managed, who maintains it, how quickly issues are addressed, and how well users are protected when things go wrong.
Regulatory frameworks are converging on a clear message: security must be built into every layer of the software supply chain. The EU’s Cyber Resilience Act (CRA), NIS2 Directive, and Digital Operational Resilience Act (DORA) all emphasize a proactive and accountable approach to managing third-party risks.
Challenges today’s security teams face:
To address these issues, regulations provide not just compliance requirements, but also a roadmap for building resilient supply chains. Below is a synthesis of their core recommendations:
Keep a complete and up-to-date inventory of all your software suppliers — including indirect and transitive dependencies such as open-source libraries. Use tools like SBOM (Software Bill of Materials) and VEX (Vulnerability Exploitability eXchange) to gain visibility and track exposures.
Establish clear policies that govern how software is sourced, integrated, and maintained. These policies should differ depending on the risk level — for example, distinguishing between cloud-based, on-premise, or embedded systems.
Embed security into your procurement process. Contracts must clearly define vendor responsibilities for patching, vulnerability disclosure, incident response timeframes, and liability — particularly in regulated sectors like finance and critical infrastructure.
Supply chain security is not a “set and forget” task. Establish continuous monitoring practices and regular reassessments of vendors, especially in the aftermath of a vulnerability disclosure or breach.
Go beyond pricing and delivery speed. Choose partners who can prove they implement security best practices — such as having secure SDLC processes, certifications (e.g., ISO 27001), or supplying SBOMs and VEX reports.
Incident response must be coordinated across organizational boundaries. Ensure your plan includes contact points at key suppliers, predefined escalation paths, and mutual obligations in the event of an attack involving the software supply chain.
The question isn’t whether open source or proprietary software is safer — both have their strengths and risks. The real question is: How well do you manage your software supply chain?
Security today is not just about the code — it’s about processes, monitoring, trust and accountability at every stage of development and deployment.
The software supply chain has become a strategic frontier for cybersecurity. To stay resilient, organizations must move from reactive protection to proactive governance — building security not just into the product, but around the entire ecosystem that supports it.
Feeling lost about where to start when it comes to the NIS2 Directive? That is why we decided to equip you with actionable steps on how to kick off your compliance journey and reach full compliance with ASEE.
