Secure development under NIS2, ISO 27001 and the CRA. What is required, what a continuous scan proves.
Four sets of rules speak about security in your own code. None of them prescribes a scanner product. This page shows where each requirement sits, says openly where no explicit obligation exists, and sets out which evidence a scan on every commit delivers for it.
Anyone asked in an audit how vulnerabilities in their own code are handled needs two things: the right place in the rulebook and a dated record. This page provides the first. The second comes out of the continuous scan, with finding, action and date.
Where secure development actually sits.
Two are lists of obligations, one applies to manufacturers only, one is not a law at all. The difference decides what you have to produce in an audit.
Security in acquisition, development and maintenance
The directive's list of measures has its own letter for handling systems across their lifecycle: acquiring, developing, maintaining, handling and disclosing vulnerabilities. Germany transposed it as Section 30(2) no. 5 BSIG. Anyone running their own code lives under that letter with every flaw in it. How they find the flaws is left open by the legislator.
Secure development lifecycle
Since the 2022 revision, an auditor working through Annex A stops at four separate points for software you write yourselves. How the build process is organised (A.8.25). Which security requirements an application was specified against (A.8.26). Whether the code was written to secure coding rules (A.8.28). And, cutting across all of that, whether known vulnerabilities are tracked and fixed (A.8.8). Each stop wants its own evidence.
Obligations for products with digital elements
This one is about the seller, not the user. Whoever brings software or a connected device to market carries its vulnerabilities for as long as the product is in use, and that is a manufacturer duty, not an operator duty. Three dates matter: 10 December 2024 (in force), 11 September 2026 (reporting actively exploited vulnerabilities became mandatory) and 11 December 2027 (everything else). If your company only runs software bought from others, this text is not addressed to you.
The technical reference framework
The Top 10 is a ranking, not a rule: the ten risk classes that most often lead to incidents in applications, re-sorted every few years. In the 2025 edition broken access control leads, and the software supply chain has moved into the top three for the first time. We use the list as the order in which findings are assessed. Anyone selling it as a certificate has not read it.
For the record, before anyone reads a purchase obligation into this: none of the four texts prescribes a scanner. What is required is an outcome, namely knowing, assessing and fixing vulnerabilities, not a product. And the CRA applies to manufacturers only. What a continuous scan delivers is documentation of that outcome with a date. We claim nothing more.
Which record fits which clause.
An audit rarely asks about the tool. It asks whether a requirement is implemented and what you show to prove it. This is how the mapping looks.
- Vulnerability management
Section 30 BSIG, ISO A.8.8
Every dependency is checked against known vulnerabilities. When a library is updated, the finding, the action and the date are in the documentation.
- Secure coding
ISO A.8.28
Unsafe patterns such as unvalidated input, dangerous system calls and missing access checks are detected on every commit, not once a year at audit time.
- Handling of credentials
Section 30 BSIG, ISO A.8.28
Hardcoded passwords, keys and tokens are found, including in the repository history, and critical secrets are rotated rather than merely reported.
- Development lifecycle
ISO A.8.25, A.8.26
Every change is assessed in the context of the codebase before the code moves on. That is the evidence that security sits in the process and not only in the annual report.
Three things a scan does not do. And that we do not claim.
It does not replace a penetration test.
The scan works in one place: in the code, on every change, against known patterns. A penetration test starts from the outside and tries to overcome the running system as a whole, including network, configuration and people. Having one does not give you the other. What a test has to deliver, and what happens after the report, is on our penetration testing page.
It does not find business logic errors.
Whether a clerk may see another department's invoices is not written in any pattern but in the business rules. No automated analysis catches such errors in authorisation logic, and evidence that pretended otherwise would be false. We do not write it.
It is not a certificate.
The scan produces records for individual controls. A management system, a certification or the effectiveness assessment under Section 30 BSIG remain separate steps that it supports but does not take off your hands.
From connection to a dated file.
Connection
Repositories are connected and the existing code is scanned once for secrets, vulnerable dependencies and unsafe patterns.
First findings
A clear report: which findings are real and critical, which can wait, and what needs to happen first.
Cleanup
Critical secrets rotated, vulnerable libraries updated, dangerous patterns defused. Every action dated.
Evidencing
From now on, on every commit. New critical findings are handled straight away, and the documentation grows with the work instead of being assembled before the audit.
Questions on code security and compliance
Is a code scanner mandatory under NIS2?
No. What is prescribed is the outcome: being able to know, handle and disclose vulnerabilities in your own systems, Section 30 BSIG. How a company achieves that is its own choice. The reason we still recommend the scan is the evidence: it leaves a date and an action behind every finding, and that is exactly what a supervisory authority asks for.
Does the Cyber Resilience Act apply to our company?
The question is whether you sell something with software inside: a machine with a controller, a device with an app, a software product. Then you are a manufacturer in the sense of the regulation, and the deadlines are running, since 11 September 2026 for reporting exploited vulnerabilities, from 11 December 2027 for the rest. If you only use software yourselves, the CRA does not apply to you, though NIS2 possibly does.
Is the scan sufficient as evidence for ISO 27001?
It substantiates controls A.8.25, A.8.26 and A.8.28 on secure development and A.8.8 on vulnerability management with dated findings and actions. A management system and the certification itself remain separate steps that the scan supports but does not replace.
What exactly is in the evidence?
For every finding, the assessment by real risk, the action taken and the date: secret rotated, library updated, pattern defused. False positives are removed before they reach the file.
Does this replace a penetration test?
No. The two checks answer different questions: the scan, whether known classes of flaw sit in the code; the test, whether an attacker gets through from the outside. An auditor who wants to see a penetration test will not accept a scan report as a substitute, and vice versa.
Which evidence are you missing today for Section 30 BSIG or A.8.28?
Free code analysis, a clear result, no obligation.