NIS2 DevSecOps: Your CI/CD Pipeline Is In Scope, Not Just Your Code

Most NIS2 DevSecOps advice stops in the same place: wire a SAST scanner into the build, keep the report, file it as Article 21(2)(e) evidence. That covers maybe a third of what the regulation actually reaches — and it is the third auditors find easiest to satisfy.

The part that gets missed is structural. Your build system is a network and information system that your organisation uses for its operations. It holds credentials with production reach, it runs on identities nobody has ever reviewed, and in most organisations it can deploy to production faster than any human administrator. Under Commission Implementing Regulation (EU) 2024/2690, that pulls it into at least four separate Annex titles, only one of which is the secure-development title everyone quotes.

This guide maps the pipeline itself — runners, service accounts, secrets, registries — to the specific provisions that govern it, and to the evidence each one demands. It assumes you already know what a secure development lifecycle is; if you need the control-by-control walkthrough of Section 6.2 first, start with our secure SDLC requirements guide and come back.

Does This Apply to You? Two Regimes, One Set of Controls

Whether CIR 2024/2690 binds you legally depends entirely on what your organisation is, not on how much software it writes.

Your entity type	Status of CIR 2024/2690	What governs your pipeline
DNS providers, TLD registries, cloud providers, data centre providers, CDNs, MSPs, MSSPs, online marketplaces, search engines, social platforms, trust service providers	Legally binding. Article 1 names exactly these eleven categories as “the relevant entities” [4]	The Annex points cited throughout this guide, as written
Every other essential or important entity — energy, health, transport, water, manufacturing, public administration, banking	Not binding. Your obligation is Article 21(2)(e) of the Directive itself, plus your Member State’s transposition	Article 21(2), read with the Annex as the best available interpretive reference for what “appropriate and proportionate” looks like

The practical distinction matters less than it sounds. Article 21(1) sets a single test for everyone: measures must be appropriate to the risks posed to “network and information systems which those entities use for their operations or for the provision of their services,” with proportionality judged on “the degree of the entity’s exposure to risks, the entity’s size and the likelihood of occurrence of incidents” [1][2]. A hospital group that maintains its own patient-portal codebase has real exposure through its build chain whether or not the Implementing Regulation binds it. The Annex is simply the only place the EU has written down what a supervisor expects to see.

One asymmetry worth naming: if you buy your software rather than build it, Article 21(3) still reaches the same subject from the other side. Entities must take into account each direct supplier’s “overall quality of products and cybersecurity practices … including their secure development procedures” [1][2]. Your vendor’s pipeline hygiene is your Article 21(2)(d) problem — see our supply chain security guide.

What Section 6.2 Actually Says — and the Three Words Everyone Skips

Annex point 6.2.1 requires entities to lay down rules for secure development before developing, covering “all development phases, including specification, design, development, implementation and testing,” and to apply them whether development happens in-house or is outsourced [4]. Point 6.2.2 then lists six things those rules must do.

Five of the six are about the software: security-requirements analysis at specification and design; secure engineering and coding principles “such as promoting cybersecurity-by-design, zero-trust architectures”; security testing processes in the lifecycle; selection and protection of test data; and sanitisation or anonymisation of that data [4]. Those are the five every competing guide covers.

Point 6.2.2(c) is the outlier: entities shall “lay down security requirements regarding development environments” [4]. Not requirements for the product. Requirements for the place the product is built. That single clause is why the rest of this guide exists, and it is the one line in Section 6.2 that most teams have no artefact for at all.

ENISA’s implementation guidance sharpens it. Under the same point, its evidence list includes “different network segments, servers, databases, existence of accounts used for this purpose and change management records” demonstrating separation of development, testing and production environments [5]. That is an infrastructure question with an infrastructure answer, and it is assessed independently of whether your code is clean.

Your Pipeline Is an Identity Population

For platform and DevOps leads: this is the section that will generate the most work, and almost none of it is code.

Annex point 11.1.2 requires access control policies to address three things, and (b) is the one that catches build systems: policies shall “address access by network and information system processes” [4]. ENISA’s guidance spells out what a process means here — access rules map to “human users or network and information system processes (e.g. a machine, device or a service)” [5]. Every runner, every bot account, every deploy key, every OIDC federation to your cloud account is a non-human identity your access control policy is required to cover.

