State of Open Source in the Federal Government

State of Open Source in the Federal Government

Speakers: Jordan Kasper, Department of Homeland Security

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=S_Ly_eXY65k

Overview

Jordan Kasper's DEF CON talk, "State of Open Source in the Federal Government," delivers a candid and critical assessment of how U.S. federal agencies interact with open source software (OSS). Kasper, a seasoned open source contributor and former policy architect for both the Department of Defense (DoD) and Department of Homeland Security (DHS), offers a unique perspective from both inside and outside the government's digital walls. The talk dissects the persistent challenges, existing policies, and the stark realities of OSS adoption and contribution within the federal landscape, advocating for a transformative shift towards greater transparency, collaboration, and security.

This discussion is crucial for anyone interested in the intersection of government technology, cybersecurity, and the open source movement. Kasper meticulously outlines why the federal government, despite being one of the world's largest consumers of open source, falls short as a responsible ecosystem participant. He highlights the profound implications of this disconnect, ranging from significant security vulnerabilities to the squandering of taxpayer dollars and missed opportunities for innovation. The talk is a rallying cry for federal employees, contractors, and the broader open source community to collectively push for a more secure, efficient, and open government technology infrastructure.

Background

▶ Watch: Speaker introduction & federal open source policy background (0:00)

The journey of open source within the federal government is complex, marked by both progressive policy initiatives and entrenched cultural resistance. Jordan Kasper, drawing on his extensive experience, frames this landscape by first establishing the fundamental benefits of open source, which he argues are often lost in translation within government bureaucracy. These benefits include reusability, fostering collaboration and contribution, enhancing security through transparent code review, improving transparency in development processes, and ultimately offering a lower total cost of ownership (TCO) compared to proprietary solutions, despite not being "free." He cites a Harvard Business School study, co-authored by Frank Nagel, which estimated the global cost to rewrite existing open source software at an staggering $8.8 trillion, underscoring its indispensable value. Beyond economic and technical merits, Kasper emphasizes a philosophical point: software paid for by taxpayers should, wherever possible, be accessible to taxpayers, aligning with the principle of "software for the people."

However, this vision faces significant hurdles, rooted in deeply held perceptions and systemic issues within the federal government. Kasper articulates these challenges through direct quotes he's encountered:

• "Open source software is insecure." This pervasive belief often stems from a misconception that lack of direct control over development equates to insecurity, despite the "many eyes" principle often making open source more robust.
• "It's illegal." This concern arises from misunderstandings of open source licenses and intellectual property rights (IPR), particularly regarding contractor-developed software. While contractors often retain copyright, federal contracts typically grant full data rights allowing the government to modify and publicly share the software, a point often overlooked.
• "We paid for it. It's ours." This sentiment reflects a proprietary mindset, ignoring that taxpayer funds, not agency budgets, ultimately finance these projects, making them public assets.
• Lack of technical knowledge: A historical "brain drain" of computer science talent from the federal government since the 1970s has led to an over-reliance on contractors. This deficit means government personnel often lack the expertise to properly evaluate, select, or manage open source components, leading to issues like stagnant, unmaintained dependencies.
• Stagnation: Both personnel and software suffer from stagnation. Government employees often don't engage with the broader technical community, leading to outdated knowledge. Software, once developed, is frequently walled off and left to decay without updates or community interaction.

Against this backdrop, several key policies and laws have attempted to steer the federal government towards greater open source adoption. The Federal Source Code Policy (M1621), issued in 2016 during the Obama administration, was a landmark memo. It mandated a pilot program to release 20% of government-funded custom-developed code as open source, though the ambiguity of "20% of what" rendered this target largely unmet. More significantly, M1621 promoted participation in the open source community, advocated for better open development practices, and formalized the requirement for data rights clauses in IT contracts to enable public sharing. It also established a government-wide code inventory, requiring agencies to list custom-developed software on their domains (e.g., dhs.gov/code.json), and created code.gov as a hub for inter-agency collaboration, though code.gov has since fizzled out, its resources now consolidated under digital.gov.

