Bypassing Procurement Can Introduce Some Unwanted Visitors

The federal IT procurement safety net may be developing some holes. Many federal developers are forgoing traditional software purchasing in favor of going directly to the source and downloading code from tens of millions of open source repositories and libraries. While this can certainly expedite innovation, it also has the potential to expose agencies to security risks if they’re not careful.

This backdoor approach to code procurement can let in some unwanted visitors through that door: unknown and dangerous vulnerabilities that may have gone undetected in the code. Without the checks and balances of procurement, how can they be sure that the code they are downloading does not contain some form of malware or another bad actor? How can they stay agile while keeping their applications and networks safe?

The Procurement Security Blanket

A rigorous procurement process that takes into account security hygiene and quality assurance can help keep the bad stuff from getting into the system. Circumventing that process can create a couple of different challenges.

First, there may not be a record of a piece of code being downloaded from a random source code repository. This can make it difficult for IT managers and developers to keep track of the applications running on their networks. It can be hard to pinpoint when a piece of code becomes compromised, or identify where the potential problem lies in the case of suspicious activity. Also, code on sites like GitHub or DockerHub may not be actively maintained, and may not have fixes for exploits that currently or will exist. If there is an exploit, it may be impossible for developers to receive a patch in case of a problem.

Second, developers are not necessarily security experts. They care primarily about getting their applications to work. They may make changes to their code, push it into a repository, and test it to make sure it is working as expected. They may not be testing for security, though; they’re testing for functional correctness. Unbeknownst to them, the code they are downloading may have some flaws that can go unnoticed until it’s too late.

Checking the Open Source Software Supply Chain

Security must be everyone’s responsibility. Developers should be writing functionally correct and secure code, and operations and security teams should put in checks that reinforce a good security posture prior to production but also provide a secure development environment to make it as easy as possible for developers to write secure code. There are several ways this can be done.

Agencies can analyze the code that they are using and the source from which it originated. They can keep tabs on the libraries developers are downloading software from, and whether or not these libraries contain known vulnerabilities. They can also run their own internal code through a code analyzer to help detect resources leaks, memory corruptions, control flow issues, or other defects that can provide attackers with a foothold.

Agencies can also participate in crowdsourced security initiatives designed to test the efficacy of their defenses and reinforce the notion that security must be taken seriously by everyone, including developers. The Defense Department has engaged in exercises like Hack the Pentagon, which was designed to expose bugs and vulnerabilities in the department’s networks. Programs like these draw attention to security measures and can help put security at the forefront. Developers may be more likely to consider security as an integral part of their application development processes.

Developers in the open source community are already taking security very seriously. No one wants to be responsible for putting out code that creates an opportunity for exploitation. Programs like the Core Infrastructure Initiative Badge Program help showcase open source projects with a commitment to security. Meanwhile, individual developers have used techniques like typosquatting to alert to potential bad actors and questionable code.

Checking and Balancing

Even when an agency buys a commercial, certified, and security hardened product, their work is not done. An agency can buy an open source operating system that has been fully vetted and write code on top of it. If that code is being pulled from outside libraries and hasn’t been fully scanned and vetted, that agency may land right back at square one.

Indeed, the platforms that agencies use can be the most secure and sophisticated in the world, but if the code that runs on them is not secure, it will not matter. As the number of open source software repositories continues to explode, agencies must take steps to ensure that code that has not been run through traditional procurement safeguards contains no known vulnerabilities. If they can do this, they can give both developers and security managers a valuable combination of agility and peace of mind.

David Egts is chief technologist for North America Public Sector of Red Hat.