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.
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).
Many companies today, certainly Synopsys 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.
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, Synopsys 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.
Phil is General Manager, Black Duck On-Demand. He works closely with Black Duck’s law firm partners and the open source community. A frequent speaker at industry events, Phil chairs the Linux Foundation's Software Package Data Exchange (SPDX) working group. With over 20 years’ software industry experience, Phil came to Black Duck from Empirix where he served as Vice President of Business Development and in other senior management positions, and was a pioneer in VoIP testing and monitoring. Prior to Empirix, Phil was a partner and ran consulting at High Performance Systems, a startup computer simulation modeling firm. He began his career with Teradyne's electronic design and test automation (EDA) software group in product, sales and marketing management roles. Phil has an AB in Engineering Science and an MS in System Simulation from the Thayer School of Engineering at Dartmouth College.