Hello, hello everyone, thank you for for sticking around in spite of the last minute substitution.
It's going to be a good game anyway. So yeah, so I am Katherine Druckman. I have been around
open source for a very, very long time going back to my early days. Also in the
project incidentally, we heard about how Drupal recognizes contributions a little bit ago.
But yeah, so I've been around Drupal. I've been around many other open source communities.
I was at Linux Journal for a very long time for those of you who remember magazines when those were
a thing. Yeah, so I am currently head of community in partnership engagement at JetBrains.
But this is not about that, because in addition to that, I am also a human who genuinely cares
about open source software and software ecosystem and keeping software secure.
And I have for several years been involved in some open source security projects. Most notably
the open source security foundation. I volunteered there quite a bit. And I have a lot of feeling.
So I'm going to share them today. I think that I'm going to talk about the critically
important role that developer relations and communities play in software security. Maybe
not obvious to all people, but it's obvious to me. So this is a real reddit post, by the way.
So let's talk about the great security divide that seems to exist between a lot of development teams
and their security colleagues. What do I mean by security divide?
Gotten through some of this post, maybe a good idea. But there's kind of an usual disconnect
that I see between security and development teams that offer often fosters kind of an us versus
them mentality, which is not helpful. It hinders collaborative progress and the adoption of crucial
security practices. Here's an example of what I'm talking about.
A developer posted this on Reddit. Not that long ago, it's the end of the last six months or so.
But he basically says the security team keeps breaking RCACD. The security team in this case is
very much a them to the developer and that's posting this. The security teams added 47 new scanning
tools, which I'm sure the security team finds very valuable. But they take forever, they randomly
fail and pardon the adult language in there, but this is the internet. It's a real post.
But the developers complain of slow feedback loops and perceived inaccuracies.
And worse, they report developers reporting, they're resorting to pushing code directly to
production, which is not something we will put. That's kind of terrifying. As a person who uses
software and would like it to be secure. So the interesting thing, of course, is that this part
post got 316 up folks. There are 162 comments from developers sharing similar experiences.
This is not all that isolated. One, we call the message, we call the story that their actual
security issues continue to accumulate because they are unable to release anything at all.
So this is what, a hat tip, by the way, to Kathy Serra, if you don't know who Kathy Serra is,
she was a long time usability expert, really fantastic. I have carried this similar image with me
in my mind from a 2009 keynote she gave itself by Southwest. But this kind of sums up
part of this disconnect that leads to the divide that I mentioned. We have, we have a lot of
security experts in the world and of the world of open source. Many, many are around here at Fox
Dem, giving their talks, releasing all these fantastic tools, releasing them to the community,
usually with ample documentation, presenting a new lovely option to their intended audience
and users, but maybe too many options. If we're finding it takes at least a 30-minute
explanation per tool and a lot of nuance to recommend a tool for a specific issue,
we start to lose the intended user of these tools that we've developed. We like to think
much like this image that the intended users intrigued. Does an index investigation pours
over the documentation, trying to figure out where this nifty new tool fits into their workflow?
Build it and they will come, right, field of dreams. So we like to think that they're all
soaking up all this great knowledge, getting to know all the players and the project
that they want to use. This is the dream, but it's probably not what's happening. What's
probably happening is that they're doing a quick install, running into an issue, punching
their laptop, and walking away. We've all been there, right? Or someone else has mandated that
they use this nifty new tool, like in our Reddit post, and it has become their nightmare,
and they punch their laptop and they walk away. That's not to get us more secure software.
So here's the thing. We've solved a lot of technical problems, and now we need to solve the
human ones, and those can be far, far more difficult, which is why we are here today in a community
bedroom, because these problems often become the most difficult to solve. Given that the developer
and security roles involved in creating secure software are likely a little out of sync, again,
back to that Reddit post, and as we've probably seen in the wild, this inevitably leads to
frustration, and then maybe some pushback, or worse, pushback that leads to bypassing security
tools altogether, which produces less secure software, which affects all of us. So how do we work
to solve the problem? The answer is relationship building. It large and small scales,
and that's what developer relations is about. It's about being empathetic to real needs, real
human needs, being collaborative, and about being human. Security teams often operate from a
compliance and enforcement mindset, right? That's the goal. The goal is compliance, and they've
you developers, as potential sources of failure. Like, we're all like walking points of failure,
like potential, potential disasters waiting to happen, but we're also humans. On the other hand,
developers prioritize speed, innovation, shipping features, and often pursue security is a bottleneck
or an imposition. This fundamental difference in objectives creates that significant divide that
I started with. So the result is an environment where security tools despite their critical importance
are often met with resistance rather than adoption, which is just awfully counterproductive,
and gets in the way of effective risk mitigation. But what if we flip that script a little bit,
make developers choose to use the right security tools, because they meet their needs, because they
understand why they meet their needs. They understand the benefit. They want to use them.
Now it helps if these tools are easy to use. Lovely AI, generate an image, a little bit proud of.
For so many reasons, though developer relations is not just a nice to have. It's an essential
function in enables, effective collaboration, and security across an organization. By fostering
strong relationships and communication between developers, security teams, and open source
security projects, by the way, shout out to the open SSF and others. Develop relations helps
drive security best practices and solutions that are practical and sustainable. If the neon
security nerves just make friends with developers, you know, in this surreal and colorful landscape,
developers wouldn't have to rant on Reddit anymore. So how do we actually accomplish this?
We hear meet developers where they are a lot. And what that means is reaching them
in their native environments, make sure your projects are communicating in ways, and in the places
where it will be received. Maybe it means slack alerts, maybe it means they're on discord, maybe even
snack, sack overflow, who knows, but make sure to put some effort into finding where your audience
is. Then focus on what messaging is meaningful to them. Always provide useful context.
Why does this matter in our documentation, in our user interaction, in our alerts, our features,
always consider meaningful context and the developer experience. Re-center our focus on the
intended users of the tools that we create, and not on the messaging that we think that they need.
And building on the above tone, I think matters just as much. Security, security, messaging,
I find, can sometimes have a policing tone. But instead, we should focus on sincerely being helpful
and creating partnership, and the intended outcome is far more likely to be successful.
And then, how do we know we're being effective? Our industry loves measure things, don't we?
I love to measure. Let's make sure to track the success that actually matters. Maybe that's improving
time to remediation of security issues, maybe it's developer satisfaction with the security tools and
question, and it may vary by project and audience. And finally, sometimes a sometimes overlooked
devural strategy is effective feedback loop. It should be fundamental, but it is frequently
overlooked, I think. In order to build the collaborative relationship you need to build adoption,
make sure your users are being heard, collect an implement feedback early and often,
and gathering the feedback helps you improve the tools and question.
So, everything I just said is even more critical for open source projects, of course. We're here at
Foxdown. We know these things, but in order for open source projects to be sustainable,
we first need to build awareness and adoption, but then that ideally leads to contribution,
and even training up new maintainers, and we've just talked about throughout the day,
ensuring the long-term success of the project. So, this constant communication and relationship
building with the intended beneficiaries of your projects pays even greater dividends in open source
projects, because this is how you keep them going once they've reached any kind of critical mouse.
So, I mentioned a little bit ago, tracking success in ways that matter.
Right, so what does that mean? Developer satisfaction might be one, happy developers, happy life,
or secure life. If you meet the needs of the people you're tools or are created to help,
we're not creating them for ourselves, are we? You were created to be used and implemented,
and to be integrated into workflows. But once you create the things that resonate and actually solve
the problems, they become your loyal advocates who will evangelize your projects.
Assessing the depths and value of interactions might be another valuable measurement.
Types of questions asked, the quality of the feedback that's provided,
but subjective, but worth keeping track of, an active community participation gives you an idea
of what's working and what's not. I think it's important for all of us, again, who use software,
which is all of us, I assume, or I hope. It's important for all of us to participate in
capturing security problems and ultimately deliver better outcomes. So let's focus on the success
of those efforts, right? Are we truly helping this beat up remediation? Are we doing security
theater? Are we furthering secure development best practices? I think we capture and then build on that.
And by the way, the stakes are pretty high. We don't want developers shipping into your code
because they're frustrated with security tooling. That's an on-starter. If we build the
necessary relationships with scale, though, we can shift the narrative, right? Bridge that
divide that I started with. No more us versus them. We create a culture of collaboration rather than
just compliance. Again, remember the Reddit post I started with. That's a very real example
that we can file away in our mental filing cabinets. To always keep in mind, when we're doing
all of the great work that our projects and our projects and communities, how can we solve
security problems or any problems in the most frictionless way? Treating developers as compliance
obstacles might get us compliance theater. If you treat the developers, we want to reach as
collaborators, we get the outcome we want, which is better software, more secure software.
So just really quickly, right? Basically, we need people to use all these great tools for creating
deeply integrating developer relations in our approach leads to more adoption, less developer
friction, and better problem solving across the software landscape. And we do this by empowering
developers, right? We want developers to feel like they have superpowers. We build real relationships
built on trust and by flipping the us versus them mentality completely on a set. Take a step back
and zoom out from the code and the infrastructure and see the people who are trying to do their
best work in the most secure way and remember to treat them as people, offer help or needed,
and then maybe get out of the way to enable them to go do great things. Again, to invoke Kathy
Sira who's brilliant and I wish created more talks and writing these days. But to invoke her again,
it's not about making them think the tools are awesome. It's about making them feel awesome about
themselves, their abilities, and empowering them to feel like security heroes, software engineering
heroes, development heroes. So I propose we answer some of these questions together, right?
How do you set up the right communication channels and keep them thriving for your projects?
What does really good documentation look like? I think there are some projects that are doing this
really really well. What can we learn from each other? How do you handle conflict when developers
push back in particular on security requirements? Things that are very important? How do you handle
that? So this is the part where I tell you to go join an open source security community. There are
several open SSF has a developer relations community that I'm a part of. I encourage you to join
that one. But wherever you go, let's solve these things together, right? Join the conversation
helps, brother, word, collect the feedback, improve the tools, improve the open source security
landscape. I have plenty of time for questions being that I am a considerate way.
Yes, I would love to talk to you about making software better by being a better human.
Thank you, a lot that makes a lot of sense, but it makes a massive assumption which is that
we are developers actually still write the code. Instead of DevRel, don't we need AI or Agent
Rel? And how would you adapt with a rate on that presentation for AI relation?
Well, that's a really good question. However, I think at this point in time, we still have
humans in the loop that are using the agents, right? So I don't think at this point,
I mean, a shutter to think of a reality where we can just completely bypass human needs, but
I think at this point, it's not all that relevant. I think agents are tools for humans,
and you still have to deal with human pushback on, especially, again, going back to, let's
go back to the original slide here, the Reddit post and question. I don't think that AI
agents solves this problem in any way. I don't think they change it, I don't think they change
the conversation all that much. Because at the end of the day, especially when you're talking
about security tooling, you have people in a different part of your company and a different part
of your process, organization of some sort, making decisions about what is correct for security
best practices. And they probably know what they're talking about. I mean, they definitely do
in most cases. And so I think what this comes down to and what agents can't solve are
convincing people why they need to do a thing the right way. So I think yes, in theory,
at some point there is a lot of agentic interaction and that kind of thing, but I think that is
I don't know, happening in a different place than these kinds of disagreements, frustrations,
conflicts. So I think at this point in time in history, now who knows, five years, one year from now,
who knows what it's going to look like. But today, these human problems are still very relevant
because you still do need to convince people why certain things just matter. So that's my take today.
Ask me again next year, I don't know. We have five or four minutes, anyone questions?
No, thank you very much again. Thank you.