In the ever-evolving cybersecurity landscape, the European Union’s NIS2 Directive (EU 2022/2555) introduces strict security requirements for organisations in critical sectors. For companies leveraging open-source solutions to accelerate product development and reduce development costs, a key question arises: can we still use free open-source software and be NIS2-compliant?
The COO of Uptime Solutions, Łukasz Bargiel, explains in a blog post whether open source and NIS2 can coexist and if there’s a need for industry-wide certification of commonly used open-source solutions.
Does NIS2 Impact Open Source?
NIS2 does not explicitly regulate open-source projects or maintainers, but it does place responsibility on organisations that use open-source components. The directive mandates that companies must:
- Assess and mitigate risks related to 3rd-party software (including open source).
- Ensure security measures for components integrated into their products.
- Report incidents if vulnerabilities in open-source software contribute to a security breach.
In other words, companies are free to use open-source software, but they must take full responsibility for securing it. NIS2 is not about restricting open source itself; it’s about ensuring that companies handle it responsibly. So, if a company chooses to use open-source solutions, it’s up to them to ensure it meets all standards – and it doesn’t matter that they did not develop it themselves.
Key Considerations for NIS2 Compliance When Using Open Source
Whilst NIS2 allows companies to use open-source solutions and still be compliant with regulations, there are several factors that one should keep in mind. Here are the most important aspects.
1. Supply Chain Security
NIS2 strongly emphasizes supply chain security, requiring companies to ensure that software suppliers follow security best practices. Since open-source components don’t have a traditional “vendor,” companies must adopt their own security measures: use well-maintained projects with active contributors, ensure the open source software follows secure development practices, and implement Software Bill of Materials (SBOMs) to track all dependencies.
If these practices are not followed, issues quickly arise. For example, the Log4Shell vulnerability (Log4j exploit) was a wake-up call for companies relying on open source. Many organizations had no visibility into their usage of Log4j, making them vulnerable to a severe security risk. This highlighted the importance of SBOMs and more proactive vulnerability management.
However, with robust security practices, like the ones we implement at Uptime, these issues can be easily avoided. In our day-to-day work, security is at the core of our software development process. Whether working with open-source or custom-built solutions, we implement strict security best practices, including SBOM tracking and proactive vulnerability monitoring, to ensure compliance with NIS2 and other cybersecurity frameworks.
2. Risk Management & Incident Reporting
Companies must also adopt a risk-based approach to cybersecurity, ensuring they can identify, monitor, and patch vulnerabilities in open-source software. Since NIS2 also mandates rapid incident reporting, organisations should continuously monitor open-source security advisories, automate vulnerability scanning and dependency management, and prepare response plans in case a critical open source vulnerability affects operations.
3. Additional Compliance Frameworks
Many companies already follow ISO 27001 for information security, but NIS2 introduces additional obligations specific to software supply chain security, making assessing the risks of using open-source parts critical.
The Big Question: Who’s Responsible for Open-Source Security?
A key challenge with NIS2 is that it assumes software vendors and their customers must work together to ensure security. But who is responsible for security in open-source projects, especially when many are maintained by unpaid contributors?
Whilst there are several possible approaches, one approach could be industry-led certification for open-source security. If this approach was to be taken, there could be non-profit organisations that audit and certify widely used open-source software as “NIS2-compliant”, a “NIS2-Ready” label could be created to help organisations confidently adopt open-source components, and governments or EU bodies could provide funding to support security audits for essential open-source tools.
Such initiatives could bridge the gap between the security demands of NIS2 and the reality of open-source development. But as the new directive is still… well, new, there’s lots of uncertainty, and many of the options are still being discussed. It makes sense to keep an eye out for any upcoming news.
The Role of Open Source in Modern Software
It’s also important to understand that talking about open-source is not hypothetical. These kinds of solutions are widely used, with 96% of proprietary codebases audited in 2023 containing some form of open-source software.
At the same time, 89% of vulnerabilities in audited codebases were found in open-source components, and only 50% of open-source projects are actively maintained, meaning security patches can be delayed or never come.
So, using open-source solutions under NIS2 is still possible and encouraged, but it’s important to make sure that necessary steps are taken to ensure compliance and security. We at Uptime have a great deal of experience in this field, so if you want to talk about your project, feel free to reach out!