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 people 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 the encryption technology in your code 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.

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 responsible 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.