CRA Sessions: Technical Security Requirements

Why is broken access control still the #1 risk in the OWASP Top 10? And why does almost every application have at least one of these flaws? In episode 2 of our OWASP Top 10 series, Codific’s Dag Flachet and one of OWASP Top 10 project leads Brian Glas break down Broken Access Control (A01:2025), the single most common vulnerability category in the Top 10.In this episode:What broken access control really meansWhy SSRF got merged into this category in 2025Real examples: path traversal, open redirects, data leaksWhat IDOR is, and its 20-year history in the Top 10Why static analysis misses it, and what catches it insteadThe #1 misconception: “the system just knows”Part 2 of 12. Catch episode 1, our introduction to the OWASP Top 10, if you missed it.

What exactly is the OWASP Top 10? In episode 1 of our OWASP Top 10 series, Codific's Dag Flachet talks with Brian Glas, OWASP Top 10 project lead and VP of Consulting Services at Codific, about what the list really is, how it's built, and what it's meant to do for your application security program.In this episode:What OWASP is, and where the Top 10 sits among its other projectsHow the Top 10 is actually selected: incidence rate, impact scoring, and the community surveyWhy it's a ranked baseline, not a strict priority orderOWASP Top 10 vs. OWASP SAMMThe biggest misconceptions about the Top 10Why the same problems have shown up for over 20 yearsPart 1 of 12. Over the next ten episodes we go category by category through the OWASP Top 10:2025, closing with a wrap-up episode.Find out more about the Codific Trainings and Services on our website: https://codific.com/consultancy-services/

Vulnerability management is at the core of the Cyber Resilience Act (CRA). But what are the minimal expectations? Annex I, Part 2 lists 8 expectations manufacturers shall implement, yet they remain very abstract.Chapters:00:00 Introduction and a motivating example02:39 CRA: a brief recap08:11 Vulnerability management basics10:00 Revisiting the running example of a smart fridge10:38 Incident management18:25 The definition of an incident24:30 Defect management27:26 Security testing28:35 Patching and updating29:51 Secure deploy33:11 Recap of all required security activities under the CRAAbout this video:Today, the topic of vulnerability management typically makes one think of a SAST, DAST, IAST, SCA scanner. It makes us think of a triaging process and fixing the critical and high severity findings in the attempts to try to keep the risk low. However under the CRA vulnerability management is much broader. Fortunately, at least based on the OWASP SAMM latest benchmark, the industry is doing so much better on vulnerability management than on any other security related activities.Incident detection and response is the first major subtopic under vulnerability management. Especially in larger organizations most of the aspects of incident management are well under control. Amongst the key outstanding issues we typically face is the lack of communication between the product teams and the incident management teams as these are always siloed. Without a clear understanding of the business context the incident management can only focus on generic risks.Under the CRA the definition of an incident is interesting to understand. It differs starkly from the organizational perspective where a minor incident affecting a single user may be overlooked. CRA is all about the sensitivity of the data rather than the volume of the data.Defect management is about making sure that all findings are reported to a centralized defect tracking system, triaged and tackled within pre-defined time frames.Security testing is all about the tooling organizations are so excited about. However just pulling in a scanner is likely to make things worse. Teams must have a full grip on their scanners by tweaking the rulesets and how they tie to the build and deploy process.Patching and updating focuses on regularly patching OS and infrastructure components.Finally, secure deploy is actually a very complex topic as it needs to ensure the authenticity and integrity of the code moving from development to production. Code signing is one of the key controls, yet getting that aspect right is not as straightforward as it seems.All in all, you need a systematic approach to product security. Codific's SAMMY tool can help you out there. SAMMY can enable your gap assessment, improvement planning and demonstrating those improvements. SAMMY has an instrumental integration with JIRA so that your developers don't have to jump into a new tool. SAMMY also features an MCP server that allows your AI tools to generate all sorts of board reports based on your data in SAMMY.Links:👉 Use the SAMMY tool to manage your security posture: https://sammy.codific.com👉 Check the industry standard AppSec management model: https://owaspsamm.org

On September 11, 2026 the CRA reporting obligations come into effect. What exactly are you supposed to repot, to whom and how do you do it.Content from Complycra.eu full article here: https://complycra.eu/what-are-the-cra-obligations-starting-september-11-2026/To use SAMMY Free go to https://sammy.codific.com

This chapter summarizes the horizontal standards of CRA and is based on resources from complycra.eu. Voices and narrative is AI generated based on in depth resources. For full factual accuracy refer to complycra.eu

The Cyber Resilience Act makes it mandatory to take security into consideration from a product’s design until sunsetting. But what are these technical security requirements? Is this about yet another checkbox exercise we can "fake it until we make it" along with a bunch of documents we can now effortlessly generate?

Traditional GRC tools were built for corporate IT, not for modern software development. As regulations like the EU Cyber Resilience Act raise the bar for product-level security, a new discipline is emerging: Product Risk and Compliance (PRC).

Risk assessments are the starting point of your application security program and as it turns out your Cyber Resilience Act compliance strategy. If you think about it, it makes absolute sense. If there is no risk, you don't really need security. Unfortunately, that's not the world we are living in and creating a crystal clear understanding of the risk profile for each of your products is essential.Risk has two components to it. It has a more "businessy" component that is related to loss magnitude or impact. This is the component that needs to be dictated by the business.The second risk component is more technical, namely threat event frequency.The combination of the two factors is what we typically think of risk. However it is critical to stress that the first "business"-side of risk is much easier to come up with. It is also relatively limited. It is also the first one in terms of a sequence. This is also precisely what CRA suggests, you need to start with clearly defining the context of your product, its risk and risk acceptance criteria.The second factor, i.e., the actual threats, is virtually unlimited. Once again you need the business side of the story to come up with meaningful threats.In this second episode of our CRA series podcast we dive deep into the risk assessment and threat modeling concepts in the context of the upcoming EU Cyber Resilience Act.

Lara and I kick off our new series on the EU Cyber Resilience Act (CRA), where we'll go deep on what the regulation actually means for product security teams and how to translate it into concrete application security practice.In this first episode, we cover the foundations:What the CRA is and why it existsWhich products fall under its scope, and which don'tHow compliance requirements differ between product categories (default, important, and critical)The role of horizontal and vertical standards, and how they fit togetherWhat's at stake if you simply ignore the regulation — the penalties, market access consequences, and liability implicationsTo help you figure out where your product stands, we've also built a CRA screening tool that walks you through the key scoping questions and gives you a first read on your obligations.In the coming episodes, we'll move from the regulatory frame into the practical side: what "secure by design," vulnerability handling, SBOMs, and conformity assessments actually look like when you're shipping real products.👉 Try the CRA screening tool: https://sammy.codific.com/cra👉 Subscribe so you don't miss the next episodes.

AI is changing everything - including how attackers think. But is the security industry keeping up?This webinar, hosted jointly with Toreon, tackles one of the biggest questions in AppSec right now: as AI agents, LLMs, and prompt-driven development become the norm, what does application security even look like?📌 Follow us on LinkedIn: https://www.linkedin.com/company/9420309/🌐 Or visit our website: https://codific.com/🔔 Subscribe for more AppSec tutorials and security framework insights!