Security Champions Live Sessions

The CRA turns product security from an internal quality goal into a condition for market access, enforced by market surveillance authorities, a reporting clock measured in hours and support obligations that outlast the sale. This session covers the timeline, product categories, secure-by-design and secure-by-default requirements, notification duties, vulnerability handling, the CEN/CENELEC standards that make all of it testable, and what the CRA means for the open source in your bill of materials.

The CRA's essential requirements are written as outcomes, which leaves the meaning of "adequate" to the harmonised standards, and to whoever has to evidence it later. This session works through the horizontal series clause by clause: EN 40000-1-1 (vocabulary), EN 40000-1-2 (principles, product risk management and lifecycle activities), EN 40000-1-3 (vulnerability handling) and EN 40000-1-4 (generic security requirements).

Most SAMM programs fail between the first assessment and the second, when the scores are in, the roadmap is written and nobody has decided who owns the work. This session covers the parts that rarely get written down: getting the organization ready, running assessments without exhausting goodwill, scoping roadmaps so they stay owned, and the change management that decides whether any of it survives the year.

One model tells you what a set of firms actually do; the other tells you what a program should be able to do. Confusing the two produces roadmaps that go nowhere. This session compares SAMM and BSIMM on structure, evidence model and cost, and on what each can and can't justify to an auditor or a board.

To an auditor, an AppSec control that can't be evidenced looks the same as one that doesn't exist. This session uses the ISO/IEC 27034 concepts of the organization normative framework and application security controls to design controls that carry their own evidence, a skill that carries over to every compliance project you'll be handed.

Most SCA programs fail on throughput, not detection: the scanner works, the queue grows, and triage capacity sets the exposure window instead of risk. This session covers designing for flow, using reachability and exploitability to cut what reaches a person, placing ownership where the upgrade actually happens, and measuring the clock that matters.

Many controls hold only while someone enforces them. The test is simple: switch off the blocking gate and see what survives. This session applies behavior science to that problem, covering why training rarely changes behavior, what actually shifts defaults, and how to build practices that outlast the person who introduced them.

The AI Act reaches any system whose output is used in the EU, wherever your company is based, and it works as product safety law rather than as a disclosure regime. This session covers which of your systems are in scope, which obligations moved to December 2027 and which apply now, and what the Act expects you to document, log and test before release.

The OWASP Top 10 tells you what commonly goes wrong. ASVS tells you what "secure enough" means, requirement by requirement, which is why it works in contracts and audits where the Top 10 doesn't. This session covers the version 5.0 structure, choosing a verification level honestly, and using the machine-readable release so your requirements stay in sync with the standard.

Most CRA coverage is written for lawyers, which doesn't help when the obligations arrive as documentation, default configurations, update mechanisms and a reporting deadline your on-call team has to meet. This session walks through the regulation from a builder's point of view, from product classification through vulnerability handling to the harmonised standards in progress, and ends on the part nobody has solved yet: your dependencies.

Secure by default means the safe configuration is the one that ships, not the one in a hardening guide nobody reads. This session translates the ENISA principles into decisions you make in design and code review, and shows why regulators now treat them as requirements rather than advice.

Every credential in a configuration file is one repository clone away from being public, and rotating it costs someone a weekend. This session covers key vaults, managed identities and shipping builds whose defaults are safe rather than left over from debugging.

Race conditions rarely show up in code review and almost never in tests, which is why they reach production and stay there. This session covers shared mutable state, atomicity, idempotency and cache coherence, and why "it works under load testing" proves less than you think.

Most serious vulnerabilities start where data crosses a boundary without being checked. This session covers finding the trust boundaries in your architecture, validating input, deserializing safely, and spotting business logic that can be abused.

The log that lets you reconstruct an incident can also hand an attacker your stack traces, tokens and customer data. This session covers failing closed, logging enough to investigate, and keeping secrets and personal data out of the output.

SAST and DAST find different things, miss different things, and both will bury you in findings if you switch them on without a plan. This session covers what each tool can and can't see, and how to tune a pipeline your developers won't learn to ignore.

Your test suite proves a feature works when it's used correctly, which isn't the interesting question. This session covers writing abuse cases alongside user stories, turning them into tests, and making sure a fixed vulnerability stays fixed.

Memory safety issues didn't disappear. They moved into the native libraries, drivers and firmware your managed code runs on. This session covers what goes wrong below the runtime, and how to reason about risk in code your language was supposed to protect you from.

The CRA makes cybersecurity a condition for placing a product on the EU market, enforced through market surveillance, mandatory reporting and penalties tied to global turnover. This session covers what the board is accountable for, what the deadlines actually are, and which decisions can't be delegated.

Done well, threat modeling finds design flaws no scanner will ever find. Done badly, it produces a backlog nobody owns and a meeting teams quietly stop attending. This session explains the activity in plain terms and gives boards and CISOs the criteria to judge which outcome they're likely to get.

A system can be fully secure and still be a privacy problem, because linking, inference and over-retention are design choices rather than vulnerabilities. This session introduces LINDDUN as a structured way to find those choices while they're still cheap to change.

Some of the most damaging attacks never touch a vulnerability. They exploit a flow that was designed to be helpful. This session shows how design decisions become attack surface, and how to spot that in a wireframe rather than in a post-incident review.

A hands-on workshop in which your team threat models one of its own systems: drawing the data flows, finding threats with STRIDE, choosing mitigations and turning them into backlog items. Champions leave able to run the next session themselves.

A practical workshop on choosing, updating and monitoring third-party packages: evaluating a dependency before you add it, keeping versions current without breaking builds, and using SBOMs and SCA tools to know what you ship.

How to express security claims, and the evidence behind them, in machine-readable formats such as CycloneDX attestations, SBOMs and VEX, so customers and auditors can verify them without a questionnaire.