 Yao from Officeworks who is the head of strategy, architecture and planning and I'll be talking to Darren today about putting the security in DevSecOps. So that keyword in DevSecOps and that new word and just off the back of that question, definitely we'll be talking about how it's changed. So Darren, if you are around, if you want to say a quick hi, so we know that we can Can you guys hear me? Yes, we can. And I'll just get you to turn your mic and camera off as well so that we can move to the next one. Awesome. Great. Excellent. Okay. Well, thanks, Darren, for being here with me today and joining us. I really appreciate having you and I'm really looking forward to our conversation. I wanted to kind of give you an opportunity to quickly kind of introduce yourself to some of our attendees who may not have heard of you. So if you wanted to give people a little bit of an intro of you, your background, what you've been working on and how this topic is known for you, that would be great. Cool. And I'm very happy to be here to share with you guys this morning. So look, I'm Darren, I look at the strategy, architecture and planning at Officeworks. I'm quite newish in Officeworks, but before, I spent a fair bit of time in mainly telcos and medias, so especially in Foxtel Group for the last 10 years before I joined Officeworks and in the retail space. My focus has been very much in architecture, engineering and platforms era. It's a terminology, but when things need to happen, we all go in and make it happen. So a job title doesn't mean much, but it's more what we have been putting out and transforming the platforms and infrastructure for the companies. So look, I think today I'm very passionate around more the people and change that we element of desktops. So I think when Isaac say, hey, come along, I have a chat, I'm so excited just to share a bit of how can we pivot this motion of change. So yeah, that's me. No, fantastic. And we're really, really excited to have you here today. So actually, just following off the back of that poll question about how the focus of security has changed over the past 12 months in DevOps, what's your perspective and take on that? Do you align with the majority, the 90% that said that it had, or are you in that 10% that say that it remains the same? No, no, I'm in the 90% of the bulk at 100%. So I think this is an interesting question, right? Because you know, like when we first started off in this waterfall, traditional way, then we went through an era of agile, break into smaller pieces, run faster, eat through the business. I think those are really good. But I think those fundamentally have break things into smaller chunks so that IT and business can iterate very quickly and we get speed to market, which is great. But I think fundamentally, did we bring security along the journey? They're kind of at the last part of the cabin most of the time, they will bring the, we brought the ops guys with us, but the security is generally still the tail end. So I think there is a lot of room for improvement in this area. Why do you think the security element has been kind of the last thing to join on the tail end? Why do you think it's been the third of the three? Hopefully there's no less security guys here. I think there's a break down into like the challenges, right? So let's start from the problem statements and see, I mean, this is more a trend and observation. So I think I'll break down into three fundamental bucket, right? So I think the first thing is the culture shift, right? If I think a step back is back to your Isaac question is why is security not instilled into the whole pipeline of a workflow today, right? And a lot of people are trying to. I think the first thing here is from a culture shift perspective is, you know, as developers, right? First thing, get caught up in market fast functionality first, business requirements first, then ops, which is great. We have, you know, stabilization of platforms, which is, which is all competing KPIs. So we kind of brought the dev and ops together for the last five to eight years, which is great. But security kind of becomes the, the ivory tower station that scanning stuff, making sure packing is up to date. And then really catching up with that is like, hey, developers, can you please make sure that you write a good code and so that we can do scanning and all those. So we are getting better, but it's still not instilled into the organic workflow. It's almost as the security folks are rapidly chasing this. And I think we got to think about, right? Is we are building more stuff that is fundamentally shifted to the digital world. So which means cyber becomes very important. You know, those are the days that we build tools and application for internal use. Everything now we are working from home. We are the digital experience is in hyper growth. So all the apps and services with you are all into the world, internet straight away. So security is almost like you cannot even negotiate. You have to pick into the workflow. So I think this culture shift of competing direction needs to be high enough over time. But that's one challenges. The other part is I call it security awareness and compliance. I feel like my, I think a lot of my peers in the cybersecurity world is one of the research that they share with us one day was, you know, one of the most common problem with generally across technology departments is security and compliance is like, it's like, I got to do it again. Oh, yes, it's another thing that we got to work on, all right. But it's the awareness is like, when a developer, when the ops guy goes in, what does it mean for them? What does it mean security and compliance? What does it mean for the company? I think that awareness and education needs to be right from the very beginning. And it's like, the security team is generally a bit, you know, like, let's say four to 10 people, right? But deaf teams and engineering team will be like hundreds easily, right? So it's like 10 people trying to convince 100 people that security is important. So I think we just got to step up the cadence in the awareness, right? So I think that's one challenges as well. But other than that, the last bucket is around the two sets that security been using are traditionally not big in the CI CD workflow. So it becomes more resistant for the deaf and ops guys to, to break into the process. Things are changing. But there's some area that a lot of vendors are trying to create more two sets of products that is more developer friendly into the workflow. So I think that's, that's something that is changing. We wish we need to look out for you. So I think that's kind of the three key challenges back to why your question of why security is at kind of the afterthought. We've got to bring it up. Yeah. Yeah, definitely. And that kind of leads on to my question about challenges next that implementing a deaf sec op strategy. Do you have anything additional to say about the challenges there with the implementation of it all? Implementation wise. That's an interesting question. I think I have a saying right is I think this might sounds very common sense to everyone, but the only thing that is variable in this entire creation is the human being, which is us. The process is created by us. I think it sounds very common sense, but I think the, the success criteria that I can see how we back in security into deaf ops is, is really how we have done way back when we break, when we bring deaf and ops together. Remember the two challenges like we have deaf ops and then we run a job that fundamental change is the goal of that change is to make sure that we collectively do something that we can support. It hasn't changed anything. Security is the same thing. We've got to do something that we can support that is secure, right? So I think a lot of companies and organizations have intrinsically been doing this already, but I guess we got to make it really, really clear the process and the handover point, the interaction point, and at different checkpoints between planning, coding, building in a testing release, deploy, operate, what is securities, deliverables and checkpoints that is efficiently baked into the workflow, right? Those needs a lot of discussion is because the encampus processes and tool set. So that's not perfect solution because every workflow is different, but I think that the key criteria here is how do we make sure that we have 10 trained cabins, every trained cabins that develop developer and operational guys deaf ops, right? How do we feed the security guys into every single cabin, which is every cabin is like a screen, right? We screen and we plan, right? So I think that's really an organization change. And I feel like the key criteria here is to make sure that we think about the end outcome. The end outcome is important is we're not trying to build a code. We're trying to build a code that is secure and high performance, right? That's very common sense. So I think that's my perspective on that question here. Yeah, definitely. And I know that you come from a different end of the DevSecOps being that you are in the architecture side of things. So how do you see enterprise architecture and architecture enable DevSecOps in organization? Yeah, this is a very tricky question. Look, I think I use the keyword here. The keyword is influencing. The influencing factor here is because from a DevSecOps perspective is really an approach, a way of building staff security away. Is this a way? A way that people come together in teams using the right two sets, right? So from an enterprise architecture perspective, is the usual way that we work is, okay, the business needs X, I got a capability Y, right? But the business now is DevSecOps. If I'm going to have a DevSecOps business users, what capability do I need to instill in the IT infrastructure to make sure that they can work in a DevSecOps way? So which means that I might look at the two sets with them that can instill into their workflow. I might influence in terms of the structure, I might influence in terms of the ways of working in the process, right? So I think those are the core because it's nothing around architecture strategy. It's less about those. It's fundamentally big into influencing the ways of working and the common two sets so that we can make insecurity right from the start, right? And I feel like there's a few stages along the way. I think my suggestion here is if you guys going to adopt the DevSecOps, right, is obviously there's security have to come on board, development ops, but then the thing here is they'll be looking at each other say, okay, cool, what are we going to do next? Are we going to use a common two set or not? But who's going to be the anostic empire referee? So the architecture is very, it's standalone, it's anostic. They say, look, this is what we should be doing. So it kind of becomes an influencing way to navigate them and help them come together, right? Because everyone has their own perspective. Dev wants to build fast, security wants to be secure, ops wants to make sure they stabilize. Architecturally, I want all three, right? So this is where my role comes in. So I think that's that's kind of my perspective on that question. Yeah. Definitely. Now, if you remember the first poll of the morning that I asked the audience, it was around how far along people were in the DevOps journey. And most people said that they hadn't started like they hadn't started a DevOps journey, or they were kind of in those very immature stages of their journey. What would be your top three tips for someone who's listening in today about how they could start their DevOps journey? Yeah. I think first thing first is realistically not a lot of people are in that journey yet, I think. Some of us might be unconsciously doing it, which is great. But I think don't get too worried by the term DevOps. And then on a day, it's around how do we build secure obligations in an iterative manner? That's a key question. So I think my three tip here is very, very simple is select something smallish in terms of don't start into the core platforms area. Start from a functionality to start off, right? Or a project that is quite independent. In our case, for example, my previous workings is we tend to start something more controlled and a lot more familiar with. And then we use that as a test bait to put in security up front. And then we kind of told everyone, look, this is beta trial. Let's be all friendly. And then we work through. And then we actually use that becomes the first draft of the process. And then we'll learn, okay, these are the two sets that is not really working. It is quite weird when we do static code testing versus dynamic code testing. It is not working. So we are building a process iteratively as well. You get what I mean, right? So I think that is find something that is very contained and controlled and then get a few evangelists. Evangelists, you know, Aaron must be, Aaron must believe that this is a good thing and come together. And then if Aaron believe you produce something great. So I think that's the second part is find people that really, really big into this idea and really come here and champion it for you, right? Because it cannot done by one person. You almost need evangelists from the death, eventually from the side, even for the ops and then come together and a bit of change management that I think you will start to take off, right? I think that is kind of a key ingredient I think. So that's the two tips. I don't have the third one, but I'll give that. No, perfect. I think two tips is great. Did you have any, I actually might just put out to the audience if you've got any questions for Darren while we've got a bit of time, feel free to send them in and we can ask them live. So while we've got Darren's brain, you may as well ask the question and see what his thoughts are. But do you have any final thoughts for our audience members on this topic? Do you have any final things you'd like to share with everyone today? Yeah, I think the key takeaway here is at the end of the day, you know, I just sum up what I've been sharing, right? It's largely around process, tools and a way of working, right? We did it before with, when we did from traditional waterfalls to agile, then we came up with depth and ops, really trying to make sure that their KPIs are all coming together. So this is no different. Is depth set ops? It's the same thing, but the product that we're building nowadays are fundamentally shifted. We are building something that is customer facing, more exposed to security vulnerabilities. And then those are not so obvious maybe 10 years ago, but now it becomes more and more. But my point here is we have done it before. I don't see why not we strengthen it with security, right? So I think we just got to go through the same process to really nail down the ways of working and the tool set and the structure and then get the right tools, because tools is enablers, right? Don't start from the tools first, always start from the process and the structure first. Then the tools come in to make sure that we dovetail. But I think if we have these three ingredients, we have done it before. I don't think it's hard. It's just another process that we got to go up to level two or level three again. Yeah, definitely. Definitely. Well, thank you so much, Darren, for joining me today for this chat. I really appreciate your time. Taking time out of your schedule to talk to me and share your insights and your wise words of wisdom with our audience today. So thank you so much for being here with us. I really appreciate it. No problem. It's my pleasure sharing this with everyone. Thank you for your time.