Concluding our blog series on open-source software in the government market, it is time to turn to the darker side of things. We already discussed the “good” of open-source software for government buyers, and we walked through the “bad,” explaining how some elements may conflict with federal laws or priorities. Now we will look at the “ugly” side of open-source software and how contractors can mitigate associated risks.
The Ugly
So what is the “ugly” side of open-source code? In a word: malware. Given that neither the government nor the contractor control the development of open-source code, it is difficult for either to determine with absolute certainty what security risks the code may pose, or if there are back-doors hidden in the code itself to allow access by foreign governments or non-state actors. This is especially troubling when code is developed overseas in countries like Russia or China, which are known to target the federal government. Such code may have purpose-built, expertly hidden vulnerabilities that allow bad actors to gain access to critical systems. For these reasons, the government is very wary of such code. And, as cybersecurity continues to become a key factor in federal IT procurements, the risks, or perceived risks, posed by open-source components could be viewed by government buyers as outweighing the benefits, especially where the origins of all lines of code cannot be verified.
All this said, these risks are generally low. Because the source code is available for review and analysis, skilled coders should be able to determine if there appears to be sloppy or superfluous code, which can indicate malicious intent. While that step is uncommon when it comes to commercial development by start-ups in particular, you may have to be prepared to take that step when working with governments, especially if you are looking to work with the Department of Defense or on more sensitive projects. Further, if you are using open-source code in your back-end systems you should understand its origins and what each line of code is used for. Especially if you are housing classified information on your systems, the FAR and DFARS requires a heightened level of scrutiny over all software used on such systems, as any spillage of classified information can have severe consequences, both legally and financially, on the company and even individuals.
As to the financial risks, Federal regulations shift this risk squarely onto the contractor. Thus, if there is some security breach due to vulnerabilities in the code, the government will likely seek damages. These damages can be listed in the contract itself, or, more likely, simply be calculated on the basis of actual losses to the government. In some cases the government is even entitled to recover the costs it expends to try and contain the spillage of information. Indeed, regulations were put in place after the Edward Snowden incident that give the government explicit authority to recover such losses, so even one incident can put a company out of business. If you think about how difficult (or impossible really) it is to contain the spread of information once it is on the internet, it is clear that the federal government could expend infinite resources and still not fully contain the leak. While we have not seen the government come after any of our clients for such “clean-up” costs, you should be aware that it is possible. It is for this reason that, as noted, contractors should be aware of the origin of any open-source code used. They should also understand what various lines of code do and look out for suspect code that may hide a nefarious purpose. Some early caution and diligence can militate against these risks, especially if the diligence comes during development or when open-source utilities are selected.
While this may sound scary or difficult to manage, many of the risks of open-source code can be mitigated and, with shorter development cycles, lower costs, and its ability to help more commercial companies enter the federal marketplace, the “good” of open-source will likely win out. Indeed, if government contractors can deploy open-source correctly it will give them the competitive advantage they need to operate successfully in the federal market, and if more successful programs operate using open-source components, the government will be more likely to continue to adopt open-source platforms and become more comfortable with their use, to the benefit of all involved.
For more information on the use of open-source code in federal procurements, please contact a member of PilieroMazza’s Cybersecurity & Data Privacy Group.
Isaias “Cy” Alba, IV, the author of this blog, is a Partner in PilieroMazza’s Government Contracts Law and Cybersecurity and Data Privacy practice groups.
