Our systems are under attack on a number of fronts. That may sound alarmist, but it's also true. By some estimates 90% of firms are likely to have suffered an attack of some kind in the last 12 months. Some may not even know it yet. So how should we best deal with the security of our systems in a world of agile development and Continuous Delivery. The answer is to build security into our systems from the outset, rather than treat it as an afterthought. So what are the things that we should worry about, and how should we deal with them? This approach is sometimes called DevSecOps, but a better term might be “Continuous Security”.

Closer collaboration between developers and operations people brought businesses many benefits. It is also fair to say, though, that it created new headaches. Some practices, especially continuous deployments, forced us to rethink the traditional security sandwich, with conceptual work up-front and a pen test at the end. It was easy to sneak a “Sec” into DevOps, it was reasonably obvious to call for security to be “shifted left”, but in practice this raised even more questions.

Based on his experience working as a consultant Erik will address these questions. He will discuss practices like container security scanning, binary attestation, and chaos engineering, alongside examples of concrete tooling to support these practices. In addition Erik will show how the concept of fitness functions, which have become popular in evolutionary approaches architecture, can be applied in the security domain.

We often define DevSecOps as ensuring that security isn't an afterthought to releasing software. It's an absolutely essential component, but initiatives can often fall into the trap of adding process and tools just to tick some boxes.

How can we make sure that DevSecOps actually happens properly, getting security people and techniques into the full flow of agile delivery, and keep everyone happy?

I'll go through the desires, the traps and pitfalls, and how to set up a DevSecOps initiative that doesn't compromise flow.

Modern software teams usually strive for Continuous Delivery of business impact with a DevOps mindset: you build it, you run it. With short iterations and continuous feedback loops, teams deploy new software to production daily.

As a software architect, it can be difficult to shape your role working in such a a fast-paced world. With daily deployments, is there even time for software architecture? How do you prevent being a delaying factor to the pace and success of a team? And how do you keep up?

In this session, I’ll share my experiences working in a DevOps world as a software architect. We’ll look at the ideas behind DevOps and plot them to the domain of software architecture. I’ll talk about “just enough” architecture, about moving from up front design to evolving architecture, and will share lots of experiences and tips along the way. After this session, you’ll have practical insights and tips in how to work as an architect with a DevOps team.

Security as Code (SaC) is the methodology of codifying security tests, scans, and policies. Security is implemented directly into the CI/CD pipeline to automatically and continuously detect security vulnerabilities. Adopting SaC tightly couples application development with security and vulnerability management, while simultaneously enabling developers to focus on core features and functionality. More importantly, it improves the collaboration between Development and Security teams and helps nurture a culture of security across the organization.

In this session, we will review lessons learned from DevOps to implement a successful DevSecOps culture, in particular how we can make developers contribute security checks with the SaC approach. We will introduce CodeQL, a language that allows us to implement security checks with code, and will demo how we can code queries for vulnerabilities and misconfigurations so they can be identified as soon as they hit your CI/CD pipeline.