Point 11.5 then applies a full lifecycle to them. Entities “shall manage the full life cycle of identities of network and information systems and their users,” must set up unique identities, must “ensure oversight of identities of network and information systems,” and must apply logging to identity management [4]. ENISA’s guidance under 11.5.1 gives the field list, and it is unusually concrete: the identity inventory “should also include all service identities and have these identity records as a minimum including department owner, review date, purpose and the level of privileges for each service identity” [5].

Read that against a typical GitHub or GitLab organisation. Personal access tokens created by an engineer who left eighteen months ago. A deploy key shared across four repositories because rotating it once broke a release. A runner with a cloud role scoped to whatever the first working IAM policy happened to grant. Point 11.5.3 addresses the shared case directly: identities assigned to multiple persons are permitted only “where they are necessary for business or operational reasons and are subject to an explicit approval process and documentation,” and must be carried into the risk management framework [4]. Point 11.5.4 requires regular review and deactivation “without delay” where an identity is no longer needed; ENISA suggests quarterly as a minimum, annually for micro-sized entities [4][5].

The gap analysis here is usually brutal and usually fast. Export your service identities, try to fill in owner, purpose, review date and privilege level for each, and count the blanks. That count is your finding, and it is the same exercise our NIS2 access control guide describes for human accounts.

Secret Scanning Is an Access-Control Control, Not a Vulnerability Control

Secret scanning gets filed under vulnerability management in most compliance write-ups. The regulation puts it somewhere else, and the difference changes what you owe when a scanner fires.

The Annex title covering access control is point 11, expressly attributed to “Article 21(2), points (i) and (j), of Directive (EU) 2022/2555” [4]. As throughout this guide, the Annex binds the eleven categories in the scope table above; for everyone else it is the clearest available reading of what point (i) expects. Within it, point 11.6.2(b) requires entities to “control the allocation to users and management of secret authentication information by a process that ensures the confidentiality of the information” [4]. A credential committed to a repository is, by definition, a failure of that process — the confidentiality the provision requires has not been maintained.

Point 11.6.2(c) then supplies the consequence, and it is an unqualified obligation rather than a recommendation: entities shall “require the change of authentication credentials initially, at predefined intervals and upon suspicion that the credentials were compromised” [4]. Suspicion, not confirmation. A secret found in git history is suspicion. The rotation is not optional remediation you schedule behind other work; it is the control operating as written.

Two practical consequences follow that a vulnerability-management framing would miss. First, deleting the commit does not discharge the obligation, because the trigger was the suspicion of compromise, not the persistence of the file. Second, the detection tooling and the rotation procedure are evidence for a different Annex point than your SAST reports — which means an auditor working through point 11.6 will not accept a vulnerability register as the answer. Point 11.6.2(f) adds a related requirement worth checking your pipeline against: separate credentials for privileged or administrative access [4].

Your Runner Is Probably an Administration System

A CI runner that can deploy to production holds, in practice, the rights of a system administrator. The Annex has provisions for that, and they are stricter than most pipeline architectures.

Point 11.3.2 requires policies for privileged and system administration accounts that “set up specific accounts to be used for system administration operations exclusively” and provide that “system administration accounts are only used to connect to system administration systems” [4]. Point 11.4.2 goes further, requiring entities to “only use system administration systems for system administration purposes, and not for any other operations,” to separate them logically from other application software, and to protect access through authentication and encryption [4]. Point 6.7.2(e), in the network security title, states the same principle from another direction: do “not use systems used for administration of the security policy implementation for other purposes” [4].

The shared-runner pattern collides with all three. A general-purpose runner pool that builds untrusted pull-request branches in the morning and deploys production in the afternoon is a system with administrative reach being used for non-administrative operations, on infrastructure that also executes code contributed by people outside the entity. Whether that is defensible is a risk-assessment question under point 2.1, not a matter of preference — but it has to be a documented decision. Segregating deployment runners from build runners is the obvious remedy; if you decline it, the reasoning is the artefact you will be asked for.

Scanners: What Is Binding and What Is Only Guidance

For compliance officers: this distinction determines what you can safely write in a policy.

The binding text on testing is Annex point 6.5.2, and it names no tools at all. Entities shall establish the need, scope, frequency and type of tests from the point 2.1 risk assessment; carry them out “according to a documented test methodology”; document “the type, scope, time and results of the tests, including assessment of criticality and mitigating actions for each finding”; and “apply mitigating actions in case of critical findings” [4].

