In many teams, the security review happens the week before launch. Someone finds a design problem, the release slips, and engineering learns that security is the team that says no. Next time, they involve security later, or not at all.

The pressure to fix this is no longer only internal. Since 11 September 2026, the EU Cyber Resilience Act requires manufacturers of products with digital elements sold in the EU to report actively exploited vulnerabilities and severe incidents: an early warning within 24 hours, a notification within 72 hours and a final report afterwards. The rest of the Act, including secure-by-design requirements, applies from 11 December 2027. If you sell software into the EU, you need to be able to show how security is part of how you build, not a gate at the end.

Why end-of-cycle reviews fail

A review at the end can only find problems when they’re most expensive to fix. Design flaws found a week before launch mean rework or a risk acceptance nobody is comfortable signing. And because reviewers see every change at once, they become the bottleneck for every release.

Move the conversation to the start

Most changes don’t need a security review. The trick is to identify the ones that do while they’re still a design. Add five questions to your design template or ticket:

  1. Does this change authentication, sessions or who can access what?
  2. Does it handle new kinds of sensitive data, or send data somewhere new?
  3. Does it accept new input from users, files, webhooks or third parties?
  4. Does it touch cryptography, secrets or payment flows?
  5. Does it change infrastructure permissions or network exposure?

Any “yes” means a short design conversation with someone who owns security, usually a 45-minute threat model. All “no” means the change follows the normal path, with automated checks.

Keep the code review light

  • Use code owners for sensitive paths. Authentication, authorization middleware, crypto helpers and infrastructure definitions get an extra reviewer automatically. Everything else doesn’t.
  • Automate the routine. Dependency scanning, secret scanning and a tuned static analysis ruleset run on every pull request, reporting only what the change introduced.
  • Set a response time. A security reviewer commits to responding within an agreed window. If reviews routinely wait days, add reviewers or narrow what needs review.

Ship with known risk, on purpose

Sometimes the right call is to release with an issue open. Make that a decision, not an accident. Record the risk, the reason, the owner and the date it will be fixed, and have the person who owns the product risk approve it. Revisit open exceptions every month.

Measure the right thingTrack how many security issues are found at design time compared with after release. If the first number is going up and the second down, the process is working, regardless of how many reviews you ran.

A checklist you can adopt

  • Five security questions in the design template.
  • A 45-minute threat model for any design with a “yes”.
  • Code owners on security-sensitive paths.
  • Diff-only automated checks on every pull request, blocking on a short list.
  • An agreed response time for security reviews.
  • A written exception process with owners and dates.
  • A documented route for receiving vulnerability reports, such as security.txt, and for reporting exploited vulnerabilities within the deadlines that apply to you.

Sources

  1. European Commission: Cyber Resilience Act (opens in a new tab)
  2. Skadden: Reporting FAQs and checklist as the EU’s Cyber Resilience Act comes into force (2026) (opens in a new tab)
  3. CISA: Secure by Design (opens in a new tab)
  4. RFC 9116: A file format to aid in security vulnerability disclosure (security.txt) (opens in a new tab)