Open Source Is In Your Software, Whether You Track It or Not
Nearly every modern project consumes open source components—99 percent, according to recent industry data. Those dependencies speed development, but they also inherit risk: open source-related breaches have risen 71 percent over the past five years. The first step in protecting your organization is simply knowing what’s in your inventory and where the risk concentrates.
That visibility is not just a compliance exercise. With community knowledge and automated tooling, you can detect issues before they become incidents and push fixes without grinding development to a halt. Rob Fletcher, head of application security at Uber, describes the effect in concrete terms: their vulnerability management strategy treats automated scanning as a “force multiplier” for manual findings. In one instance, that combination surfaced 11 true variants of a single bug, yielding significant cost savings.
There is also value in opening parts of your codebase to outside scrutiny. Publicly visible projects draw attention from developers who will report problems you might never see internally. Arduino’s CISO, Gianluca Varisco, notes that simply being open source on GitHub means developers contact them directly with bugs.
Keep Security Feedback Inside the Developer Workflow
Your own custom code needs the same scrutiny as your dependencies, but traditional security tools bolted on after the fact create friction and manual overhead. The workaround is not to skip security—it’s to bring it into the environment where developers already work.
Keith Hoodlet, application security manager at Thermo Fisher, says this integration matters because it lets engineers focus on issues in code they actually wrote. The individuals who know how the code is intended to function are the ones empowered to address security and quality issues. Feedback delivered early and in context avoids the larger disruptions that surface closer to release.
That early context also changes who owns security. “Security is just as much the responsibility of the developers as it is of the security team,” says James Hurley, director of developer services at McKesson. The sooner vulnerabilities are caught, he argues, the better for the company in the long run—for cost and for product quality.
Govern the Full Lifecycle, Not Just the Code
Individual fixes matter, but a project is only as secure as the lifecycle that produces it. Organization-wide visibility, customizable governance, and enforced policies allow you to manage application security without slowing the business.
Dow Jones CISO Miguel El Lakkis describes the goal as baking security controls into the pipeline “all the way from the first line of code you’re writing.” When policies are established and enforced at every stage, development teams can trust that the software they ship was built under consistent security rules—without needing a separate audit step at the end.
Securing the world’s code is not a single-vendor problem. It combines community knowledge, partner technology, and automation. In practice, that means three concrete commitments: know and secure your supply chain, place security tools inside the developer workflow, and enforce policies across the entire software development lifecycle.
