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.