Many years ago, when I was a wee baby programmer, someone taught me about “rubber duck programming”. When you can’t find the source of an error, explain your code line by line to a rubber duck. Somewhere along the way, you read out a line and realize immediately that’s where your error is. The duck didn’t fix anything. The duck never even blinked. The fixing happened the moment the bug had to survive being said out loud to something that couldn’t fill in the gaps for you.
Over the years, I’ve realized this is an amazing tool for pretty much anything you’re trying to figure out. The simple reality that took me a while to understand is that if you can’t explain a concept cleanly to someone with less context than you, you don’t own that concept yet. You’re borrowing it. It’s sitting in your head as a shape you recognize, not a thing you could rebuild from scratch, and the only way to find out which one it is is to try saying it out loud to someone who’s going to ask “wait, why” the moment you skip a step.
In product security specifically, anyone can flag a vulnerability by pointing at a scanner report and a line number. Explaining to the engineer who wrote that code exactly how an attacker reaches it, why this particular input makes it all the way to that particular function, why a permission check firing in the wrong order actually matters, is a different exercise entirely, and it’s the one that tells me whether I understand the vulnerability class or just recognize its shape. Similarly, for a finding of a vulnerability in a third-party library, I need to be able to explain to the engineer in great detail how, exactly, that vulnerability is exploitable in the context of the application. If the only answer I’ve got is “it has a CVE,” I haven’t done the job, and the engineer across the table isn’t going to willingly support a major effort in refactoring code to support a newer version.
My favorite application of this, though, is in explaining your work to a mentee or someone interested in learning more about it. They ask the question you didn’t think to ask yourself, the one that reveals your mental model had a hole in it you’d never noticed because nobody had ever pushed on that exact spot before. Every software engineer I’ve ever walked through a threat model or who has questioned the exploitability of a finding has, at some point, asked a question that improved my own understanding of the framework. That’s not a nice side effect of teaching. That’s the actual mechanism.
Truthfully, writing this blog is the same exercise at a larger scale. Every post here is me explaining something to an audience that didn’t build it alongside me, which means every post is also me finding out, in real time, which parts of my own thinking were solid and which parts were just a shape I recognized. I have never once finished writing a post about something I thought I understood and come out the other side with exactly the same understanding I started with.
I don’t treat teaching as something you do once you’ve already mastered a thing. I treat it as part of how mastery gets built in the first place, which means I look for chances to explain product security concepts out loud as often as I can, to whoever’s in the room, whether that’s a new hire, a board member, or an intern three weeks into their first job. A security program scales exactly as fast as its knowledge can be explained by more than one person in it. If you’re the only one who can explain your own findings clearly, you haven’t built a program; you’ve built a bottleneck with a badge.
Grab the duck. Or better yet, grab whoever’s newest on your team. They’ll ask better questions than the duck ever could.
Road to CISO 
Leave a comment