Building Secure Software(Panel) : Practical Strategies for Developers

This panel discussion will provide developers with practical strategies to integrate security practices into every stage of the software development lifecycle. Our expert panel will offer practical tips and techniques to immediately improve your security position, going beyond theoretical concepts.

Software development has come to depend increasingly on the comprehensive integration of security practices throughout the entire lifecycle. Practical techniques will be provided to prevent vulnerabilities and maintain software integrity, including the use of SBOMs.

Attend this practical and engaging session to gain the knowledge and tools to create a more secure and reliable software.

Please find below the seed questions.
The following points will be discussed with the panelist: their areas of expertise and the latest trends.
What are the most significant current threats to software security?
Could you please specify the three or five most important points you would like developers to take away from the session?
Could you please outline some of the most critical security topics you have encountered in your experience, which you believe would be valuable for developers to know?

Failure is not an option. It's a fact

Failure is an inevitable part of success. As an engineer, failure is not a question of if, but when. Failure in the context of innovation efforts has helped thousands of start-up companies succeed, but in the context of a known execution process it can damage results or reputation or create undue risk.
In software development we are at the intersection of innovation and known processes, so how do we benefit from failure and achieve success?
Understanding the types of failure is the key to harnessing the power behind them! This is a session for everyone because failure comes in many different forms and has several different types! We can only benefit from failure if we know how to recognise the type of failure we are facing and how to deal with it.
In this session we will explore several studies and best practices from successful companies that have embraced both.

I present multiple studies, books, white papers to showcase HOW to make it possible to leverage FAILURE and what types of failure should be address with an open strategy and which ones should be avoided

My top resources on this topics are:

HBR The special issue on failure. April 2011
HBR: Increase Your Return on Failure by Julian Birkinshaw and Martine Haas
The Failure Files perspectives on failure. Edited by David Hillson
Learning from Design Failure, Collaboratively by Shulong Yan and Marcela Borge
Learning from Success and Failure by Robert I. Sutton
Strategies for Learning from Failure by Amy C. Edmondson
The Real Reason Why Your Brain Is so Scared of Failure Failure doesn't scare you. Not knowing does By Mithu Storoni
The Skills You Need To Make Failure Productive by Vivian Giang
When We Learn From Failure (and When We Don’t) by Gretchen Gavett
The Tipping Point Between Failure and Success by Dashun Wang

CRA security deadlines loom: What senior Java engineers must deliver by December 2027

CRA, NIS2, DORA Does it ring a bell? By December 2027, the EU Cyber Resilience Act (CRA) will require Software Bills of Materials (SBOMs) for almost all software products placed on the European market. For teams working with Java, this is a significant compliance task, given their work with deep dependency trees, complex build systems and layered deployment models. This is an architectural and operational deadline that demands immediate attention.
The purpose of this session is to provide a clear and technical overview of what Java engineers, architects and DevOps teams must understand in order to meet CRA expectations and to avoid risk under NIS2 and DORA. These two initiatives increasingly treat SBOMs as evidence of supply-chain control. In this session, we provide a comprehensive explanation of the essential elements that an SBOM must capture in a Java ecosystem, including transitive dependencies, shaded JAR contents, BOM-managed versions, container layers, embedded services, and runtime components.
Attendees will learn how to integrate SBOM generation into Maven and Gradle pipelines with CycloneDX, how to supplement artefact SBOMs with container-image inventories, and how to implement them using Dependency-Track for vulnerability and license visibility. We also outline the minimal governance and workflow changes needed to ensure SBOMs stay correct throughout releases and updates without slowing developers down.
The objective is clear: to provide senior Java practitioners with the clarity, urgency, and practical guidance required to make their systems SBOM-ready before CRA enforcement begins, while enhancing overall software quality and supply-chain resilience.

All about dependencies

Modern software is built on dependencies. They accelerate delivery, extend capabilities, and allow teams to focus on differentiation. But every import is an architectural decision with long term consequences. Beneath the convenience of package managers lie transitive vulnerabilities, maintenance risks, hidden operational costs, license exposure, performance trade offs, and ecosystem fragility.
The real cost of adopting a dependency is the probability of failure multiplied by its impact. What seems efficient today can become technical debt tomorrow when maintainers disappear, APIs shift unexpectedly, governance models change, or security flaws surface deep in transitive trees. Systems that must live for years inherit not just functionality but assumptions about threading, memory, serialization, and lifecycle management.
In regulated environments shaped by the EU Cyber Resilience Act, dependency decisions intersect with secure by design and secure by default obligations, SBOM transparency, and supply chain accountability. However, dependency risk is not merely an infrastructure or compliance problem. It is a core software engineering concern. Architectural boundaries, upgrade strategies, abstraction choices, and test isolation determine whether a dependency can be replaced, patched, or contained when it fails. These are design decisions made in code, not policies written in audit documents.
This session reframes dependency management as strategic engineering rather than administrative hygiene. We examine how to evaluate long term sustainability, assess project health beyond popularity metrics, manage upgrade fatigue, design for replaceability, and build systems that remain adaptable as ecosystems evolve.
Dependencies are not downloads. They are commitments that shape system behavior, resilience, and long term ownership. This talk equips teams to choose them deliberately, responsibly, and with sustained engineering stewardship in mind.

Elevator Pitch
Every dependency you introduce is an architectural commitment that shapes your system’s risk, resilience, and long term maintainability.
This session shows why dependency management is a core software engineering discipline and how to treat external code as a deliberate, auditable design decision rather than a convenience.