Code security for software engineers

Stream the latest episode

Listen and watch now on YouTube, Spotify, and Apple. See the episode transcript at the top of this page, and timestamps for the episode at the bottom.

Brought to You by

•⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more. Statsig are helping make the first-ever Pragmatic Summit a reality. Join me and 400 other top engineers and leaders on 11 February, in San Francisco for a special one-day event. Reserve your spot here.

•⁠ Linear ⁠ — ⁠ The system for modern product development. Engineering teams today move much faster, thanks to AI. Because of this, coordination increasingly becomes a problem. This is where Linear helps fast-moving teams stay focused. Check out Linear.

—

In this episode

As software engineers, what should we know about writing secure code?

Johannes Dahse is the VP of Code Security at Sonar and a security expert with 20 years of industry experience. In today’s episode of The Pragmatic Engineer, he joins me to talk about what security teams actually do, what developers should own, and where real-world risk enters modern codebases.

We cover dependency risk, software composition analysis, CVEs, dynamic testing, and how everyday development practices affect security outcomes. Johannes also explains where AI meaningfully helps, where it introduces new failure modes, and why understanding the code you write and ship remains the most reliable defense.

If you build and ship software, this episode is a practical guide to thinking about code security under real-world engineering constraints.

Interesting quotes from the episode:

How code quality and code security are connected:

Gergely: “How does the quality of code relate to security?”

Johannes: “This is an underrated topic in the industry today. We talked about the null pointer exceptions or these slow regular expressions, right? That can lead to security issues. That’s more of the obvious examples of bugs.

Think about unreadable code, not well-maintained code: that’s often like spaghetti code. At first, it’s not so obvious how this is connected to security.

If you think about how code is not easy to comprehend, not easy to review. Then you do pair programming or code reviews in your development team — then in that spaghetti code, you will more likely overlook security problems of your colleague.

Now, maybe someone found an issue or and issue and reports it back to you. As a