This article is based on reporting originally published on SDXCentral, featuring commentary from Guy Podjarny, founder and president of Snyk.
Remote Work as a Security Wake-Up Call
The COVID-19 pandemic pushed development teams into remote work almost overnight. For many organizations, this sudden shift exposed structural weaknesses that had been quietly accumulating for years: poor visibility into what development teams were actually doing, over-reliance on centralized security controls, and a persistent gap between security teams and developers.
Guy Podjarny, founder and president of Snyk — a security company focused on helping developers find vulnerabilities in open source code and Kubernetes-based applications — put it bluntly: “Security has historically been very much about control, and that was already being challenged around visibility into what development teams are doing. So at a high level, you need to shake off this illusion that you can centrally control what development is doing. That wasn’t true before. You’ve been kind of walking on this thin ice. And then the virus shattered it.”
The Case for Bug Bounty Programs During Downtime
One of Podjarny’s more actionable suggestions during the pandemic period: launch a bug bounty program. With many developers working from home and looking for productive outlets, sign-ups to bug bounty communities increased noticeably. Podjarny noted that this kind of distributed, community-driven security testing aligns naturally with remote-first workflows.
The idea received broader industry support as well. Bugcrowd announced it would provide free, fully managed bug bounty programs — including attack surface analysis — to emergency response teams, hospitals, and other healthcare organizations responding to the pandemic. This illustrated a broader industry recognition that security capacity could be scaled through community programs at relatively low cost.
Snyk’s Approach: Continuous Security Integration
Snyk’s core product is built around the idea that security should happen during development, not after deployment. The platform helps developers identify vulnerable dependencies as they write code, leveraging a continuously updated database that monitors open source libraries and container images for newly disclosed vulnerabilities.
When vulnerabilities are found post-deployment, Snyk can also apply patches or suggest dependency upgrades. This dual capability — shift-left detection and post-deployment remediation — positions the tool as relevant across the full software development lifecycle (SDLC).
In response to the pandemic, Snyk offered its security services free for six months to organizations in industries hit hardest: healthcare, hospitality, travel, and entertainment.
How to Secure Code When the Dev Team Is Fully Remote
Podjarny outlined three core components for empowering remote developers to write secure code:
1. Document Best Practices and Decision Frameworks
It is not enough to publish a list of secure coding rules. Documentation should walk developers through the decision-making process: what questions to ask themselves as they make architectural and implementation choices, and what steps to take when they encounter an ambiguous situation. The goal is to make good security decisions the path of least resistance.
2. Use Supportive Tools, Not Enforcement Tools
Podjarny makes an important distinction between tools that block developers and tools that inform them. Rather than breaking the entire build when a security violation is detected, he advocates for failing pull requests instead — a targeted intervention that flags only the new changes in question. This approach preserves developer autonomy and keeps the feedback loop tight and actionable.
“Don’t break the build. But rather, surface it to developers. They need to play a role. It’s not just the security team that needs to change.”
— Guy Podjarny, Founder and President, Snyk
This philosophy reflects a broader DevSecOps principle: security tooling should feel like a helpful colleague, not a gatekeeper.
3. Invest in Security Visibility
Even well-intentioned teams make mistakes, and not every developer will have the same level of security awareness. Visibility tooling — instrumenting builds to capture dependency manifests, surfacing discovered vulnerabilities in the build output, and creating team-level dashboards or leaderboards that track how security issues are handled — creates accountability and encourages healthy competition around security hygiene.
Celebrating security achievements publicly within an organization reinforces the message that security is a shared engineering responsibility, not just a compliance checkbox.
Why This Accelerates DevSecOps Adoption
CI/CD pipelines had already been accelerating the pace of software delivery well before the pandemic. But as deployment velocity increased, security teams were frequently left out of the loop — reduced to naysayers who slowed releases down, rather than enablers who helped teams ship safely.
Podjarny argues that the pandemic forced a reckoning with this dysfunction. Organizations could no longer rely on proximity, informal hallway conversations, or the assumption that a centralized security team could review everything. The only scalable answer is DevSecOps: embedding security controls, tooling, and culture directly into the DevOps workflow.
“DevSecOps is about equipping teams that practice DevOps with the ability and empowerment to make security decisions,” Podjarny said. “It is fundamentally the right approach.”
Key Takeaways for DevOps Teams
- Centralized security control does not scale in a distributed, remote-first development environment. Accept this and plan accordingly.
- Shift security left by integrating vulnerability scanning into the IDE, version control, and CI pipeline — not just at the point of deployment.
- Fail pull requests, not builds, to keep developer feedback loops tight and maintain autonomy while enforcing security standards.
- Make security visible through dashboards, dependency audits, and team-level metrics. What gets measured gets managed.
- Consider a bug bounty program as a cost-effective way to augment internal security capacity, particularly when developer availability is high.
- Security documentation should be decision-oriented, not just rule-oriented. Help developers reason through security tradeoffs, not just memorize restrictions.
The pandemic did not create the problems that DevSecOps solves. It simply made them impossible to ignore.