Why vulnerability management balances transparency with user safety

Understanding community norms before contributing, just like assessing vulnerabilities before going public.

Working on security vulnerabilities in private is a big time sink, but disseminating too much information too early can expose users to nefarious actors before fixes are ready. In this episode, Jeremy Stanley, Senior Principal Engineer at OpenInfra Foundation, joins the We Love Open Source podcast to share why vulnerability management requires puzzle-solving meticulousness, how to lurk in communities before contributing, and why every job in his 35-year career came through people he knows, not blind resume submissions.

Jeremy’s been in open source communities since the early 90s, starting with hand-rolled manual kernel and user space installations for Linux, then Softlanding Linux, Slackware, and Red Hat before discovering Debian in the late 90s. Its community-oriented distribution appealed to him. He’s now a director and officer of Software in the Public Interest, the charity providing a home to Debian and other community Linux distributions and popular open source projects.

Balancing public transparency with private necessity

Vulnerability management appeals to puzzle solvers requiring attention to detail and meticulousness. The challenge: Balancing open source transparency with user safety. Most communities do all work in the open on publicly visible tooling. Anyone can see software changes and bug reports. But security vulnerabilities flip this on its head. 

You must be careful about disseminating information early in a vulnerability report’s lifespan. Don’t have too many eyes on it until you assess the situation, develop fixes, and provide them to users before it becomes well known enough for nefarious actors to exploit. This creates challenges because developers used to working publicly can’t use their normal tools when collaborating privately. It slows them down and wastes time.

Open source’s biggest resource is people. Working on security issues privately is a time sink. Jeremy’s biggest task: Assessing when it’s safe to work on reports publicly versus continuing privately.

Read more: The AI slop problem threatening open source maintainers

How to get involved in open source

When getting involved in open source, remember it’s about community. Don’t barge in without understanding culture and norms. Lurk for a bit. Watch established members’ interactions, tools, workflows, preferences, and what they avoid. Start slow with limited engagement and feel out the relationship.

Jeremy’s career advice centers on building relationships. Put yourself out there, make friends, and attend conferences or local user groups. The more people you know doing what you want to do, the easier finding a job becomes. Every job in his 35-year career came through people he knows, not blind resume submissions.

Key takeaways

• Vulnerability management balances transparency with user safety: Working on security issues privately is a time sink, but disseminating information too early exposes users to nefarious actors before fixes are ready.
• Lurk before contributing to open source communities: Watch established members’ interactions, tools, workflows, and preferences before engaging. Start slow and feel out the relationship.
• Every job comes through people you know: Put yourself out there at conferences or local user groups. Networking beats blind resume submissions.

Respect community culture, balance security with openness, and build relationships. That’s how Jeremy built a 35-year career without a single blind resume submission.

More from We Love Open Source

• 15 open source backup solutions to protect your data
• The AI slop problem threatening open source maintainers
• Why 1.3 billion people depend on progress, not perfection
• Model parameters grew 3x in 10 years: Here’s what that means
• How to engage with policy makers when you’re a developer (not a lobbyist)