Security and the FOSS Supply Chain

“…“widespread use of open-source software, with contributions from developers worldwide, presents a significant and ongoing challenge. The fact that the Department currently lacks visibility into the origins and security of software code hampers software security assurance.”

• From a DoD memo issued 24 April 2025

A memo on DoD procurement policies has sparked renewed concern regarding the security of Free and Open Source Software (FOSS) more broadly. This article will clarify the security differences between FOSS and commercial software, provide a practical framework for evaluating any software before deployment, and offer strategies for communicating your findings to non-technical stakeholders.

For non-technical leaders, unfamiliar acronyms and open-source dependencies can raise concerns or even lead to fear. Without clear visibility into how FOSS is maintained, audited, or supported, managers may assume the worst and block its use entirely. Whether you’re presenting a recommendation to your manager or challenging a vendor’s claims, this guide will help you do so with clarity, precision, and credibility.

All Software Has Vulnerabilities

As of this writing, Microsoft Windows 11 has over 1,900 known CVEs. It’s unrealistic to believe any open source operating system or distribution such as Ubuntu, Red Hat, or Debian is significantly more secure. Large codebases, regardless of license, will always contain flaws.

What separates secure software from insecure software is not the absence of bugs, but the speed and transparency with which those bugs are fixed. Well-maintained open source projects often release security patches within hours of a disclosure. Distributions like Ubuntu, Red Hat, and Debian maintain dedicated security teams and publish advisories and changelogs.

Commercial software may come with service-level agreements (SLA’s), but patch timelines are often shaped by legal, contractual, or reputational concerns. In some cases, vendors delay disclosure or patching to serve business priorities.

Not all open source projects are well maintained. Smaller or abandoned tools may go unpatched for months, just like legacy or neglected proprietary products. A project’s patch history says far more than its license. Ask how fast issues are resolved, whether fixes are public and verifiable, and whether active maintainers are involved.

Vulnerability counts alone do not define security. What matters is how consistently and effectively those vulnerabilities are managed.

How to Evaluate Risk Before Deployment

Before deploying any software, whether open source or commercial, engineers should follow a consistent evaluation process focused on real-world risk. The goal is not to check ideological boxes, but to understand how the software behaves, how it is maintained, and what risks it introduces.

Start by identifying who maintains the software. Is it backed by a vendor, a nonprofit foundation, or a single contributor? Look at the frequency and transparency of updates, especially around security issues. Are there public changelogs, advisories, and a history of timely patches? How is the development and long term support of the software funded?

Check whether the software supports auditing and monitoring. Can the source be reviewed directly or by a trusted third party? Can it integrate with your logging and observability stack?

Assess the support model. If the software fails in production, who do you call? If no external support exists, your team becomes responsible for diagnosing, fixing, and maintaining it. What looks like a cost-saving decision can quickly turn into a hidden labor cost and a long-term burden.

Analyze the supply chain. What dependencies does it include, and are they actively maintained? This includes external apps, libraries, frameworks, and tools used by your internal teams to support the application. Vulnerable components introduced during development can quietly create significant risk. Use Software Composition Analysis (SCA) to identify known vulnerabilities and licensing issues in all third-party code.

Consider the legal and geopolitical context. Understand the software’s license and whether it aligns with your compliance requirements. Just as important is where the software is developed. The legal system of that country may allow governments to compel changes, introduce surveillance, or suppress disclosures. Consider that country’s relationship with your own. Software from adversarial nations can carry hidden risks.

For example, the U.S. government banned Kaspersky antivirus in federal agencies, citing concerns that the Russian government could compel cooperation in espionage. But this risk is not limited to foreign vendors. In 2013, NSA documents leaked by Edward Snowden revealed a backdoor in Dual_EC_DRBG, a cryptographic algorithm standardized by NIST. This weakened global security, including for U.S.-developed systems.

Jurisdictional risk is about influence and authority, not just location. A powerful government can silently alter software. Knowing the software’s legal and political context is as important as knowing its version history.

Finally, evaluate operational fit. If software cannot be patched, logged, or controlled with your current tools, it is not secure, no matter who wrote it.

Communicating Risk to Managers

Evaluating software is only part of your job. Explaining your findings to management is often harder and more time-consuming than the evaluation was. Communicating risk effectively means turning detailed analysis into clear recommendations. That takes preparation and empathy, not just technical skill. This is a complex topic, and we will expand on it more in the near future.

Start by understanding what your audience cares about. Management is focused on uptime, liability, compliance, and cost. They are not thinking about dependency graphs. Say, “This project has no support, so failure could lead to longer outages and more internal labor,” instead of “The maintainers are inactive.”

Speak in terms of risk. Emphasize how likely something is to go wrong and how serious the consequences would be. Keep the technical depth appropriate to the context. “This vendor has a history of slow patching” says more than a deep dive into commit history.

Offer solutions, not just problems. Recommend actionable next steps. That could mean isolating a component, adding internal monitoring, or purchasing support. When possible, propose a preferred path forward with a clear rationale.

Be ready to counter vendor spin. Managers may repeat confident-sounding claims from sales pitches. Vendors often downplay risks, exaggerate compliance, or use vague phrases like “trusted by the government.” Stay calm. Ask for specifics. For example, “If they claim FIPS compliance, let’s verify which modules are certified and how they’re configured.”

Focus on facts, not opinions. A vendor saying their product is secure is not proof. Look for independent audits, public CVEs, changelogs, and measurable behavior. Quiet, well-sourced corrections are more effective than lectures.

Finally, document your work. A brief summary, risk matrix, or decision log can support your position even if it is overruled. If your advice is ignored and something goes wrong, a clear record of your evaluation protects both the system and your credibility.

Conclusion

There is no such thing as perfectly secure software. Whether open source or commercial, every product introduces risk. What matters is how those risks are evaluated, managed, and communicated.

Security engineers should focus less on ideology and more on evidence. A well-maintained open source project can outperform expensive proprietary tools, and strong commercial products may justify their cost. What matters is whether your choice is defensible based on facts.

With the right evaluation process and clear communication, you can make responsible, high-trust decisions. When you speak in the language of risk, impact, and accountability, you are not just securing systems. You are showing leadership.

**