NIS2 Article 21: How a Private Package Repository Helps You Comply

The NIS2 Directive (Directive 2022/2555/EU) entered into force in January 2023 and required member states to transpose it by October 2024. For security teams at essential and important entities, one of the most concrete obligations is Article 21(2)(d): “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.”

Software packages are your most direct supply chain. Every apt-get install or yum install pulls an artifact from a third-party server and installs it with root privileges on your infrastructure. If that artifact is tampered with — or carries a known critical CVE — your network is exposed before your SIEM fires a single alert.

What Article 21 Actually Requires

Article 21 does not prescribe specific tools, but the ENISA guidelines and national implementations (notably the German IT-Sicherheitsgesetz 2.0 alignment) point to four concrete controls for software supply chains:

1. Provenance verification — you must be able to prove the origin of every software component
2. Vulnerability management — known vulnerabilities must be tracked and mitigated within defined SLAs
3. Change management — every change to production software must be audited
4. Incident-readiness — you must be able to reconstruct what was deployed, where, and when

A properly configured private repository addresses all four.

GPG Signing as Provenance Control

Every package entering your repository should be GPG-signed. The signature chain looks like this:

Upstream vendor GPG key  →  signs the .deb/.rpm
Your repository signing key  →  signs the Release/repomd.xml file
apt/yum client  →  verifies both before installing

RepoD generates and manages a repository GPG key stored in an isolated keyring (/repos/gnupg/). The Release file (APT) and repomd.xml (RPM) are signed on every metadata update. Clients configured with your public key will reject any package that wasn’t signed by your repository — making man-in-the-middle or repository substitution attacks fail silently before installation.

For NIS2 audit purposes, you can export the signing key fingerprint and include it in your supply chain attestation documentation.

CVE Gating Before Promotion

The most common supply chain risk is not tampering — it is known vulnerabilities in upstream packages. A package with CVE-2024-XXXX rated CRITICAL (CVSS 9.8) might be available on the upstream mirror today. Without a gating mechanism, your automated patching jobs will install it across your fleet in the next maintenance window.

RepoD’s validation pipeline runs Grype against every package before it lands in the distribution tree. The CVE policy in settings.json maps severity levels to actions:

{
  "cve_policy": {
    "critical": "block",
    "high":     "review",
    "medium":   "warn",
    "low":      "allow"
  }
}

With "critical": "block", a package carrying a CRITICAL CVE is quarantined in staging/quarantine/ and never reaches dists/. Your security team receives an alert and must make an explicit decision. This decision — approve or reject, with timestamp and username — is recorded in the immutable audit log.

For NIS2 Article 21(2)(e) (basic cyber hygiene), this policy enforces a zero-critical gate by default while giving your team a documented override path for false positives.

EPSS and KEV Enrichment

Raw CVSS scores are a poor proxy for actual exploitation risk. RepoD enriches every detected CVE with:

• EPSS (Exploit Prediction Scoring System) from FIRST.org — the probability that a CVE will be exploited in the wild in the next 30 days
• CISA KEV (Known Exploited Vulnerabilities catalog) — confirmed in-the-wild exploitation

A CVE with CVSS 7.5 but EPSS 0.89 and KEV flag is far more urgent than a CVSS 9.8 with EPSS 0.01. This enrichment lets you prioritize remediation in a defensible, evidence-based way — exactly what NIS2 incident response obligations require.

Immutable Audit Trail

NIS2 requires entities to maintain records sufficient to support post-incident forensics and regulatory reporting. RepoD appends every significant event to a daily JSONL audit log:

{"ts":"2024-11-15T09:12:33Z","event":"package_uploaded","user":"alice","pkg":"nginx_1.26.2-1_amd64.deb","sha256":"a3f9..."}
{"ts":"2024-11-15T09:12:41Z","event":"cve_blocked","pkg":"nginx_1.26.2-1_amd64.deb","cve":"CVE-2024-7347","severity":"CRITICAL"}
{"ts":"2024-11-15T09:18:02Z","event":"cve_override","user":"bob","role":"maintainer","pkg":"nginx_1.26.2-1_amd64.deb","decision":"reject"}

These files are append-only (never modified after writing), rotated daily, and included in scheduled backups. They provide a complete chain of custody for every package in your infrastructure.

Fleet Inventory for Vulnerability Impact Assessment

Knowing a CVE exists in a package is not enough — you need to know which machines are running that package version. RepoD’s SSH inventory scanner connects to your fleet and collects installed package lists using dpkg-query (Debian/Ubuntu) or rpm -qa (RHEL/Rocky/Alma). Combined with the CVE database, it produces a TruRisk score per host showing exploitability in your actual environment.

This directly supports NIS2 Article 23 incident reporting: when a vulnerability is exploited, you can produce a list of affected hosts within minutes rather than days.

Getting Started

The fastest path to compliance is to:

1. Deploy RepoD (single docker compose up -d)
2. Mirror your current package sources through the validation pipeline
3. Set CVE policy to "critical": "block", "high": "review"
4. Distribute the repository GPG public key to your fleet
5. Point your apt/yum sources at the RepoD distribution URL

Your package supply chain is now audited, signed, and CVE-gated — with a complete paper trail for your NIS2 auditor.

---

Questions about NIS2 compliance with RepoD? Contact our team.