Full transcript
0:00Hello, Gio. Thank you so much for joining me in this interview today. Gio is one of our awesome
0:07platform engineering ambassadors. She took our awesome practitioner course and is one of the
0:13people that I basically like to to reach out to whenever I can for everything that I can,
0:18especially on the big topic that we're talking about today, security. Security really is is one
0:24of the fastest growing kind of domains within the platform engineering community. People who have
0:29been watching lots of our content know we had about 200,000 people who were engaged with our
0:34content last year or in January of this year. Now it's at around 270,000 and most of that is
0:42people with security backgrounds, observability backgrounds who are now entering the platform
0:47engineering domain. So no better person to talk to about this than Gio. So Gio, how about you
0:53just give us a quick quick round of of why do you get to be here? Why are you the expert I
0:58love to call on? Oh dear. Hello Sam. Thanks for calling me when and hi everyone. So yeah, I've
1:03um I've been working at Dashlane for the past four years. Uh I'm VP of engineering there
1:08and specifically I look after the teams that are really focused on platform uh platforms actually
1:14and sort of capabilities that we like to build for our uh fellow colleagues in on the product
1:20development side. So um when we think about platform engineering and when you know when
1:24platform engineering kind of uh emerged it was really fantastic for me cuz I I thought finally
1:29I didn't have to you know um sort of engage in in uh complicated methods to persuade people to look
1:37at my options. you know, all of a sudden I had actually a a sort of a toolkit. My teams could
1:42rely on some tangible products and we we could slowly demystify or explain DevOps principles in
1:49ways where people could actually see what those meant. Um, so in my world, my biggest challenges
1:56um have remained raising awareness around security, getting people to think a little bit
2:01more about what they're developing. Going fast is important, but making sure that what you do
2:06actually is not going to be a problem tomorrow is also important. Being able to like uh think
2:12or think on your feet when actually things do happen like you have incidents, you know,
2:16all of these things were things that really matter to me and matter to my teams day in day out and
2:21uh I kind of can't think of anything else but platform engineering as being the best solution
2:26to that for me. So I'm quite happy to talk about platform engineering in the enterprise context.
2:32uh when you're working with security or when you have challenges of those types. That's why you're
2:36here. No better person to be talking to. So, let's let's jump right into it. I was just throwing some
2:41pretty big numbers around, but basically, it's tens of thousands of security people now thinking
2:46about platform engineering. Why is that? Why has security suddenly really woken up to the value
2:53of of platform as an operating model? I think um the security world has been kind of isolated for
2:58quite some time. uh slowly got closer with or got closer thanks to the principles that were sort of
3:05um distributed around DevOps. they started understanding the benefits of you know
3:10um having uh having observability in place for instance um and so with that the next
3:17step naturally has become platform engineering and I'll give you some examples uh in security
3:22often what you have to do is try and build security awareness so typically everyone will
3:27go for the you know security champions solution which is you put you identify a few people in
3:33the organization on the platform on the sorry on the product development side some engineers ers,
3:38you get them to get really excited about security and you kind of like hope that those people are
3:42going to be your champions to make sure that you know their team is not going to do some like you
3:47know hideous ludicrous thing you know in terms of security. Now that could work but nine times out
3:54of 10 it doesn't work simply because the pressures that those teams are under the the cognitive load
3:59the the context and the complexity that we have to deal with today with with building platforms
4:05and architectures for fast markets. Um it makes it so that they just haven't got the time to really
4:12do all the things they really wanted to do like be a champion for security. So where platform
4:17engineering comes in is that you can actually bake security principles in the foundations and so
4:24the the templates that you're asking the rest of your the engineering organization to use already
4:28come with those security controls. Um so the the sort of the persuasion part of hey you need to
4:34do things properly become secondary because it's just how it is you know it's just how it is. Um,
4:40and that's that's one example where I think that's the reason why security is starting to become more
4:45interested because it it takes away the having to beg someone to care about your areas, you know,
4:51and uh, you know, there's so much begging happening in corporations these days. Oh,
4:55please do this. Oh, please do that. You know, it's it's just not something that we like to
4:59do to be honest. We like to get work done, you know, and not necessarily ask people for favors.
5:04Yeah. I used to work at quite a huge corporation and the amount of begging that has to get done.
5:09Please follow this governance framework. Please read the the the rule set that I have written out
5:16or this documentation rarely never happens. So I want to zoom in a little bit more on the DevOps
5:22versus platform engineering thing. You know, I I wore my DevOps is dead t-shirt at uh AWS reinvent.
5:29I got some a lot of thumbs up. I got some pretty uh venomous uh comments on that. Now, I'm not
5:36anti-devops at all, but I'd love to zoom in a little bit more on kind of that transition from
5:42DevOps into dev sec ops now into thinking about kind of security platform engineering. You know,
5:48what are the the gaps there where platform engineering might be fulfilling things in a
5:52better way? I'm going to use I'm going to use a a common example that is not unique to security but
5:59is unique to every single um business context up there that has like digital presence and that's
6:05incident response thinking about DevOps DevOps the principles were great they introduced this
6:11idea of like incident response logging alerting the obserability that I mentioned the the sort
6:15of the process around what you do the grading of an incident which is all great but where things
6:21got a little bit fuzzy was well Who decides the assessment of an incident or who decides on the
6:26template of the incident uh case? Who who decides if this even should be something we should add an
6:32alerting or monitoring to. Now, it basically led people to believe that every team you you know
6:40you you you build it, you run it. This ideology that basically every team gets to do their own
6:45thing. Which means that when you're actually building a single product and you need teams
6:49to collaborate together, you're reading different incidents graded in different ways in different
6:53formats. It just gets in the way of actually preventing that incident from happening again.
6:58So this decentralized in this decentralized world where DevOps principles got baked into everyone in
7:05their own way, every team, we have even more noise to deal with. We have to also deal with tribal
7:10knowledge of how to resolve incidents which let's be honest is not going to be great for any company
7:16that is looking for longevity and sort of you know running a business. So where platform engineering
7:22has come in and specifically with security is they have taken the same principles but they've
7:28actually built a common way and a centralized way of handling an incident. So you don't have
7:33to have that weight on you to decide whether this is important or not. No, we've actually agreed on
7:38a mechanism and that's the mechanism we're going to do. And you know, you can have subject matter
7:44experts to to deal with an incident, but at the same time, should this be, you know,
7:48Jim who's been in the company for 20 years and Jim is the only guy who knows how to handle that piece
7:53of the software, you know, that's it's just not feasible, right? Everyone knows that. So, I think
7:59that's what platform engineering did with DevOps. It's it's it's built uh sort of a a tangible
8:05organizational structure to that implements DevOps principles. Whereas before we had fantastic DevOps
8:12principles that were hard for us to communicate and describe to organizations. Now instead we
8:18have a very clear template. Okay, we go with for this we try for this experiment. We of course use
8:23the DevOps principles and we watch basically you know the impact. So that's that's an example I
8:29would have is incidenc is just a common example. It's interesting to me well not interesting to
8:34me but interesting that I want to point out to to everyone that nothing there mentioned was
8:40really around tooling changes. It wasn't that platform engineering introduces oh now you've
8:46got this one unified tool set. It all sounds like it's cultural changes. It's really the cultural
8:51reframing of the conversation from platform engineering. Is that correct? Yes definitely.
8:55And I and I think that's also been a a miss from our side as as the you know as an engineering
9:01leadership team as engineers to really think of platform engineering as just another method to
9:06handle your tech debt for instance. It's it's not it's literally a way to model your organization.
9:12It's a way to think about architectures that can that can be free to change that are free
9:17to change that uh you know rigidity for instance is is something that people might think platform
9:22engineering comes with. actually there's nothing rigid about platform engineering you know so and
9:27therefore having an actual product internal product that can be thought of as an enabler
9:33for other teams well that's pretty incredible so yeah I I I think we in hindsight on I think it's
9:41easy now to think in hindsight but in hindsight like at my time when I introduced the concept of
9:45platform engineering I think I kind of messed up a little bit because I should have really talked
9:50more about the business benefits of it as opposed to really fixating on the sort of nitty-gritty of
9:56the sort of the integrations on the how this is going to help us engineers. I I really should
10:02have really highlighted way more the the sort of the business benefits and I think that is
10:07something that a lot of especially people with an engineering background tend to struggle with cuz
10:12of course you know our brains don't automatically go to things like ROI or business case and I think
10:18that's a mistake that that lots make. That was actually going to be my next question on on what
10:22you would do if you were in a new organization now needing to pitch platform. But I'll take it
10:27a little bit from from a different direction. You know, platform engineering really at first
10:33optimized on this idea of DevX, you know, DevX and then a bit on the infrastructure platform
10:37engineering side over the last few years. So my question would be if you're you're coming in as
10:43a new new head of platform a VP of platform and DevX is something that people are really going
10:49to be thinking about they're really going to be thinking about the infrastructure side when do
10:52you introduce hey security should be a really key domain for us as well you could you could force
10:58introduction security at the start for instance in the context where I am it's unlikely that we would
11:04uh sort of ignore security until someone tells us you know for us security is like that baseline
11:10that defines and and incluses constraints to how we build our product. But another way around this
11:16is that actually running a DevX uh survey which is something that I I always do and I always ask
11:23my teams to do. We try to understand the patterns of who the engineers are, what is their sentiment
11:28towards work and how much do they actually know about security. Cuz one thing is having a security
11:34engineer put you in a call and ask you okay what do you know? It's security engineers also tend
11:40to also have a little bit of a cred of being, you know, the, you know, the the ones that know
11:44the most and, you know, the ones that you don't want to look silly in front of. So, there's also
11:48that cultural bit. And so, when you do a survey and you ask that question, you allow people to
11:53really truly um come out in a way and sort of uh let let understand what their vulnerabilities are
12:02um around security. And it's only through that that then we can actually think about building
12:09a an internal platform that actually addresses the securityities the security challenges that
12:15you might have in that moment in time because I think the also the other idea is that um what I
12:21discovered uh is that platform engineering is is a very is a clear concept. It's it's tangible. Um
12:28but what it is is that the the what's inside it and what how your company is reacting to it and
12:32how do you engage that's constantly moving. So you could have a moment in time where there's
12:37very low there's very immature adoption of for instance DevOps principles. You will see that
12:42in your internal platform and you can act quickly and then you'll have moments where actually oh wow
12:47actually everyone knows about everyone's really keen on observability and everyone's done their
12:51own studying and and they all have a you know a really good understanding of that and so you could
12:55sort of rein back on that. So platform engineering in a way within the security scope also it gives
13:01me a chance to focus on the on the gaps that I truly have internally rather than you know
13:07sort of taking everyone through the journey of you got to know everything you know which can be very
13:13daunting for engineers. Testing is another thing for instance and I guess testing and security are
13:18somewhat related but testing is something that especially with the arrival of AI teams are you
13:24know becoming a little bit confused about like how do I do testing do I stop doing testing how
13:29I did before do I rely on that does it even matter you know you know if I have a e-commerce product
13:34I have to ship it quickly maybe I just wait to get feedback directly from customers you know you have
13:40some developers that might think that way so with platform engineering kind of gives you it grounds
13:44you a little bit and it it really helps you to to really focus on the thing that collectively
13:50as an organization we're focusing on. So it's uh yeah it's um I I think the DevX the Devx survey
13:56is is the first step and understanding what your average developer experience is and what who your
14:03average developer is is also interesting. I sorry and maybe I'm going on too much about this but
14:08um in couple couple jobs ago I actually developed a whole framework to uh sort of
14:14um classify developers as archetypes looking and understanding how that they would engage with even
14:20reading content so reading RFC's or uh reading ADRs engaging with these important pieces of work
14:28I actually managed to map out who the developer population community was at that point right one
14:34thing is you're dealing with developers ers that are hyperengaged. They engage with everything.
14:38They have an opinion about everything. Another thing is when you have developers that are a
14:42little bit insecure, they they don't want to be seen as the ones who don't know. You have to
14:46change your language. You have to change your targets. You have to your leadership changes,
14:50you know. So, and that's all thanks to putting all this information together and actually piping it
14:55through an internal product that gives you the hard data and you also have the qual data that
14:59comes from the survey. Yeah, it's amazing. we need to build that uh some an article or some content
15:04pieces on that that framework. I remember talking to you about that in the past. So we we definitely
15:10have to hop on that. I'm curious to to focus in on the the security side. You know, security is
15:16often the probably the least sexy conversation pro probably testing I think is is the least security
15:24is kind of second. Security has some spice to it. Um, so how do you then when it comes time to talk
15:31about your feature set, you know, you're road mapping what the six months year of your your
15:36platform is and you you want to focus on security or you want to optimize for security items.
15:41How do you kind of convince your developers below, hey, this is where our attention is going to go?
15:46And how do you kind of convince your your boss above this is where our attention's going rather
15:52than something that might have a much more clear ROI in terms of a feature set for the for the
15:57internal platform. So, I'm going to try and answer this uh not specifically talking about dashing
16:02because I think, you know, we're in a very sort of privileged position. Uh my my boss, the CTO
16:08totally gets security. our sizzo past and current are incredibly switched on. So I mean the obvious
16:18answer is you have a strong sizzo and you have a CTO that knows that knows what they're doing,
16:23right? But not everyone has that luxury. Not everyone can can be that lucky, right? So in other
16:29cases the really the a good way of doing this is like trying to empathize with the developer
16:35as much as possible. I've seen security teams in the past uh antagonize developers uh where yeah
16:42again they will be like oh they don't understand they don't know you know and then trying to get a
16:46security champion program in place you know surely that's not going to go anywhere so empathizing
16:51with the developer as much as possible and especially speaking way more to product managers
16:56who perhaps are not as technical as we might like them to be but everyone understands security if
17:02you explain security in sort of in understandable in in sort in in common terms. And that's the
17:08challenge because and that's also one of the reasons why security doesn't appear to be so hot
17:12and exciting as everything else because there's a special language to it. There's uh there's a
17:18special sort of there's a special value system to it, right? there's um a sense of uh exclusion
17:26as it was as opposed to inclusion which you know I remember having multiple discussions with my sized
17:32about where do we draw the line around privilege and he was completely right in saying the least
17:37amount of privilege that's the way to go. Uh but these things are hard are hard to explain
17:43to persuade developers with no you're not going to be able to ship to production because that's
17:48just the way it is. That's hard to say especially after so many years of being said you know CI/CD
17:54you run you you know you build it you run it all this very individualistic uh you know uh comments
18:02uh have pervased the the tech world to a point where me personally I think it's kind of really
18:09hard to rein it back in you know um so what I would suggest is really leverage your debits devot
18:16principles because actually everyone believes in those and sort really focus on explaining how um
18:23security is something that will take you way too long to understand in the ins and outs. You've got
18:28to trust that security team and yeah security team knows the most about security happens. You know,
18:34you're not going to start painting a house because you think you watched a YouTube video and then
18:38you know ask money for it, right? So unless it's your house, sure, but you're not going to go out
18:42starting doing a job that you never really trained in before. So we've also got to respect expertise
18:48in that sense and I I again I think the internal product that platform engineering has proposed
18:53is is a yeah it's a great tool to use because finally someone can look at something rather
18:59than look at each other and have this really weird sort of ego ego challenging conversation between
19:06security engineer and not. Um but yeah talking is really important. So on the security side I
19:12would say you know making sure that the security engineers are not antagonizing developers. They're
19:17not just focusing on talking to their lot you know they should be talking to uh business partners who
19:24be talking to product managers. Um, we did uh an exercise which um actually I really loved and I've
19:32I've I think I never really thanked the security engineer that did it enough. But we did an entire
19:38uh an entire day was dedicated to basically doing threat modeling. I organized an offsite
19:44with all my teams and we had an entire day that was threat modeling and I I invited I had one of
19:50the security engineers basically lead that session and we were all doing threat modeling. It didn't
19:54matter whether you were a tester, whether you were an architect, everyone can get it, you know,
19:59if the right person is explaining it. So, if you don't have the luxury of being able to have that
20:05type of security engineer can explain things or that time to do an offsite specifically for threat
20:11modeling, you can certainly find ways of like uh crystallizing the security message in simple
20:16terms that then platform engineering can help you sort of manage, you know, as as the internal tool.
20:22Amazing. I want to flip that on its head now. So, we we did our state of platform engineering survey
20:29and our state of AI platform engineering survey. I think we've done a good job of not talking
20:33about AI too much uh for the first, you know, 20 minutes of this. We're obviously going to get on
20:38to AI pretty soon. Um but before we do you know we of course ask about you know relationships with
20:44security teams around governance around go like guard rails and a pretty significant contingent
20:52around 20% of those surveyed felt that their security teams were too strict to to the point
21:00of absurdity. Now I'm adding that part on there. But in the conversations and felt that there there
21:05wasn't this this kind of relationship of let's figure out how we can do this. It was very much
21:11security says this is what goes and then we're really steadfast. So I'd love to understand you
21:17know what your advice would be. So both as like a as a team lead like how do you kind of nurture
21:22those those more you know supportive relationships between between the wider team and security.
21:29uh but then maybe also you as the individual you know how would you think from the security
21:33perspective and how would you maybe persuade a security person if you even can yeah I think the
21:38first thing is always quite interesting that when when surveys are done they're always about how the
21:44product engineering world or how developers feel about security it's never the other way around
21:50you know so I think just that from a let's say an I don't know maybe an anthropological point
21:56of view maybe that should make us ask Okay, why are we always asking them about them? You know,
22:02uh, and so I want to introduce a few things that actually may not be obvious to people working
22:07in the in the sort of product development world. First of all, the architectures we have these days
22:13are completely wild. The complexity is completely like just is broken everyone's minds. We have AI,
22:20you've got data, you've got all kinds of things. Um so you have this idea of like
22:24multi and also you have a lot of cloud you know because everyone wants to use services.
22:28So you have this this combination of complex architectures built by people that are come
22:34and go because talent is constantly coming and going multicloud. And so this is literally a
22:40security governance problem like and now we have a small team that's typically always been quite
22:45small overloaded with this oh my oh my lord what the hell is going on you know that's that's the
22:50first we have to understand that's where they they are. The second bit of where they are
22:55is regulatory pressure is continuous. It's not episodic. So it's not a matter of saying, "Oh,
23:01we need to hit sock 2 and that's it." No, no, no. At one moment it's sock two, then it's ISO this,
23:07then it's that, then it's that, then it's GDPR. No one else is really obsessing over these things.
23:11But that tiny little team of security experts, they're the ones that basically are on, you know,
23:18they're on the line for that stuff. They're the ones that know this stuff inside out and
23:21they have to constantly study what the new pressure is for. The other thing that I think
23:26um we forget about which is kind of connected with the first point is in these highly complex
23:31systems we also have been building technology for longer which means we've got really big fat legacy
23:38systems that nobody knows anything about anymore and that's a walking that's a walking dis that's
23:43a disaster waiting to happen and I know it sounds a little bit like Cassandra like from from others
23:49but if you think as a security engineer who's been trained and is an expert and knows exactly
23:55actually the the weight of these things. This is a really ungrateful job. So imagine when you're
24:01starting off with that and then all of a sudden you have a bunch of developers asking you to do
24:05this and this and this and this and now you also want a security engineer to be you know empathetic
24:10and you know talk to others. I mean naturally they start thinking hey you know you're asking a
24:15bit for too much. You want me to be an expert. You also want me to be a communicator. It's a big ask.
24:20Sure, it would be it would be great for security engineers to explain these challenges tangibly
24:26and spend the time to explain these challenges. Um, but it would also be great to see developers
24:32actually understand the the lightweight of the security challenge. We don't need them to become
24:37security experts, but actually we just need them to understand the challenge the the reality we
24:41live in. We're not worried about whether the product manager is happy or not. Most of the
24:46times we're worried whether we're going to hit you know whether we've got sock two done in time
24:50you know and the risk is different connection matters. I always suggest having like sort of
24:56collab sessions where you know you have a security engineer and like maybe a team working together
25:03maybe on a particular part of the product that's uh iffy particularly iffy. Um some some of my
25:10colleagues like to do this thing where basically they'll pick a ticket and if a ticket is is sort
25:15of interesting to security they will actually work on it together and pair on it together. you know,
25:20it works for some companies, it doesn't work for others. But, you know, ultimately,
25:25I think what security teams really benefit from is having a sort of a an aid in communicating these
25:32challenges, an aid in in sort of in sort of like simplifying their world to others because their
25:38world is complex by themselves and it's also made more complex by other people's world. So that's
25:44why I kind of like think platform engineering is is a great solution for security teams because
25:49they can leverage something that's built for you know human consumption which they didn't
25:54necessarily have to build themselves and they can bake in all the rationale all the explanations in
26:00there you know and then if someone is truly interested in understanding oh but actually
26:04how does sock 2 work da da da da then you know you can take them on the journey but it's exhausting
26:09as a security expert to have to explain ins and outs every day every and you know every day to
26:16every single new developer in in this kind of wild war of like you're telling me no explain
26:22why and I also have been in those situation I I have to complain I've been in situations where
26:28I was fighting with my sizzle for stuff and it's only now that I realize like oh good lord like I
26:33have I've really driven him around the block you know like crazy like I should have given him oh
26:39god I mean sure he could have been nicer about things And I guess I was fixating about things
26:43but you know that's where the relationship comes in. So I think platform engineering is a great
26:48solution really really great solution cuz it kind of moves away all the stuff that would take you
26:54ages to explain and it kind of leaves a space for a true human relationship which I think can never
26:59go away even with an internal product. Amazing. I'm curious then to to zoom in on the AI side of
27:06things because all that stuff you talked about the complexity, the risk, legacy systems, data,
27:12regulation, AI is all of that times 10. And so I think it's no surprise that so many of the new
27:19security people coming into the community asking questions. It's coming from the the cause of of
27:25an AI approach. So I'd love to get a a few minutes of your your kind of experience on how AI has kind
27:32of reshaped things. I know in the the state of AI platform engineering report that I I wrote that
27:37we published a few months ago, a lot of security teams were kind of struggling with how to approach
27:42governance in guard rails. So either being too strict and kind of stifling experimentation or
27:50you know for for fear of being strict, not really being strict enough and and causing some kind of
27:56risk vectors there. So I'd love to kind of hear how you've approached this this AI explosion
28:00and where you think we might be going from here. Yeah, I I I think I'm going to have to first say
28:06uh disclose that this is my personal opinion, right? and in no way represents the opinion of the
28:11company I have I work at or have worked at. And I'm also myself trying to understand. I'm going to
28:17be honest. I'm also in two minds because I've had this conversation in the past where I'm not sure
28:24we still have enough data to really understand the value of AI. I know, you know, it helps my husband
28:32work. You know, it helps him write things. Cool. Uh it helps me write things. cool, but beyond
28:40that, uh, it's just a little bit fuzzy to me, you know? So, when it comes down to the world of like
28:47sort of AI tools to help like development and to go faster and be more productive,
28:53I kind of challenge that a little bit because I do think it's it's helping some types of developers,
28:59but it's not helping others. And that's where I go back to my initial point of understanding
29:03who your internal population is and almost doing a an ethnographic analysis of who your company
29:09who your engineers are are. What sent what kind of sentiment do they have towards new things or
29:14not? Um and with security naturally you'll end up with a lot of security engineers that
29:21are reluctant to support uh AI products especially that have just been built in what couple months. I
29:27mean the plethora of like AI tools to bump up your productivity. I'm not just talking about developer
29:33productivity. I'm also talking about all the other requests that are coming from other departments,
29:37right? Everyone wants like uh the app that will sort of transcribe everything. Okay,
29:42cool. But which one? There's like 30 to choose from. How do you analyze all of those? So I I I
29:48just think there's a so much right now that everyone is experimenting with everything.
29:53uh and the experiments aren't necessarily in my opinion welldesigned because even an experiment
30:00you know can be welldesigned unless we just want to go for the random approach uh and in that
30:05sense I actually would welcome a random approach for pieces of the you know pieces of the of the
30:10architecture where maybe there's this very low risk so that's also a way of doing it but I've
30:15seen companies make uh humongous use on AI tools that have not got a lot of you know they haven't
30:23got many months under the belt, you know, not in testing nor in in, you know, in actually existing.
30:30So, that to me, I don't know. That's not something we would normally do. You wouldn't normally just
30:36I don't know. I I don't know. I can't think. It just seems a little bit too much and too fast,
30:42let's say. But it could also be my age. I think that is the the ultimate ultimate statement to
30:49capture everything when it comes to the topic of AI. It's too much and it's too fast. Um,
30:55so I think we're we're both bang on there. But thank you so much, Gio, for for everything on
31:00the security landscape. I this is, you know, one of the biggest and fastest growing topics
31:05in the platform engineering discipline and I get asked about it all the time and there's no better
31:09person to have come and helped me understand. So, thank you so much and thank you everybody
31:14for watching and hope you're doing well wherever you are. See you next time. Bye bye. Thank you.