WEBVTT 00:00.000 --> 00:11.840 Hello, hello everyone, thank you for for sticking around in spite of the last minute substitution. 00:11.840 --> 00:18.080 It's going to be a good game anyway. So yeah, so I am Katherine Druckman. I have been around 00:18.080 --> 00:24.160 open source for a very, very long time going back to my early days. Also in the 00:24.400 --> 00:30.560 project incidentally, we heard about how Drupal recognizes contributions a little bit ago. 00:30.560 --> 00:34.640 But yeah, so I've been around Drupal. I've been around many other open source communities. 00:35.440 --> 00:40.480 I was at Linux Journal for a very long time for those of you who remember magazines when those were 00:40.480 --> 00:46.400 a thing. Yeah, so I am currently head of community in partnership engagement at JetBrains. 00:48.000 --> 00:52.880 But this is not about that, because in addition to that, I am also a human who genuinely cares 00:52.880 --> 00:57.920 about open source software and software ecosystem and keeping software secure. 00:58.480 --> 01:04.880 And I have for several years been involved in some open source security projects. Most notably 01:04.880 --> 01:10.480 the open source security foundation. I volunteered there quite a bit. And I have a lot of feeling. 01:10.480 --> 01:16.160 So I'm going to share them today. I think that I'm going to talk about the critically 01:16.160 --> 01:22.960 important role that developer relations and communities play in software security. Maybe 01:22.960 --> 01:30.800 not obvious to all people, but it's obvious to me. So this is a real reddit post, by the way. 01:30.800 --> 01:38.720 So let's talk about the great security divide that seems to exist between a lot of development teams 01:39.680 --> 01:44.960 and their security colleagues. What do I mean by security divide? 01:46.320 --> 01:52.160 Gotten through some of this post, maybe a good idea. But there's kind of an usual disconnect 01:52.160 --> 01:57.840 that I see between security and development teams that offer often fosters kind of an us versus 01:57.840 --> 02:05.920 them mentality, which is not helpful. It hinders collaborative progress and the adoption of crucial 02:05.920 --> 02:11.360 security practices. Here's an example of what I'm talking about. 02:11.360 --> 02:17.280 A developer posted this on Reddit. Not that long ago, it's the end of the last six months or so. 02:18.000 --> 02:25.200 But he basically says the security team keeps breaking RCACD. The security team in this case is 02:25.200 --> 02:32.640 very much a them to the developer and that's posting this. The security teams added 47 new scanning 02:32.640 --> 02:37.600 tools, which I'm sure the security team finds very valuable. But they take forever, they randomly 02:37.600 --> 02:43.760 fail and pardon the adult language in there, but this is the internet. It's a real post. 02:44.480 --> 02:49.760 But the developers complain of slow feedback loops and perceived inaccuracies. 02:51.840 --> 02:56.720 And worse, they report developers reporting, they're resorting to pushing code directly to 02:56.720 --> 03:01.840 production, which is not something we will put. That's kind of terrifying. As a person who uses 03:01.840 --> 03:06.240 software and would like it to be secure. So the interesting thing, of course, is that this part 03:06.240 --> 03:13.680 post got 316 up folks. There are 162 comments from developers sharing similar experiences. 03:14.240 --> 03:21.680 This is not all that isolated. One, we call the message, we call the story that their actual 03:21.680 --> 03:28.240 security issues continue to accumulate because they are unable to release anything at all. 03:30.640 --> 03:35.360 So this is what, a hat tip, by the way, to Kathy Serra, if you don't know who Kathy Serra is, 03:35.360 --> 03:42.560 she was a long time usability expert, really fantastic. I have carried this similar image with me 03:42.560 --> 03:48.400 in my mind from a 2009 keynote she gave itself by Southwest. But this kind of sums up 03:49.360 --> 03:55.200 part of this disconnect that leads to the divide that I mentioned. We have, we have a lot of 03:55.200 --> 04:00.320 security experts in the world and of the world of open source. Many, many are around here at Fox 04:00.320 --> 04:06.640 Dem, giving their talks, releasing all these fantastic tools, releasing them to the community, 04:06.640 --> 04:12.960 usually with ample documentation, presenting a new lovely option to their intended audience 04:13.120 --> 04:19.120 and users, but maybe too many options. If we're finding it takes at least a 30-minute 04:19.120 --> 04:24.240 explanation per tool and a lot of nuance to recommend a tool for a specific issue, 04:24.240 --> 04:31.120 we start to lose the intended user of these tools that we've developed. We like to think 04:31.120 --> 04:37.520 much like this image that the intended users intrigued. Does an index investigation pours 04:37.520 --> 04:42.720 over the documentation, trying to figure out where this nifty new tool fits into their workflow? 04:43.840 --> 04:51.360 Build it and they will come, right, field of dreams. So we like to think that they're all 04:51.360 --> 04:55.280 soaking up all this great knowledge, getting to know all the players and the project 04:56.480 --> 05:01.680 that they want to use. This is the dream, but it's probably not what's happening. What's 05:02.000 --> 05:07.920 probably happening is that they're doing a quick install, running into an issue, punching 05:07.920 --> 05:15.280 their laptop, and walking away. We've all been there, right? Or someone else has mandated that 05:15.280 --> 05:21.760 they use this nifty new tool, like in our Reddit post, and it has become their nightmare, 05:22.480 --> 05:29.200 and they punch their laptop and they walk away. That's not to get us more secure software. 05:29.280 --> 05:33.840 So here's the thing. We've solved a lot of technical problems, and now we need to solve the 05:33.840 --> 05:39.440 human ones, and those can be far, far more difficult, which is why we are here today in a community 05:39.440 --> 05:46.720 bedroom, because these problems often become the most difficult to solve. Given that the developer 05:46.720 --> 05:53.840 and security roles involved in creating secure software are likely a little out of sync, again, 05:53.840 --> 05:59.920 back to that Reddit post, and as we've probably seen in the wild, this inevitably leads to 05:59.920 --> 06:08.320 frustration, and then maybe some pushback, or worse, pushback that leads to bypassing security 06:08.320 --> 06:15.760 tools altogether, which produces less secure software, which affects all of us. So how do we work 06:15.760 --> 06:20.960 to solve the problem? The answer is relationship building. It large and small scales, 06:21.920 --> 06:27.040 and that's what developer relations is about. It's about being empathetic to real needs, real 06:27.040 --> 06:36.480 human needs, being collaborative, and about being human. Security teams often operate from a 06:36.480 --> 06:42.800 compliance and enforcement mindset, right? That's the goal. The goal is compliance, and they've 06:42.880 --> 06:48.960 you developers, as potential sources of failure. Like, we're all like walking points of failure, 06:49.520 --> 06:54.640 like potential, potential disasters waiting to happen, but we're also humans. On the other hand, 06:54.640 --> 07:02.080 developers prioritize speed, innovation, shipping features, and often pursue security is a bottleneck 07:02.080 --> 07:09.040 or an imposition. This fundamental difference in objectives creates that significant divide that 07:09.040 --> 07:17.600 I started with. So the result is an environment where security tools despite their critical importance 07:17.600 --> 07:23.200 are often met with resistance rather than adoption, which is just awfully counterproductive, 07:24.000 --> 07:29.440 and gets in the way of effective risk mitigation. But what if we flip that script a little bit, 07:29.440 --> 07:34.400 make developers choose to use the right security tools, because they meet their needs, because they 07:34.400 --> 07:38.880 understand why they meet their needs. They understand the benefit. They want to use them. 07:38.880 --> 07:45.920 Now it helps if these tools are easy to use. Lovely AI, generate an image, a little bit proud of. 07:48.320 --> 07:53.200 For so many reasons, though developer relations is not just a nice to have. It's an essential 07:53.200 --> 08:00.080 function in enables, effective collaboration, and security across an organization. By fostering 08:00.080 --> 08:05.840 strong relationships and communication between developers, security teams, and open source 08:05.840 --> 08:12.000 security projects, by the way, shout out to the open SSF and others. Develop relations helps 08:12.000 --> 08:18.240 drive security best practices and solutions that are practical and sustainable. If the neon 08:18.240 --> 08:25.600 security nerves just make friends with developers, you know, in this surreal and colorful landscape, 08:25.600 --> 08:31.360 developers wouldn't have to rant on Reddit anymore. So how do we actually accomplish this? 08:33.200 --> 08:40.400 We hear meet developers where they are a lot. And what that means is reaching them 08:42.080 --> 08:47.200 in their native environments, make sure your projects are communicating in ways, and in the places 08:47.200 --> 08:52.560 where it will be received. Maybe it means slack alerts, maybe it means they're on discord, maybe even 08:52.560 --> 08:57.040 snack, sack overflow, who knows, but make sure to put some effort into finding where your audience 08:57.040 --> 09:04.080 is. Then focus on what messaging is meaningful to them. Always provide useful context. 09:05.360 --> 09:11.680 Why does this matter in our documentation, in our user interaction, in our alerts, our features, 09:11.680 --> 09:18.240 always consider meaningful context and the developer experience. Re-center our focus on the 09:18.240 --> 09:23.920 intended users of the tools that we create, and not on the messaging that we think that they need. 09:26.720 --> 09:33.440 And building on the above tone, I think matters just as much. Security, security, messaging, 09:33.440 --> 09:41.200 I find, can sometimes have a policing tone. But instead, we should focus on sincerely being helpful 09:42.320 --> 09:46.320 and creating partnership, and the intended outcome is far more likely to be successful. 09:46.320 --> 09:53.440 And then, how do we know we're being effective? Our industry loves measure things, don't we? 09:53.440 --> 09:58.880 I love to measure. Let's make sure to track the success that actually matters. Maybe that's improving 09:58.880 --> 10:05.920 time to remediation of security issues, maybe it's developer satisfaction with the security tools and 10:05.920 --> 10:14.560 question, and it may vary by project and audience. And finally, sometimes a sometimes overlooked 10:14.640 --> 10:20.400 devural strategy is effective feedback loop. It should be fundamental, but it is frequently 10:20.400 --> 10:25.520 overlooked, I think. In order to build the collaborative relationship you need to build adoption, 10:26.400 --> 10:30.720 make sure your users are being heard, collect an implement feedback early and often, 10:31.840 --> 10:34.800 and gathering the feedback helps you improve the tools and question. 10:36.640 --> 10:42.000 So, everything I just said is even more critical for open source projects, of course. We're here at 10:42.000 --> 10:46.880 Foxdown. We know these things, but in order for open source projects to be sustainable, 10:48.320 --> 10:53.200 we first need to build awareness and adoption, but then that ideally leads to contribution, 10:53.200 --> 10:57.920 and even training up new maintainers, and we've just talked about throughout the day, 10:58.800 --> 11:04.960 ensuring the long-term success of the project. So, this constant communication and relationship 11:04.960 --> 11:11.360 building with the intended beneficiaries of your projects pays even greater dividends in open source 11:11.360 --> 11:15.760 projects, because this is how you keep them going once they've reached any kind of critical mouse. 11:18.000 --> 11:23.280 So, I mentioned a little bit ago, tracking success in ways that matter. 11:24.000 --> 11:29.440 Right, so what does that mean? Developer satisfaction might be one, happy developers, happy life, 11:29.440 --> 11:35.440 or secure life. If you meet the needs of the people you're tools or are created to help, 11:35.440 --> 11:40.240 we're not creating them for ourselves, are we? You were created to be used and implemented, 11:40.240 --> 11:49.280 and to be integrated into workflows. But once you create the things that resonate and actually solve 11:49.280 --> 11:54.800 the problems, they become your loyal advocates who will evangelize your projects. 11:56.400 --> 12:01.920 Assessing the depths and value of interactions might be another valuable measurement. 12:02.880 --> 12:07.360 Types of questions asked, the quality of the feedback that's provided, 12:07.360 --> 12:13.360 but subjective, but worth keeping track of, an active community participation gives you an idea 12:13.360 --> 12:20.480 of what's working and what's not. I think it's important for all of us, again, who use software, 12:20.480 --> 12:26.640 which is all of us, I assume, or I hope. It's important for all of us to participate in 12:26.640 --> 12:33.680 capturing security problems and ultimately deliver better outcomes. So let's focus on the success 12:33.680 --> 12:38.720 of those efforts, right? Are we truly helping this beat up remediation? Are we doing security 12:38.720 --> 12:43.840 theater? Are we furthering secure development best practices? I think we capture and then build on that. 12:45.120 --> 12:49.520 And by the way, the stakes are pretty high. We don't want developers shipping into your code 12:49.520 --> 12:54.720 because they're frustrated with security tooling. That's an on-starter. If we build the 12:54.720 --> 12:59.840 necessary relationships with scale, though, we can shift the narrative, right? Bridge that 12:59.840 --> 13:05.920 divide that I started with. No more us versus them. We create a culture of collaboration rather than 13:05.920 --> 13:12.080 just compliance. Again, remember the Reddit post I started with. That's a very real example 13:12.080 --> 13:17.840 that we can file away in our mental filing cabinets. To always keep in mind, when we're doing 13:17.840 --> 13:22.880 all of the great work that our projects and our projects and communities, how can we solve 13:22.880 --> 13:29.760 security problems or any problems in the most frictionless way? Treating developers as compliance 13:29.760 --> 13:35.840 obstacles might get us compliance theater. If you treat the developers, we want to reach as 13:35.840 --> 13:40.800 collaborators, we get the outcome we want, which is better software, more secure software. 13:42.640 --> 13:48.480 So just really quickly, right? Basically, we need people to use all these great tools for creating 13:49.440 --> 13:55.760 deeply integrating developer relations in our approach leads to more adoption, less developer 13:55.760 --> 14:03.760 friction, and better problem solving across the software landscape. And we do this by empowering 14:03.760 --> 14:11.360 developers, right? We want developers to feel like they have superpowers. We build real relationships 14:11.360 --> 14:18.000 built on trust and by flipping the us versus them mentality completely on a set. Take a step back 14:18.000 --> 14:23.440 and zoom out from the code and the infrastructure and see the people who are trying to do their 14:23.440 --> 14:29.760 best work in the most secure way and remember to treat them as people, offer help or needed, 14:29.760 --> 14:36.400 and then maybe get out of the way to enable them to go do great things. Again, to invoke Kathy 14:36.400 --> 14:43.840 Sira who's brilliant and I wish created more talks and writing these days. But to invoke her again, 14:43.840 --> 14:49.920 it's not about making them think the tools are awesome. It's about making them feel awesome about 14:49.920 --> 14:56.560 themselves, their abilities, and empowering them to feel like security heroes, software engineering 14:56.560 --> 15:04.320 heroes, development heroes. So I propose we answer some of these questions together, right? 15:04.320 --> 15:10.000 How do you set up the right communication channels and keep them thriving for your projects? 15:10.960 --> 15:16.000 What does really good documentation look like? I think there are some projects that are doing this 15:16.000 --> 15:22.000 really really well. What can we learn from each other? How do you handle conflict when developers 15:22.000 --> 15:26.720 push back in particular on security requirements? Things that are very important? How do you handle 15:26.720 --> 15:32.640 that? So this is the part where I tell you to go join an open source security community. There are 15:32.640 --> 15:38.800 several open SSF has a developer relations community that I'm a part of. I encourage you to join 15:38.800 --> 15:43.200 that one. But wherever you go, let's solve these things together, right? Join the conversation 15:43.200 --> 15:48.240 helps, brother, word, collect the feedback, improve the tools, improve the open source security 15:48.240 --> 15:55.680 landscape. I have plenty of time for questions being that I am a considerate way. 15:57.920 --> 16:02.080 Yes, I would love to talk to you about making software better by being a better human. 16:08.960 --> 16:16.400 Thank you, a lot that makes a lot of sense, but it makes a massive assumption which is that 16:16.400 --> 16:26.160 we are developers actually still write the code. Instead of DevRel, don't we need AI or Agent 16:26.160 --> 16:32.880 Rel? And how would you adapt with a rate on that presentation for AI relation? 16:33.520 --> 16:38.720 Well, that's a really good question. However, I think at this point in time, we still have 16:38.720 --> 16:47.760 humans in the loop that are using the agents, right? So I don't think at this point, 16:49.840 --> 16:54.640 I mean, a shutter to think of a reality where we can just completely bypass human needs, but 16:54.640 --> 17:00.480 I think at this point, it's not all that relevant. I think agents are tools for humans, 17:00.480 --> 17:08.160 and you still have to deal with human pushback on, especially, again, going back to, let's 17:08.160 --> 17:15.760 go back to the original slide here, the Reddit post and question. I don't think that AI 17:15.760 --> 17:20.080 agents solves this problem in any way. I don't think they change it, I don't think they change 17:20.080 --> 17:24.880 the conversation all that much. Because at the end of the day, especially when you're talking 17:24.880 --> 17:32.000 about security tooling, you have people in a different part of your company and a different part 17:32.000 --> 17:38.880 of your process, organization of some sort, making decisions about what is correct for security 17:38.880 --> 17:44.080 best practices. And they probably know what they're talking about. I mean, they definitely do 17:44.080 --> 17:51.680 in most cases. And so I think what this comes down to and what agents can't solve are 17:52.560 --> 17:59.840 convincing people why they need to do a thing the right way. So I think yes, in theory, 18:00.640 --> 18:06.640 at some point there is a lot of agentic interaction and that kind of thing, but I think that is 18:09.200 --> 18:14.640 I don't know, happening in a different place than these kinds of disagreements, frustrations, 18:14.640 --> 18:20.480 conflicts. So I think at this point in time in history, now who knows, five years, one year from now, 18:20.960 --> 18:25.360 who knows what it's going to look like. But today, these human problems are still very relevant 18:25.360 --> 18:33.760 because you still do need to convince people why certain things just matter. So that's my take today. 18:33.760 --> 18:40.480 Ask me again next year, I don't know. We have five or four minutes, anyone questions? 18:42.240 --> 18:46.480 No, thank you very much again. Thank you.