NSA and Open Source: Another Controversy Brewing?

September 05, 2013
By Derek Weeks

7 minute read time

I attended the NSA Open Source Industry Day in Maryland, and thought I'd summarize what did and didn't surprise me. We'll see if these observations prove controversial or helpful. More importantly, we'll see if organizations can effectively manage, govern, and secure their applications, given the reality of open source, agile development practices and component-based development.

What Wasn't Surprising?

Organizations are looking for an open source savior. They are looking for someone or something to hold accountable. They want a "single throat to choke." They are conditioned to think this way based on the historical support they receive from ISVs that license proprietary software. And now, they turn to vendors like Red Hat for open source infrastructure software support. But that model doesn't work for the hundreds or thousands of open source components sourced from different projects or forges. A new model is needed.
Open source = Linux, MySQL, JBoss. When people think open source, they think large infrastructure software. They don't think of the open source components used to build applications. Many are unaware or planning that 80% of an application is open source components. Until they accept this reality, it will be difficult for them to implement the processes necessary to secure component-based applications.
Disagreement about open source contributions. While people agreed that classified or secret system work shouldn't be shared, there was disagreement about non-sensitive work. And there were questions about the value of sharing this work. This led to a discussion about how custom change leads to forked internal versions that are difficult to maintain, and the change control issues associated with leveraging new open source versions. Here is an interesting article about open source in government misconceptions.
Disagreement about whether access to code gave hackers an advantage. Lots of discussion about how "many eyes make for safer code," and interesting conversation about whether access to code gave hackers an advantage. Some thought so, but others argued it doesn't matter because hackers can simply reverse engineer what they need from the binary.
Organizations can't keep up with the latest versions of software. Many panelists and attendees lamented their ability to keep their software current, even with large infrastructure software. When thinking about this in the context of components, the problem is even more daunting.

What Was Surprising?

People still buy into the golden repository fallacy. Perhaps this shouldn’t be surprising, but the knee-jerk reaction to many open source challenges was "we just need to ensure developers use the current version." Or "we should ensure that only the most current version is available for download from the Internet." Although it's great to have a repository to provide some control (we do provide the Sonatype Nexus Repository by the way), we know that there is no such thing as a golden repository. There are many problems with this approach: Developers will bypass it; it will be too restrictive for initial development efforts, etc. Sure, a repository is a start, but you need guidance and governance throughout the SDLC, including support for the production environment.
People still think an approval process is the way to manage OSS. One organization spoke about how they have an open source review board. Told from the perspective of a CISO - here is how it goes… warning, it's painful.

The owner of the OSS component (the person that wants to use it). They write up an in-depth review, including the business value. It goes to legal and we make sure we don't have a legacy issue, or a contract issue. Once legal is done, we go to review board, and depending on the timing of the project. They prioritize it with other items in the queue. It then goes through a security review. What functionality does it provide, what else will it touch? We have to understand the baseline. I have to know my enterprise and what my network looks like today. We factor in privacy requirements, transactional requirements. Do we do these securely? Are there protocols being used? Once that is done, we go deeper into the code using automated tools. At the end of the full review (legal, technical, security) we make a risk management decision. Do we want it in our enterprise? It's give and take with the developer. We like this, we need this changed.

I'm not arguing that these aren't important considerations. I'm just saying this approach doesn't work based on the volume, variety, complexity and release cadence of components, even if the workflow is automated. Think about this approach in an agile development environment that leverages short sprints. This is why developers resist policy efforts. Developers are forced to bypass the process to meet their deadlines. Or they have to rely on components already approved, even if they aren't the best component for the job.
People equate app security to DAST / SAST. While these technologies certainly play a role, some organizations force them to fit into managing open source usage. But how many organizations want to get involved with open source component code? They turn to components for "out of the box" functionality. They turn to components so they don't have to build it themselves. They don't want to be involved in the code. They often don't even have the code. And why wait to scan source code for components until they are used in the development process, when information is already known about those components? Information that can be used to select optimal components at the beginning of the development process. While DAST/SAST have their place, component-based development can't be managed the same way that we manage the custom code that stitches components together.

Key Realizations

Do you agree with these observations? Do you agree that we need to act? Based on the conversations that took place at the conference, these common themes indicate solid progress on the open source front:

Supply chain management. Given the application development process is supported by external components, using supply chain principles to manage the development lifecycle was a common theme. There is a realization that the entire software lifecycle needs to be supported, and that organizations are responsible for the application regardless of what constitutes the application. People understand how components can be used to drive developer efficiency, as long as security, licensing and quality risk can be managed.
Automation is key. Even though I didn't hear DevOps uttered once, there was plenty of discussion around automating the development and delivery process. While this automation is typically focused on the application delivery toolchain (IDE, build tools, CI, CD, etc.), it can lead to conversations around policy automation. Automated policies can provide guidance and enforcement directly in the tools used to develop and deliver software applications.
Give developers what they want. There is a growing realization that security needs to provide developers what they want. The CISO understands that developers will bypass their controls if they hinder the development process. They realize they have to overcome the "false positive" and "false negative" burden that is the result of many application security tools. And they are starting to realize that providing information to developers in their context requires integration into the tools they use. Look, for example, at how Sonatype's CLM platform integrates open source security data and automates the policies directly in the IDE, where developers work every day.
Modify security to work with how today's apps are developed. Security and quality efforts must be aligned with modern development approaches, and that's not just accommodating the use of open source. There were plenty of conversations about agile development, and how security and quality efforts must fit within that construct. Among other things, it means that policy and compliance efforts must fit within short agile development cycles.
Organizations must take responsibility for code and components that are externally sourced. There is a growing realization that developers using open source must manage it effectively. But this responsibility should not fall on the developer alone; the entire organization needs to support the effort. And organizations must do so in a way that supports the development process naturally, not by force fitting legacy approaches. The answer can't be that we just won't use open source. There is too much value that would be lost.
Silos (of all kinds) need to be removed. While DevOps leads the way by breaking down Development and IT Ops silos, it's not just organization friction that stifles agility. In the keynote, Dr. Patrick Dowd, NSA CTO and Chief Architect, talked about how they are moving away from an enclave-based architecture because the silos made it difficult to analyze data that crossed enclaves. Instead, they have moved to an architecture that leverages open source technologies to deliver cloud-based utility, data, and storage support. Organizations realize they are more likely to meet agility and speed goals if they dismantle organization, technology and architecture silos.

If you attended the event, or if you work in the government sector, do you agree with these observations?

If you work in another industry, it might help think about how this perspective relates to your industry.

Written by Derek Weeks
Derek serves as vice president and DevOps advocate at Sonatype and is the co-founder of All Day DevOps, an online community of 65,000 IT professionals.