Encryption Technology in Your Code Impacts Export Requirements

Encryption Technology in Your Code Impacts Export Requirements

US export laws require companies to declare what encryption technology is used in any software to be exported. The use of open source makes complying with these regulations a tricky process.

US Export Requirements

The regulations on US software exports come from the US Commerce Department’s Bureau of Industry and Security (BIS). The specific regulations are called Export Administration Regulations (EARs). The restriction of encryption is based in national defense concerns: we don’t want bad guys to be able to hack into our secret communications, nor prevent us from cracking into theirs. 

The specifics of these regulations are complex and belong in the realm of experts. The basics are that you need to tell the BIS what encryption is in any software you export, though it restricts only strong cryptography, with particular sensitivity to a small number of bad actor nation states. The agency is serious about the requirements and has been known to enforce them, notably fining Wind River $750,000 in 2014 (despite Wind River's voluntarily disclosing the issue they had discovered themselves).  

So How Is It Relevant to Open Source?

Many companies today, certainly Black Duck customers, understand it’s challenging for software development organizations to know what open source components are in their code. The ubiquity and accessibility of open source makes it so easy for developers to use that only companies with excellent training, policies, process and tools can really track it. And it’s only by knowing what’s in the code that companies can evaluate risks associated with those components.

Encryption is used in all kinds of applications today and therefore is a feature of numerous open source components. Open source is a common path for encryption to get into a code base, without necessarily being identified. Often when an engineer downloads an open source component, they are asking only enough questions to determine whether it will work for their purpose. They may not look into whether the component has embedded cryptographic elements or depends on (and ships with) other open source cryptographic libraries.

Request a Custom Code Analysis

Most organizations don’t have good processes for tracking open source components in the code. Engineers may not understand the importance of declaring crypto code (and indeed may not even know there is cryptography in the code) and the organization may not even know to ask the question. So you can imagine that the information does not necessarily get to those reponsible for making disclosures to the BIS.

It’s surprising how many of the frequently used open source projects include cryptography, such as: Zlib, glibc, log4j, Apache Struts, Apache Tomcat, dpkg, and angular. Glibc contains five different algorithms and Struts a whopping nine. There are some larger components with dozens. But, again, the point is, if you don’t know these components are in your code, you can’t account for the use of encryption. This lack of visibility increases the risk of running afoul of export regulations.

So What Do You Do?

Going forward, make sure there’s a process in place for tracking open source in your code. There should also be a process to vet components for the presence of encryption technology (in addition to license, security and other concerns) and to record that information. Educating your developers on the importance of knowing what's in their code will increase the likelihood that they follow the processes you have in place.

For your current code base, Black Duck provides an audit service to identify encryption in current code to give you a baseline on your codebase. That will save a ton of time and provides more comprehensive information than manual inspection. If you are acquiring a company that has not been managing open source code well, an audit can identify risks and help quantify the regulatory burden going forward.

Finally, it’s worth getting advice from an attorney who really understands this stuff.

0 Comments
Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.
0 Comments

MORE BY THIS AUTHOR

Can Blockchain and the BTC License Fund Health Insurance?

| Jul 26, 2017

The BTC license hit my radar screen recently. Billed as “sexy” by the author, the permissive BTC license employs Blockchain and may signal a new trend going forward that could transform the way many developers work... and how they get their health insurance. Background I chair the Linux

| MORE >

3 Examples of Why Permissive Licenses Deserve a Little Respect

| Jun 21, 2017

To the extent that tech companies manage open source risks, their primary focus tends to be on reciprocal licenses and the GPL in particular. As I've discussed earlier, the potential risks of open source are broader than just license compliance. Additionally, there are other licenses to consider

| MORE >