SAST and DAST appear in the Implementing Regulation exactly once, in Recital 15, which states that security tests “may include automated or manual tests, penetration tests, vulnerability scanning, static and dynamic application security tests, configuration tests or security audits” [4]. Recitals are interpretive and non-binding. They indicate intent; they do not create obligations. So the accurate statement is that SAST and DAST are recognised methods you may select and must then document — not that the regulation requires them. Any policy asserting “NIS2 requires SAST” is overstating the source. The same care applies to penetration testing, which our penetration testing guide covers in more depth.

Worth knowing before you draft anything: the words “pipeline”, “DevSecOps” and “continuous integration” appear zero times in the entire Implementing Regulation — a count you can reproduce against the primary text [4]. Every mapping in this guide, including ours, is interpretation of technology-neutral drafting. ENISA’s guidance is where CI/CD is named directly, and it is the single most useful sentence in the EU stack for this topic: “Make sure that network and information systems undergo continuous testing, particularly in environments utilizing continuous integration / continuous deployment practices” [5]. That is a recommendation rather than law, but it is the clearest signal available that supervisors expect pipeline-integrated testing where pipelines exist. ENISA’s evidence list under 6.2.2 is equally quotable — “version control, change management logs, code reviews” sit alongside audit and testing reports [5].

For the dependency layer specifically, ENISA’s tips under 6.2 ask that “defined methods and tooling for performing analysis and tracking of usage of third party libraries should be in place” [5]. That is the closest the EU guidance comes to mandating dependency scanning, and it pairs naturally with the inventory question covered in our SBOM requirements guide. Where you need a named methodology for the artefact and provenance side, NIST SP 800-204D sets out strategies for integrating software supply chain security across the build, test, package and deploy stages [7] — a useful reference, though not an EU legal source.

What a National Authority Expects From the Development Environment

Germany’s BSI, a national competent authority under NIS2, publishes a module on software development in its IT-Grundschutz compendium that reads as the missing operational detail behind Annex 6.2.2(c). It applies to German entities using IT-Grundschutz, not to the EU generally — but it is the most concrete statement any authority has published on what securing a development environment means.

BSI CON.8 requirement	Level	What it asks for
CON.8.A10 — Source code version control	Basic (MUST)	Source code must be held in suitable version control, and the institution must regulate access to that version control system
CON.8.A6 — External libraries from trustworthy sources	Basic (MUST)	External libraries must come from trustworthy sources and their integrity must be assured before use
CON.8.A20 — Review of external components	Basic (MUST)	External components whose security is not assured by established peer review must be checked for vulnerabilities
CON.8.A17 — Trustworthy development tools	High (SHOULD)	Only tools with demonstrated security properties should be used; security requirements should be placed on the tool vendors
CON.8.A18 — Security audits of the environment	High (SHOULD)	Regular security audits of both the development environment and the test environment
CON.8.A19 — Integrity checking of the environment	High (SHOULD)	Regular state-of-the-art cryptographic integrity checks of the development environment, with the checksum files and the checking program themselves protected against manipulation

CON.8.A19 is the one worth sitting with. It anticipates an attacker who compromises the build environment and then tampers with the verification that would have caught it — which is the shape of several of the major software supply chain compromises of recent years. It is also a control that rarely appears in pipeline security programmes, and the second half — protecting the checksum files and the checking program themselves — is rarer still. If you are looking for a control that distinguishes a mature pipeline programme from a scanner deployment, that is it.

When a Pipeline Compromise Becomes Reportable

Article 23(3) sets the significance test for all entities: an incident is significant if it “has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned,” or if it “has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage” [3].

For the eleven categories the Implementing Regulation binds, Article 3(1)(e) adds a criterion that lands directly on build systems: an incident is significant where “a successful, suspectedly malicious and unauthorised access to network and information systems occurred, which is capable of causing severe operational disruption” [4]. Note what is absent — there is no requirement that the access caused disruption, or that anything was deployed, or that a financial threshold was crossed. Access plus capability is enough. An attacker who obtains a runner token with production deployment rights has, on its face, achieved access capable of causing severe operational disruption.

One boundary in the other direction: Article 3(2) excludes “scheduled interruptions of service and planned consequences of scheduled maintenance operations carried out by or on behalf of the relevant entities” from being significant incidents [4]. A planned deployment window that goes as planned is not an incident. A cutover that fails and forces a rollback is not a planned consequence, and the exclusion does not reach it. If you are unsure where a given event lands, our significant incident guide works through the threshold in detail, and the 24-hour early warning guide covers what actually has to be filed.

The Evidence Pack: What to Produce, and Who Owns It

Supervisors do not audit pipelines by reading YAML. They ask for documents. This table maps each obligation discussed above to the artefact that evidences it and the role that realistically produces it.

