control
secure development
Building security into software during design, coding, testing and release, and checking what you buy. NIS2 asks for it, the CRA sets requirements for products, and the AI Act does for high-risk AI systems.
- what it protects
- the software you ship and the software you buy, from flaws built in or bought in
- who owns it
- head of engineering
- start with
- one product, one release process, one place where the result is kept
what it is
Secure development means that security is part of how software is designed, written, tested and released. It covers software you build, software you commission and, for NIS2, what you buy.
NIS2 lists it as security in acquisition, development and maintenance and leaves the method to you. The CRA is more specific for makers of products: it sets security requirements for products with digital elements and a duty to build to them. The AI Act sets a cybersecurity requirement for high-risk AI systems. If you make no software for others, the question is mostly about bought software and your internal tools.
Start with one product and one process: who approves a release, which checks run before it and where the result is kept. Then add the list of components, because every later flaw announcement begins with the question of which of your products contains it.
basis NIS2 Art. 21(2)(e); CRA Annex I part I. The process and the order are practice.
how a release gets checked
- 1design reviewrequirements and risks are looked at before code is written
- 2build checksautomated checks run on every change
- 3release approvala named person signs off, or overrides with a reason
- 4release recordthe checks, the approver and the component list are stored
- 5after releasea new flaw announcement is answered from the record
what the build checks cover
- your own codeflaws and mistakes in what the team wrote
- libraries you pull inknown flaws in code written elsewhere
- container imageswhat sits underneath the application
- secretskeys and passwords left in a repository
basis working practice. No legal text sets this.
an example
Picture a company of 120 people that ships one product to a few hundred customers.
Security testing happens in the last week before a release. Anyone can push past a failing check without leaving a trace. Nobody knows which libraries are in last year's version, so when a flaw is announced the first day goes on finding out.
Checks run in the build and in design review. A release needs a named approver, an override has a reason on record and each release stores its list of components. When a flaw is announced the team answers which products contain it from that list.
An illustration. It is not a real case.
what it has to do for each rule
| rule | where | what the text asks | what the control has to do |
|---|---|---|---|
| NIS2 | NIS2 Art. 21(2)(e) | Security in acquisition, development and maintenance of network and information systems. | Write down how software is built or bought, who approves a release and what is checked before it goes live. |
| CRA | CRA Art. 13(1) | Manufacturers: a product designed, developed and produced to meet the security requirements of annex I part I. | If you sell software or connected products, build the requirements into design and test against them before release. |
| CRA | CRA Annex I part I | No known exploitable vulnerabilities at release, secure defaults, access control, protection of data, limited attack surface and logging. | Turn the list into release checks that someone signs off. |
| AI Act | AI Act Art. 15 | High-risk AI systems: an appropriate level of accuracy, robustness and cybersecurity. | Test the system against attacks on its data and its model, and keep the results with the release record. |
basis NIS2 Art. 21(2)(e); CRA Art. 13(1); CRA Annex I part I; AI Act Art. 15. What the control has to do is practice.
what to look for when you choose
- Does it fit how your team already works: the code host, the build pipeline and the ticket system?
- Does it check your own code, the libraries you pull in and the container images, and does it flag a secret left in a repository?
- Can a release be blocked when a serious finding is open, and can someone with authority override that, with a reason on record?
- Does it keep a record of what went into each release, so you can answer which products contain a flaw once it is announced?
- Can a developer see the finding and the fix advice inside the tool they already use?
- How does it handle software you buy or commission: can you ask the supplier for the same proof?
- Who approves the exceptions, and where is the list kept?
- Does it separate test and production data and credentials?
basis working practice. No legal text sets this.
three levels, from first step to strong
Each level adds something visible. Stop where the risk you accepted allows.
- start
Pick one product and write down who approves a release, what is checked before it and where the result is kept.
- solid
Run the checks in the build, record every override with a reason and an owner and store the list of components for each release.
- strong
Block a release on a serious open finding, ask suppliers of bought software for the same proof and review the exceptions list every quarter.
basis working practice. No legal text sets this.
where it goes wrong
checks at the end only
Security testing in the last week before release finds problems that cost the most to fix. Put the checks in the build and in design review.
third-party code is nobody's job
Most of what ships was written elsewhere. Someone has to know which libraries are in each release and watch for flaws in them.
a gate everyone can skip
A check that can be bypassed without a record is advice. Keep overrides rare, owned and logged.
bought software gets no questions
Acquisition is part of the same article of NIS2. Ask suppliers how they build and patch, and record the answer.
basis working practice. No legal text sets this.
the proof it leaves
| what you can show | who owns it | refresh |
|---|---|---|
| secure development procedure with named approvers | head of engineering | yearly |
| release records showing the checks that ran and who approved | head of engineering | per release |
| list of components in each shipped product | head of engineering | per release |
| exceptions with reasons, owners and end dates | head of engineering | quarterly |
basis practice. The rhythms are your choice.
check it yourself
your next step
Pick the product with the most customers and write down who approves its next release and what is checked first.