NIS2: Understanding key software security requirements

After high profile attacks like Solar Winds and Kaseya, global lawmakers have responded to software supply chain threats and their impact on critical infrastructure and entire economies with directives like the European Union’s Network and Information Systems 2 (NIS2).

October of 2024 marked the implementation deadline for NIS2, which expands the scope and requirements of its predecessor (NIS1) and critically shifts the liability to meet those requirements from just corporate consequences to personal ones. An organization’s management team and board of directors are now personally responsible for meeting the directive.

The legislation’s vulnerability management and software supply chain regulations have the potential to change the way developers build with open source software, introducing new software lifecycle security requirements and attestations like Software Bills of Material (SBOMs) and CVE reporting. While these changes are designed to lead to more secure software, meeting new requirements could lead to considerable workloads and toil on the part of security and developer teams.

Below we’ve provided background on the directive and some of the more prominent requirements, as well as some insights into how Chainguard can help your organization meet NIS2 compliance without impacting development time and velocity.

Who’s impacted by NIS2?

Introduced initially in 2020, NIS2 expands the scope of NIS1 to cover a much wider range of sectors, grouped into two broad buckets. “Essential Entities” are designated as high criticality including core utilities like energy, water, transportation, and infrastructure, while “Important Entities” cover broad sectors of the European economy, like manufacturing, food and chemical sectors and a big chunk of digital businesses. See a full list here.

Any organization with over €10 million in revenue in a given country or over 50 employees has to comply with NIS2. Regardless of where an organization is headquartered, if it does enough business in the EU, it will need to comply.

The expanded reach of NIS2 is a clear indication of the significance EU lawmakers have put on the cybersecurity posture of EU organizations, serving as a reset for what secure software development best practices should look like.

What are the requirements?

Requirements fall into three broad areas, with a focus on risk management, security measures, and cooperation and information sharing. While the directive itself encompasses more cybersecurity disciplines than just software development, there are clear developer-impacted requirements highlighted across risk management, security measures, and cooperation and information sharing:

• Risk management: Encompassing threat assessments, vulnerability management like CVE reporting, and incident response plans. 

• Security measures: Covering data protection, incident reporting, supply chain security, and business continuity and disaster recovery requirements. 

• Information sharing: Focusing on facilitating cooperation and information sharing between organizations and with competent authorities.

Within the risk management and security measure areas, NIS2 includes specific secure software lifecycle requirements and puts a much greater emphasis on building and using quality software.

For vulnerability management, developers and application security teams have new requirements around secure development methodologies, regular risk assessments, and establishing processes for handling and disclosing vulnerabilities like timely CVE reporting, patching, and remediation. All of these new requirements are designed to emphasize secure-by-design development.

NIS2 adds new guardrails around the software supply chain, extending vulnerability management expectations to third-party tooling and adding risk assessment requirements. Organizations must identify and assess software supply chain risks like vulnerabilities in third-party software components, and are encouraged to utilize SBOMs to provide transparency into the composition of software. 

This means engineering and security teams will need to partner closely to evaluate the security postures of third-party providers, enforce contractual agreements for vulnerability disclosure, and conduct thorough supply chain audits.

For global organizations trying to meet a variety of cybersecurity standards, it’s not uncommon to identify the most rigid and build to that highest degree of compliance. As organizations adapt to NIS2, NIST 800-53 is a helpful standard that may already be part of an organization’s compliance approach. The standard can serve as a fallback guidepost for some of the requirements within NIS2, such as adopting FIPS cryptographic modules to meet NIS2’s cryptography requirements or looking to STIGs to address other cybersecurity requirements.

What are the penalties for failing to comply?

Penalties are levied at the member state level so mileage may vary a bit, but the directive lays out harsh ramifications for non-compliance, including significant financial and reputational consequences levied at the organizational level, as well as at the individual level for management.

For “Essential Entities,” fines can be up to €10 million OR 2% of their annual global revenue, whichever is higher. For “Important Entities” the fines are lower, but still significant at €7 million or 1.4% of their annual global revenue, whichever is higher.

For an entity’s management team non-compliance could amount to temporary bans from holding management positions, suspensions, and public disclosure.

These fines and penalties serve as a significant deterrent themselves, but they only capture a percentage of the impact of failing to meet the directive. As NIS2 becomes the law of the land, more and more organizations are likely to expect their own vendors and partners to illustrate strong cybersecurity posture and practices in accordance with the directive.

How Chainguard can help

While many organizations need to comply with NIS2 to operate and maintain customer trust, their engineering teams shouldn’t have to spend resources and time retroactively patching vulnerabilities and creating proof of origin artifacts for open source tooling — their time is better spent building new products and features that accelerate growth and revenue.

Chainguard provides the building blocks for a secure open source software supply chain, abstracting away much of the vulnerability assessment and management for security and developers, and providing attestations and provenance for software out of the box.

Some of the ways Chainguard can drive value for organizations who need to comply with NIS2:

• Eliminate Vulnerabilities: Leverage minimal, zero-CVE container images designed for rapidly consuming security patches and software updates to minimize CVE patching workloads.

• Create a Secure Foundation for Open Source Software: Reduce risk through supply chain control, including full build-time SBOMs and cryptographic attestations. Developers can then safely and securely adopt open source software with clear proof of origin artifacts. 

• Reduce Cost of Engineering Toil: By adopting zero-CVE container images with clear attestation, organizations can reduce unplanned work associated with fixing vulnerabilities and demonstrating compliance while increasing productivity through repeatable processes. 

Beyond meeting compliance challenges, we believe every organization wants to build secure software for their customers and users and we can provide the foundation.

Learn more about Chainguard Images or speak to an expert today about your compliance challenges.