On the first night of BlackHat USA, I made conversation with a few friendly penetration testers who were perplexed when I told them I was a developer.
Why would I be at a cybersecurity conference?
…What was I hoping to get out of it?
My general (and perhaps vague) response to them, and to others I’d meet who would be perplexed by my attendance at both BlackHat and DefCon, was that I wanted a better cybersecurity education, particularly around AI development.
Despite my conviction, I admittedly felt a little out of place. Security conferences like BlackHat and DefCon are often seen as the domain of penetration testers, security analysts, and ethical hackers, among others. Both cybersecurity conferences are respected in their own right. And at both, I met brilliant engineers, thought-provoking speakers, and world-renowned researchers.
None of the individuals I met, however, were developers.
Having attended both of these events for the first time, I can speak from experience when I say that developers have a lot to gain from attending a cybersecurity conference. Here are five compelling reasons why developers should consider making cybersecurity conferences a part of their professional development:
As mentioned in multiple talks at BlackHat — the developers and the security professionals sit in two different camps, and they don’t intermingle as much as they should.
But innovation and security are entirely intertwined, regardless of job description or organizational divisions, and this arguably begins at the code-level. The adoption of Shift Left has put more emphasis on ensuring code quality and security early in the software development lifecycle; but a desire to produce secure code is not the same as knowing how.
Training — or awareness to training — is certainly a contributor. Just over half of software developers surveyed by The Linux Foundation and OpenSSF reported that they had never taken a course on secure software development, partly because they were unaware of a good course (though, not having the time was an equally leading reason). This lack of awareness and training might be one explanation for why 71% of organizations have security debt, with 46% of these organizations being deemed to have “critical” security debt.
Why would an organization make time to tackle its security debt unless it understood its criticality?
Or worse, if they are unaware they have it in the first place?
(This was also part of the inspiration for my Cisco DevNet podcast, The DevSec Voice. The show aims to bridge the gap between developers and the cybersecurity community.)
If you dive into articles and documentaries on major cybersecurity scandals of the 90s and 00s, you’ll notice a recurring theme: people just weren’t thinking about cybersecurity back then.
But I’ll be honest: I graduated with a Master of Software Engineering in 2021, and at the time, security was still hardly even an afterthought — let alone emphasized.
And I’m not alone in this. While the statistics on developers who feel confident writing secure code seem to vary widely, according to The State of Developer-Driven Security Survey (conducted by Evans Data Corp for Secure Code Warrior), only 35% of developers consider their teams to have “excellent proficiency” in writing vulnerability-free code.
Having a practical understanding of how to write code free from vulnerabilities can help reduce that security debt I mentioned above.
When you attend a cybersecurity conference, you not only begin to learn practical code security through DevSec/AppSec talks — you also begin to cultivate a security-minded development flow.
If cybersecurity threats are ever-evolving, so should our mitigation strategies and security practices. Generative AI (GenAI) was a huge topic of interest at BlackHat this year, partly because as quickly as GenAI and related tooling is being produced, we’ve hardly scratched the surface of security best practice standards or novel attack discovery. Developers and other engineers involved in GenAI have an ethical responsibility to understand the security and privacy risks of the GenAI they’re developing and supporting.
DefCon has a lot to offer, but one of the highlights for me as a first-time attendee was definitely the Villages. There are several different cybersecurity “Villages” ranging from AI security to social engineering to biohacking, in which visitors can participate in hands-on activities. For instance, the AI Security Village allowed you to create your own deepfake, and I tried my hand at LLM red teaming through a Capture the Flag (CTF)-style experience.
What is best practice is often not reality. Developers can work long hours and under immense amounts of pressure, and while most developers I know pride themselves on producing high quality code, there can be numerous obstacles to doing that.
By having developers at the (metaphorical) cybersecurity table, we can help the cybersecurity industry know what developers need to consistently produce secure code. This could mean that we have improved DevSec/AppSec talk track representation; or that we inspire the development of security tools and processes that make our lives easier instead of inducing burnout.
And most important of all?
A practical cybersecurity education empowers us to confidently create impactful applications, staying true to what inspired us to become developers in the first place.
Subscribe to our YouTube channel to be notified of episodes from our new podcast, The DevSec Voice. The show aims to bridge the gap between developers and the cybersecurity community through laid-back and insightful conversation.
Share:
