Open Source Hacker V. Government Lawyer

Open Source Hacker V. Government Lawyer

Speakers: Rebecca Lively, Government Attorney (formerly); Eddie Zaneski, Staff Engineer, Defense Unicorns

Conference: DEF CON 32

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

Overview

"Open Source Hacker V. Government Lawyer" delves into the often-conflicting worlds of rapid open-source development and the stringent security and compliance requirements of the United States Department of Defense (DoD). Presented by Eddie Zaneski, an open-source staff engineer and Kubernetes maintainer, and Rebecca Lively, a former government attorney, the talk offers a unique, dual perspective on the challenges of integrating modern technological practices within a highly regulated environment. The genesis of this discussion stems from their shared experience at a Bravo 3 collaborative software development event, a hackathon designed to bring civilian talent onto a military base to work with sensitive government data.

The core of the talk highlights the profound disconnect between the "hacker" ethos—defined here as building innovative solutions and subverting inefficient rules—and the government's deeply ingrained priorities of compliance and scale. This clash manifests in practical, often frustrating, impediments to development, forcing engineers to resort to "illegal, unethical, and very bad security practices" to simply get their jobs done. By dissecting these competing priorities, Zaneski and Lively provide a compelling narrative on why the DoD struggles to adopt cutting-edge technology and how these challenges inadvertently create new security vulnerabilities.

This presentation is particularly relevant for anyone involved in government technology, cybersecurity policy, or open-source initiatives within highly regulated sectors. It underscores the critical need for a more nuanced understanding of developer workflows and the practical implications of security mandates. The speakers, both now working at Defense Unicorns to bridge this very gap, argue for a collaborative approach that balances the imperative of national security with the agility and innovation inherent in the open-source community, ultimately aiming to equip the military with more effective and secure software.

Background

▶ Watch: Introduction: Hacker vs. Government Lawyer (0:00)

The foundational context for this talk is the Bravo 3 collaborative software development event, a hackathon designed to invite uncleared civilians, like Eddie Zaneski, onto a military base to work with controlled and classified data. This event, organized by Stewart and his team, aimed to leverage external talent for government projects. However, the operational environment established for these developers inadvertently became a stark illustration of the friction between civilian development practices and DoD security protocols.

Upon arrival, civilian participants were met with immediate and pervasive restrictions that severely hampered their ability to perform basic development tasks. Eddie recounts attempting to bring his personal laptop, only to be told it was forbidden. This was followed by the prohibition of USB devices, including his YubiKey for secure authentication to platforms like GitHub. Crucially, access to GitHub itself, a cornerstone for open-source collaboration and version control, was denied. The environment further lacked internet connectivity, an essential resource for modern software development, preventing access to documentation, package managers, and external libraries.

The provided development environment, while ostensibly equipped with tools, was functionally crippled. Participants were given VS Code, a popular integrated development environment, but it was notably installed "without any of the language plugins." Rebecca Lively, with a touch of humor and a nod to the government mindset, remarked, "And to be clear, I'm not sure why you would need language plugins. This is America and we speak English." This statement, while facetious, perfectly encapsulates the cultural and operational chasm: the government provided a tool, but without understanding the fundamental requirements for its effective use in a modern development context.

Faced with these severe limitations, the developers, true to the "hacker" spirit—defined by Zaneski as "building cool shit, subverting the rules, doing that type of stuff"—resorted to unconventional and insecure workarounds. Eddie describes going "out to the car and tethered from our phones to get anything done at all." Rebecca, from her former government attorney perspective, immediately identified this as "both probably illegal, definitely unethical, and a very bad security practice." This incident became a microcosm of the larger problem: security policies, when overly restrictive and impractical, can drive individuals to circumvent them in ways that introduce greater risk than the policies were intended to prevent.

The speakers frame their entire talk around "six questions that Eddie asked me over the last three months," all stemming from his initial bewilderment ("why the fuck are we doing this, Rebecca?") at the government's operational methods. Rebecca, drawing on her "13 years of Stockholm syndrome" in government service, found herself providing explanations rooted in deeply ingrained institutional priorities. This ongoing dialogue led them to realize that the "root of all of it is just competing priorities within like the hacker community and the government community." The talk, therefore, is an exploration of these fundamental differences, using the Bravo 3 hackathon as a vivid, real-world case study of the challenges inherent in merging agile innovation with rigorous governmental oversight.

Key Findings

▶ Watch: Humorous clash: 'America, we speak English' on plugins (2:00)

The central revelation of this talk is the profound and often counterproductive clash of competing priorities between the open-source hacker community and the U.S. government, particularly within the Department of Defense. This conflict is not merely a difference in preference but a systemic issue that impedes technological progress and inadvertently introduces security vulnerabilities.

The speakers identify two paramount government priorities that frequently override other considerations:

1. Compliance: Rebecca Lively emphasizes that compliance is about "checking the box and validating that you meet all of the various requirements from all of the various different parts of government and law." In the DoD context, this involves a labyrinthine array of regulations, standards, and directives, including those from NIST (National Institute of Standards and Technology), DISA (Defense Information Systems Agency), and various military branches. The focus is on adhering strictly to established rules, often regardless of their practical impact on innovation or efficiency. This box-ticking mentality prioritizes auditability and legal defensibility over agile development. For instance, the prohibition of USBs or external internet access, while seemingly blunt, directly addresses specific compliance requirements related to data exfiltration and unauthorized software introduction, even if it cripples developer productivity. The government, being a complex entity, is described as "not a monolith that acts completely deliberately and with one singular direction and intention," meaning compliance requirements can vary and even contradict across different agencies or departments, further complicating matters.

1. Scale: Any new technological idea or experimental project within the government is immediately evaluated through the lens of enterprise-wide deployment. Rebecca recounts that whenever she proposed a small-scale experiment, like "string[ing] a couple Raspberry Pis together and try this thing," the immediate leadership response was, "Okay, but do you think that would scale across the entire Department of the Air Force?" This demand for immediate, vast scalability stifles small-scale prototyping, experimentation, and iterative development—methodologies crucial for modern software innovation. A $32 proof-of-concept is dismissed if it cannot be envisioned as a solution for hundreds of thousands of users or across an entire branch of service. This priority reflects the immense logistical, financial, and training overhead associated with deploying technology across a global military organization, but it effectively acts as a barrier to entry for novel solutions that require initial smaller-scale validation.

In contrast to these explicit government priorities, the talk implicitly highlights the priorities of the hacker/developer community, which were demonstrably frustrated at the Bravo 3 hackathon:

• Agility and Experimentation: The desire to quickly "try this thing" with minimal overhead, using readily available and inexpensive tools (like Raspberry Pis), is fundamental to iterative development and innovation.
• Access to Modern Tools and Resources: Developers expect functional IDEs (VS Code with language plugins), reliable internet access for dependencies and documentation, and collaborative platforms like GitHub for version control and community engagement.
• Productivity and Efficiency: The ability to get work done efficiently, without unnecessary bureaucratic hurdles or technical impediments that force insecure workarounds.

The key finding is that the government's emphasis on compliance and scale, while understandable from a risk management and operational perspective, creates an environment antithetical to modern software development practices. This disconnect leads directly to inefficiencies, developer frustration, and, critically, the adoption of insecure workarounds (like phone tethering) that undermine the very security posture the policies aim to uphold. The talk effectively demonstrates that without a conscious effort to bridge these priority gaps, the DoD will continue to struggle in leveraging cutting-edge technology and attracting top-tier civilian talent.

Technical Deep Dive

▶ Watch: Origin of talk: 'Why the fuck are we doing this?' (3:30)

The talk, while not presenting a specific technical solution, offers a critical "deep dive" into the technical impediments faced by developers within highly secure government environments. It meticulously illustrates how well-intentioned security policies can inadvertently create an anti-technical environment, hindering modern development practices and potentially leading to less secure outcomes.

The primary technical challenges highlighted during the Bravo 3 hackathon were:

1. Lack of Internet Access: This is perhaps the most fundamental technical barrier. Modern software development is inherently connected.

• Dependency Management: Without internet, developers cannot pull external libraries, frameworks, or packages (e.g., from npm, PyPI, Maven Central, Docker Hub). This effectively freezes the technology stack at whatever was pre-installed, preventing updates, new feature integration, or even basic project setup for many contemporary applications. Eddie Zaneski, as a maintainer for the Kubernetes project, operates in an ecosystem heavily reliant on dynamic package management and continuous updates. An air-gapped environment makes such work nearly impossible.
• Documentation and Support: Developers constantly refer to online documentation, Stack Overflow, and community forums for problem-solving and learning. The absence of internet access isolates them from this collective knowledge base, significantly slowing down development and increasing the likelihood of errors or suboptimal solutions.
• Continuous Integration/Continuous Delivery (CI/CD): Modern DevOps pipelines are built on internet-accessible services for code repositories, automated testing platforms, and deployment targets. Without connectivity, these essential practices are severed, reverting development to a much slower, manual, and error-prone process.

1. Prohibition of GitHub and Open-Source Software Access: For an "open-source hacker" like Eddie, GitHub is the central hub for collaboration, version control, and project management.

• Version Control Systems (VCS): While local Git repositories can function offline, the ability to push, pull, fork, and collaborate on remote repositories is critical. Denying GitHub access prevents developers from leveraging the vast existing open-source ecosystem, contributing back to it, or even securely managing their own project's history in a shared, auditable manner.
• Community and Innovation: Open-source projects thrive on community contributions and transparency. By isolating developers from platforms like GitHub, the government not only prevents them from participating but also from benefiting from the rapid innovation, peer review, and security vetting that occurs within these communities. This creates a technical debt where the government must re-invent or re-secure solutions that already exist and are maintained by a global community.

1. Limited Integrated Development Environment (IDE) Functionality: The provision of VS Code "without any of the language plugins" exemplifies a profound misunderstanding of developer needs.

• Language-Specific Features: Plugins provide essential functionalities like syntax highlighting, intelligent code completion (IntelliSense), debugging tools, linters, formatters, and refactoring capabilities for specific programming languages (e.g., Python, JavaScript, Go, Rust). Without these, VS Code essentially becomes a sophisticated text editor, drastically reducing developer productivity, increasing cognitive load, and making code quality harder to maintain. Rebecca's quip about "America and we speak English" highlights the cultural gap: the technical team providing the tool likely didn't grasp that "English" in coding means language-specific tooling, not just generic text.
• Tooling Ecosystem: Modern IDEs are extensible platforms. The lack of plugins means developers cannot integrate other essential tools for testing, containerization (e.g., Docker extensions), cloud interaction, or specialized security analysis directly within their primary workspace.

1. Prohibition of USB Devices (e.g., YubiKey): While a common security measure to prevent data exfiltration or malware introduction, the blanket ban on USBs ignores modern secure authentication methods.

• Secure Authentication: Devices like YubiKey are hardware-backed security keys used for multi-factor authentication (MFA), often integrating with services like GitHub or corporate identity providers. Prohibiting them forces reliance on less secure authentication methods or completely prevents access to secure external resources, creating a dilemma between security and usability.

The overall technical implication is that these restrictions, while intended to create a secure, isolated environment, instead create a highly inefficient and frustrating one. Developers are forced to operate with outdated methods, limited tools, and a crippled workflow. The "tethering from our phones" incident is a stark technical consequence: it demonstrates how a lack of functional, secure pathways for necessary tasks will lead to the creation of insecure, unmonitored pathways. From a technical perspective, this means bypassing corporate networks, potentially exposing sensitive data over personal mobile connections, and introducing unvetted devices into a secure perimeter – precisely what the initial policies aimed to prevent. This "deep dive" reveals a critical need for security policies to be technically informed and integrated with practical development requirements, rather than acting as blanket prohibitions.

Demo / Proof of Concept

▶ Watch: Defining 'Hacker' and talk structure (competing priorities) (4:15)

This particular talk did not feature a traditional technical demonstration or a live proof of concept in the conventional sense of showcasing a new exploit or defensive tool. The speakers did not present any code, system, or attack vector.

However, the entire narrative of the talk serves as a powerful, albeit inverse, "proof of concept" regarding the efficacy of current government security practices for software development. The Bravo 3 hackathon experience itself functions as an experiential demonstration of how not to enable effective technological innovation within a secure environment. The detailed recount of the hackathon's restrictive setup—no personal laptops, no USBs, no GitHub, no internet, and a crippled VS Code installation—effectively demonstrates the critical flaws in an overly cautious, compliance-driven approach that neglects developer needs.

The most poignant "proof of concept" within the talk is the developers' collective decision to "go out to the car and tethered from our phones to get anything done at all." This action serves as an impromptu, real-world proof of concept of security circumvention. It starkly illustrates how human ingenuity, when faced with impractical and suffocating restrictions, will find ways to bypass them. This act, described by Rebecca as "probably illegal, definitely unethical, and a very bad security practice," inadvertently proves that:

1. Overly restrictive security can be counterproductive: Instead of enhancing security, it can drive developers to create shadow IT solutions outside the controlled environment.
2. The perceived "secure" environment is porous: If developers can bypass the air-gap with personal devices, the integrity of the isolated network is compromised.
3. Risk is merely shifted, not eliminated: The risk of data exfiltration or malware introduction is not removed by blanket bans; it is merely transferred to unmonitored and unsecured personal devices and networks.

Therefore, while no formal demo was presented, the talk's narrative structure and the explicit recounting of the hackathon's challenges and the subsequent workarounds serve as a compelling, cautionary "proof of concept" for the real-world implications of the hacker-versus-government-lawyer paradigm.

Defensive Implications

▶ Watch: Government's competing priorities: compliance and scale (5:00)

The clash between open-source hackers and government lawyers, as articulated in this talk, carries significant defensive implications for the Department of Defense and any organization operating under similar stringent security mandates. The core takeaway is that overly restrictive security policies, while well-intentioned, can inadvertently create new and potentially greater security risks by fostering an environment of circumvention.

1. Creation of Shadow IT and Unsanctioned Workflows: The most direct defensive implication is the emergence of shadow IT. When developers are denied essential tools and connectivity (internet, GitHub, functional IDEs), they will find ways to circumvent these restrictions to accomplish their mission. The example of "tethering from our phones" is a prime illustration. This creates unmonitored and unsecured channels for data transfer, code access, and communication, completely bypassing official security controls. Defenders lose visibility and control over sensitive data and intellectual property, making it impossible to detect or prevent exfiltration, malware introduction, or unauthorized access.

1. Increased Insider Threat Vectors: By forcing developers to use personal devices and untrusted networks, the organization effectively increases its insider threat surface. A developer using their personal phone to access project code in a car is not subject to the same monitoring, scanning, or policy enforcement as they would be within a controlled environment. This opens avenues for accidental data leaks, exposure to public Wi-Fi risks, or even deliberate malicious actions that would be harder to trace.

1. Compromised Security through Inefficient Development: A development environment that stifles productivity also impacts security. When developers are forced to manually manage dependencies, work without proper tooling, or operate in isolation, the quality and security of the code they produce can suffer. Bugs, vulnerabilities, and insecure configurations are more likely to be introduced when developers are stressed, frustrated, and lacking the necessary resources (like up-to-date libraries or static analysis tools). The inability to quickly patch vulnerabilities or integrate security updates due to a lack of internet or access to modern CI/CD pipelines further exacerbates this issue.

1. Erosion of Trust and Morale: From a defensive posture, security is not just about technology; it's also about people. Policies that alienate and frustrate technical talent can lead to a breakdown of trust between security teams and developers. This can result in developers becoming less cooperative with security mandates, viewing them as obstacles rather than enablers. A demoralized workforce is less vigilant and less invested in upholding security best practices.

Recommendations for Defenders:

• Embrace Developer-Friendly Security: Instead of blanket prohibitions, security teams must work collaboratively with developers to implement enabling security controls. This involves understanding developer workflows and providing secure, sanctioned alternatives. For example, rather than "no internet," provide controlled internet access through whitelisted proxies or secure virtual desktops for specific development tasks.
• Implement Risk-Based Security, Not Zero-Tolerance: Acknowledge that some level of risk is inherent in any system. Conduct thorough risk assessments to understand the actual threat landscape and implement proportionate controls. Instead of "no USBs," consider secure USB scanning stations, whitelisting specific, encrypted devices, or enforcing strict data transfer protocols.
• Invest in Secure Development Environments (SDEs): Create dedicated, secure development environments that offer the necessary tools and connectivity while maintaining strict security. This might involve secure internal package repositories, mirrored GitHub instances, or cloud-native development platforms with robust access controls and monitoring.
• Foster Communication and Education: Bridge the cultural gap between "government lawyers" (policy/compliance) and "open-source hackers" (developers). Educate developers on the why behind security policies and involve them in the design of secure solutions. Conversely, security and legal teams need to understand the practical necessities of modern software development.
• Leverage Open Source Securely: Recognize that open-source software, while requiring careful vetting, also offers significant security benefits through transparency, community review, and rapid patching. Develop policies for secure consumption and contribution to open-source projects, perhaps via internal, air-gapped mirrors and review processes.

Ultimately, effective defense in the modern era requires a shift from a purely prohibitive mindset to one that strategically enables secure innovation. The talk serves as a stark warning that ignoring the practical needs of developers will lead to unintended security consequences.

Key Takeaways

• Overly restrictive security policies can be counterproductive: Policies intended to enhance security, such as blanket bans on internet, GitHub, or USBs, often backfire by forcing developers to find insecure workarounds (like phone tethering), thereby creating new, unmonitored vulnerabilities.
• Government priorities (compliance and scale) frequently clash with developer needs: The DoD's intense focus on "checking the box" for compliance and demanding immediate, vast scalability for any new idea fundamentally impedes the agile, experimental, and tool-rich development practices common in the open-source community.
• Functional development environments are critical for security: Providing tools like VS Code without essential language plugins or internet access renders them largely useless, hampering productivity and code quality, which can indirectly lead to more insecure software.
• Prototyping and experimentation are stifled by scale demands: The expectation that even small, inexpensive proof-of-concept projects must immediately demonstrate enterprise-wide scalability prevents crucial early-stage innovation and learning.
• Bridging the cultural and operational gap is essential: Effective technological advancement within the government requires a deeper understanding and empathy between legal/security professionals and developers, fostering collaboration to balance security mandates with practical development needs.
• Defense Unicorns aims to solve this problem: The speakers' company is actively working to integrate open-source methodologies and private sector talent into the US military, demonstrating a commitment to finding practical solutions to these long-standing challenges.

About the Speaker(s)

Rebecca Lively is a former government attorney with an extensive background in the legal and policy landscape of federal service. She spent "13 years" within the government, gaining a deep understanding of the complex compliance requirements and institutional priorities that often dictate technological adoption. Approximately four years prior to this talk, she ceased practicing law, emphasizing that this was by choice and not due to disbarment. Currently, Rebecca applies her unique perspective on government operations and legal frameworks as part of Defense Unicorns, a company dedicated to building open-source software for the US military. Her role involves translating government needs and restrictions into actionable insights for modern development teams.

Eddie Zaneski is an "open source hacker" and a staff engineer at Defense Unicorns. He brings a wealth of experience from the open-source community, notably as a maintainer for the Kubernetes project, a leading platform for container orchestration. Eddie embodies the agile, innovation-driven ethos of the hacker community, focused on "building cool shit, subverting the rules." He describes himself as "not a security person at all," but rather an open-source maintainer. Having been relatively new to the government and policy world, with only "about eight months" of experience in that realm at the time of the talk, he provides the fresh, often bewildered, perspective of an industry expert encountering the unique challenges of the DoD environment.

Together, Rebecca and Eddie represent the dual perspectives at the heart of their talk. Their collaboration at Defense Unicorns underscores their shared mission to bridge the gap between private sector innovation and public sector requirements, aiming to equip the US military with advanced, secure, and effective open-source technology.