Further solidifying these principles, the Share It Act, passed into law, codified many elements of M1621. This legislative action is critical because, unlike an executive memo, a law cannot be unilaterally rescinded by future administrations, providing a more stable foundation for open source initiatives. Most recently, Executive Order 14144 (EO14144), "Strengthening and Promoting Innovation in the Nation's Cybersecurity," issued in January 2025 (Kasper notes it's a Biden-era order, still in place, with edits making it 2C), directs the Cybersecurity and Infrastructure Security Agency (CISA) to develop best practices for contributing to open source software projects. This mandate signals a growing recognition at the highest levels of government that active contribution is vital for national cybersecurity.

Key Findings

▶ Watch: The constant argument for open source in federal government (2:30)

Kasper's talk reveals several critical findings about the federal government's engagement with open source:

Firstly, despite internal resistance, open source is actively being published by the federal government. The speaker points to government.github.com/community, which lists 164 U.S. federal agencies or agency organizations with public GitHub presence. This demonstrates that publishing open source is not only feasible but already happening on a significant scale. Notable examples include SE Linux, developed by the National Security Agency and open-sourced in 2000; the US Web Design System, a GSA-led initiative mandated for new federal websites and fully open source; Open MCT by NASA, a mission control framework; and the recent IRS Direct File system, which is 100% open source, including its code, infrastructure, documentation, and design artifacts. These examples showcase the breadth and depth of government open source initiatives when successfully implemented.

Secondly, a stark contrast exists between the government's role as a consumer versus a contributor. Kasper asserts that the U.S. government is likely the largest consumer of open source software globally, with hundreds of thousands of IT systems relying on it. However, he argues it is simultaneously the worst consumer due to a severe lack of contribution. This includes failing to file bug reports or security issues, and neglecting regular updates. This imbalance creates a parasitic relationship where the government benefits immensely from the open source ecosystem without adequately investing back into its health and security.

Thirdly, the processes for consuming open source within federal agencies are fundamentally broken and insecure. Kasper highlights several critical deficiencies:

• Poor Selection Process: Instead of evaluating factors like release cadence, documentation quality, testing practices, or continuous integration (CI) pipelines, agencies often select open source libraries based solely on whether they "do the thing we want," often leaving this critical decision to contractors without proper oversight.
• Ineffective Scanning: While systems are scanned for vulnerabilities, network operation centers primarily look for binaries or packages, often missing vulnerabilities embedded within open source code libraries pulled into custom applications.
• Manual and Infrequent Updates: Dependency updates are almost always manual, lacking automation for flagging new versions (like Dependabot) or checking for breaking changes, license alterations (e.g., the React license change incident), or new bugs. This leads to severe software supply chain security risks from outdated components.
• Zero Upstream Contribution: This is identified as a "complete and utter fail." Even when contractors identify bugs or security flaws in critical open source libraries, fixes are typically kept behind agency firewalls rather than contributed back upstream. This is partly due to contracts not explicitly funding such contributions and the "we paid for it, it's ours" mentality. This practice deprives the broader open source community (and by extension, other government agencies) of crucial improvements and security patches.

Finally, while policies like M1621, the Share It Act, and EO14144 lay a legal and strategic foundation, their implementation and enforcement remain weak. The 20% open source pilot failed due to lack of clarity, the code.json inventories are largely incomplete, and CISA's best practices for contribution are still pending. This gap between policy aspiration and operational reality is a recurring theme, hindering meaningful progress.

Technical Deep Dive

▶ Watch: Core benefits: reusability, collaboration, security, transparency (3:20)

While Jordan Kasper's talk focuses heavily on policy and cultural aspects, it implicitly highlights several areas ripe for technical improvement within federal government software development and procurement. The underlying technical challenges stem from a lack of modern software supply chain security practices and an absence of open development methodologies.

The current state reveals a significant gap in the robust technical management of open source dependencies. Agencies, often relying on contractors, frequently adopt open source components without rigorous technical evaluation. A proper open source selection baseline would involve technical criteria such as:

• Release Cadence: Assessing the frequency of new releases to ensure active maintenance and responsiveness to bugs and security issues. Kasper explicitly states, "If you haven't done a release in three years, I'm not going to let you use that open source software."
• Testing and Quality Assurance: Verifying the presence of unit tests, integration tests, and a continuous integration (CI) pipeline to demonstrate code quality and stability.
• Security Scans: Requiring evidence of automated security scanning (e.g., SAST, DAST) within the project's development pipeline.
• Documentation: Evaluating the clarity and completeness of technical documentation for developers.

A critical technical deficiency is the lack of automated open source scanning and approval processes. Current practices are often manual, requiring human review by Information Security Managers (ISMs) who may lack the deep technical expertise to assess a library's suitability. This bottleneck not only slows down development but introduces human error and inconsistency. Implementing automated tools for Software Composition Analysis (SCA) that can identify open source components, their licenses, and known vulnerabilities (e.g., CVEs) would be a significant technical leap. These tools should integrate directly into CI/CD pipelines, automatically flagging issues and potentially automating parts of the approval workflow based on predefined security policies.

Another major technical vulnerability lies in how federal systems consume external packages. Kasper points out that agencies "pull from Pi. We pull from npm. We pull from Maven straight in. It's totally fine, right? What could possibly go wrong?" This direct consumption from public repositories exposes federal systems to dependency confusion attacks, typosquatting, and other supply chain compromises. The technical solution is to implement package mirrors or proxies (e.g., Nexus Repository Manager, Artifactory) that cache approved versions of open source dependencies. This not only provides an air-gapped layer of security but also ensures consistency and availability of specific versions, preventing unexpected changes or removals of upstream packages.

The concept of government-wide code reuse also has strong technical implications. Kasper advocates for building more modular systems rather than monolithic applications. This involves designing software as discrete, reusable components that can be shared across agencies. Technically, this means adopting microservices architectures, well-defined APIs, and containerization (e.g., Docker, Kubernetes) to facilitate independent deployment and reuse. Such modularity also inherently supports open sourcing individual components, making them easier to manage, secure, and contribute back to.

Furthermore, Kasper stresses the need to enforce secure coding practices, specifically mentioning the NIST Secure Software Development Framework (SSDF). The SSDF provides a comprehensive set of guidelines for integrating security across the entire Software Development Life Cycle (SDLC). Technically, this involves:

• Threat modeling early in development.
• Using static application security testing (SAST) and dynamic application security testing (DAST) tools.
• Implementing security gates in CI/CD pipelines.
• Conducting regular code reviews focused on security.
• Ensuring proper dependency management and vulnerability patching.

Finally, the speaker's vision of contractors delivering projects via GitHub URLs implies a shift towards Infrastructure as Code (IaC) and fully transparent, auditable development. This means not just the application code but also configuration files, deployment scripts, CI/CD pipeline definitions (e.g., GitHub Actions workflows), and all other build artifacts should reside in a public repository. This technical approach enables complete reproducibility, simplifies auditing, and fosters community engagement.

Demo / Proof of Concept

▶ Watch: Open source is not free: cost of ownership & investment (5:00)

The talk did not include a live technical demonstration or a detailed proof of concept of a specific exploit or tool. Jordan Kasper mentioned that his slides contained funny memes and a wealth of links, including examples of government open source projects and policy documents.

However, a practical artifact mentioned and demonstrated on the slides (and accessible live) is the code.json inventory file. Kasper specifically points to dhs.gov/code.json as an example of an agency's public inventory of custom-developed software, as mandated by the Federal Source Code Policy (M1621) and the Share It Act. This JSON file serves as a machine-readable catalog of software projects, including metadata such as title, description, repository URL, and license. While not a "demo" in the traditional sense, it represents a concrete, technical implementation of a policy requirement aimed at transparency and discoverability of government-developed code. The speaker notes that while the concept is sound, the completeness of these inventories across agencies often leaves much to be desired.

Defensive Implications

▶ Watch: Harvard study: $8.8 trillion value of open source (6:15)

The insights from Jordan Kasper's talk offer critical defensive implications for federal agencies, contractors, and even private citizens aiming to bolster the security posture of government systems.

For Federal Agencies:

1. Establish Robust Open Source Selection Criteria: Agencies must move beyond superficial evaluations. Implement a formal process with clear technical criteria for selecting open source components, focusing on active maintenance (e.g., recent releases within 12-18 months), strong documentation, comprehensive test suites, and evidence of secure development practices (e.g., CI/CD with security scanning).
2. Automate Open Source Scanning and Approval: Integrate Software Composition Analysis (SCA) tools into every CI/CD pipeline. These tools should automatically identify all open source dependencies, flag known vulnerabilities (CVEs), check license compliance, and provide a risk score. This automation streamlines the approval process, reducing reliance on manual, often unqualified, reviews.
3. Implement Package Mirrors: To mitigate supply chain risks like dependency confusion or malicious package injection, agencies should deploy and enforce the use of internal package mirrors (e.g., for npm, PyPI, Maven). These mirrors should be tightly controlled, caching only approved versions of dependencies and potentially scanning them before ingestion.
4. Define Clear Update Cadence and Triggers: Establish explicit policies for updating open source dependencies. This includes regular scheduled updates (e.g., quarterly, monthly) and immediate updates for critical security patches. Automation tools (like Dependabot or commercial equivalents) should be used to monitor for new versions and vulnerabilities, triggering alerts or automated pull requests.
5. Enforce NIST Secure Software Development Framework (SSDF): Mandate and actively audit contractor adherence to the NIST SSDF. This framework provides a holistic approach to security throughout the software lifecycle, from design to deployment and maintenance, ensuring security is "built-in," not "bolted-on."
6. Actively Participate in Open Source Communities: Beyond consumption, agencies should encourage and fund employees to participate in upstream projects. This includes submitting bug reports, feature requests, and security vulnerabilities, as well as engaging in foundations like Apache or Linux Foundation. This fosters a healthier ecosystem that directly benefits government systems.
7. Prioritize Modular Systems for Reuse: Encourage the development of software as modular, reusable components. This not only aids government-wide code reuse but also simplifies the security auditing and maintenance of individual components, making them easier to open source and contribute.

For Federal Contractors:

1. Elevate Open Source Practices: Contractors must move beyond simply pulling in libraries. They should proactively follow the NIST SSDF, integrate automated security scanning, and propose robust dependency management strategies to their government clients.
2. Deliver Projects as Open Source by Default: Where appropriate, contractors should propose and deliver projects with an "open by default" mindset. This includes submitting all code, infrastructure-as-code, and CI/CD pipelines to public GitHub repositories as a core deliverable, as Kasper successfully implemented at DoD. This transparency can significantly enhance security through community scrutiny.
3. Contractual Obligation for Upstream Contribution: Contractors should be contractually required to contribute all security fixes (and ideally bugs and enhancements) for open source libraries back to their upstream projects. This shifts the financial burden and responsibility to the contractor while profoundly benefiting the entire open source ecosystem. Kasper suggests this could inject potentially 500,000 new developers as contributors.

For Private Individuals / Security Researchers:

1. Discover and Promote Government Open Source: Explore resources like government.github.com/community to find federal, state, and local government open source projects. Promote well-maintained projects and, if skilled, contribute fixes or enhancements.
2. Participate in Bug Bounty Programs: The federal government is increasingly embracing Vulnerability Disclosure Programs (VDPs) and bug bounty programs. Researchers can visit platforms like bugcrowd.com/engagements/featured/cisa or HackerOne to find active bounties on federal systems. This provides a legitimate and compensated avenue for ethical hackers to identify and report vulnerabilities, directly enhancing government cybersecurity.

Key Takeaways

• Massive Consumer, Poor Contributor: The federal government is arguably the world's largest consumer of open source software but acts as one of its worst contributors, failing to report bugs, submit security fixes, or maintain timely updates, creating significant security liabilities.
• Policy Exists, Enforcement Lags: While foundational policies like M1621, the Share It Act, and EO14144 advocate for open source adoption and contribution, their implementation, enforcement, and clarity remain insufficient, leading to a gap between aspiration and reality.
• Cultural and Technical Hurdles: Deep-seated cultural resistance (e.g., "open source is insecure," "we paid for it, it's ours") and a critical lack of technical expertise within the federal workforce continue to impede effective open source consumption and contribution.
• Automation is Critical for Security: The absence of automated processes for open source selection, security scanning, and dependency updates introduces severe software supply chain risks. Implementing robust, automated solutions for these tasks is paramount.
• Mandatory Upstream Contribution: A transformative step would be to contractually require federal contractors to contribute all security fixes, and ideally other improvements, back to the upstream open source projects they utilize. This would dramatically bolster the security and health of the global open source ecosystem.
• Active Participation and Funding: For a truly secure and innovative future, the federal government must become an active participant in open source communities and consider directly funding open source projects and foundations, mirroring initiatives like Germany's Sovereign Tech Fund.

About the Speaker(s)

Jordan Kasper is a highly experienced open source contributor and maintainer, with active involvement in the open source community dating back to 2008, including early contributions to the jQuery project. His unique perspective stems from a career that bridges deep technical expertise with high-level federal policy development.

Kasper served the Department of Defense (DoD) through the US Digital Service, where he was instrumental in drafting the DoD's open source policy, which was officially signed out in 2022. Subsequently, he joined the Department of Homeland Security (DHS), where he authored the current DHS open source policy (142-04), signed in 2023, and developed further open source guidance that is awaiting publication. At the time of this talk, he was transitioning from his role at DHS, emphasizing that the opinions expressed were his own and not necessarily those of his current or former employers. Jordan Kasper is known online as J A K R E L L A and can be found at jordanasper.com/oss-in-gov.