Provision	Evidence artefact	Owner	Effort
Annex 6.2.1 / 6.2.4	Documented secure development rules covering all phases, with a review schedule and version history	Head of Engineering + CISO	Medium
Annex 6.2.2(c)	Security requirements document for development, test and production environments, plus proof of separation (network segments, distinct accounts, change records)	Platform / DevOps lead	High
Annex 6.5.2	Documented test methodology; per-test records of type, scope, time and results with criticality assessment and mitigating actions	AppSec / QA	Medium
Annex 11.1.2(b)	Access control policy with an explicit clause covering non-human identities and system processes	Compliance Officer	Low
Annex 11.5.1 / 11.5.4	Service identity inventory with owner, purpose, review date and privilege level per identity; dated review records; deactivation log	Platform / DevOps lead + IAM	High
Annex 11.5.3	Approval record and documented justification for every shared identity, referenced in the risk register	CISO	Low
Annex 11.6.2(b)/(c)	Secrets management procedure; secret-scanning coverage report; rotation records showing rotation on suspicion of compromise	Platform / DevOps lead	Medium
Annex 11.3.2 / 11.4.2	Runner inventory showing which runners hold production rights, with segregation design or a documented risk acceptance	Platform / DevOps lead + CISO	Medium
Article 23(3) / CIR Art. 3(1)(e)	Incident classification procedure that names pipeline credential compromise as a scenario to assess	Compliance Officer	Low

For the board: the pattern in that table is worth noticing. The two High-effort rows are both inventories, not engineering projects. The expensive part of pipeline compliance is not buying tools — it is establishing who owns each machine identity and each build system, which is organisational work that no vendor can sell you.

Frequently Asked Questions

Does NIS2 require us to run SAST or DAST in our pipeline?

No provision names either tool. The binding requirement is Annex point 6.5.2: establish the need, scope, frequency and type of security tests from your risk assessment, run them to a documented methodology, and record results with criticality and mitigating actions [4]. SAST and DAST appear only in Recital 15 as examples of methods you may select, and recitals do not create obligations [4]. In practice most entities that build software will conclude from their own risk assessment that automated code analysis is appropriate — but the obligation is to reason and document, not to deploy a specific product.

We use GitHub Actions rather than self-hosted runners. Does that move the obligation to GitHub?

It does not. Article 21(1) attaches obligations to the systems the entity uses for its operations, and Recital 83 of the Directive indicates the same measures apply whether systems are maintained internally or their maintenance is outsourced [8] — though as a recital it signals intent rather than creating the obligation itself. What changes is the mechanism: your provider becomes a direct supplier, so Article 21(2)(d) and Article 21(3) apply — including the express requirement to take into account suppliers’ “secure development procedures” [1][2]. You still owe the access control, identity and secrets obligations for the accounts and tokens you configure inside that service.

Is a leaked API key in a repository automatically a reportable incident?

Not automatically. Rotation is required as soon as compromise is suspected under Annex 11.6.2(c) [4], but reportability is a separate test. For entities the Implementing Regulation binds, ask whether Article 3(1)(e) is met — was there successful, suspectedly malicious and unauthorised access capable of causing severe operational disruption [4]? A key exposed with no evidence of use is typically not. A key demonstrably used by a third party to reach production usually is. For all other entities, apply the Article 23(3) test [3]. Document the reasoning either way; the assessment itself is the artefact.

How does this guide differ from the other secure development articles on this site?

Our secure SDLC requirements and secure development guides work through Annex Section 6 control by control — coding standards, code review, dependency scanning, environment separation. This guide covers what those two do not: the obligations that attach to the pipeline as infrastructure, under the access control, identity and administration-system titles rather than the development title.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Directive (EU) 2022/2555, Article 21 — Cybersecurity risk-management measures
2. Directive (EU) 2022/2555, Article 21 — NIS2 Resources (independent verification of the Article 21 text)
3. Directive (EU) 2022/2555, Article 23 — Reporting obligations
4. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex, Official Journal
5. Technical Implementation Guidance on Cybersecurity Risk Management Measures, version 1.0 (June 2025) — ENISA
6. “CON.8 Software-Entwicklung, IT-Grundschutz-Kompendium Edition 2023” — Bundesamt fuer Sicherheit in der Informationstechnik (bsi.bund.de)
7. NIST SP 800-204D: Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines — NIST
8. Directive (EU) 2022/2555, Recitals 81 to 90 (Recital 83 — outsourced maintenance)