<- Back to the blog

Cryptographic Security in the Software Supply Chain

Graham Steel
February 3, 2022

Finding and Fixing your Inherited Cryptography

Many of the largest recent security breaches are the result of supply-chain security issues: applications are exploited because they incorporate third-party code that contains vulnerabilities, either by mistake, or by malicious action.

These attacks have led the industry to take an end-to-end look at the way we built modern software, and issue guides to securing that process. For example, the Cloud Native Computing Foundation and NIST have both released standards or drafts.

Since good cryptography is a cornerstone technology for security, it’s not surprising to see plenty of mentions of encryption, hashing, signing and authentication. This cryptography is designed to secure the source code, but what about securing materials? How do I ensure that my applications don’t inherit cryptography-related vulnerabilities from the libraries and transitive dependencies they pull in? If my application requires FIPS-approved cryptography, say to meet FedRAMP compliance, how can I be sure my materials don’t introduce non-approved cryptography?

Artifacts and Operations

To be sure that a third-party component is using secure or compliant cryptography I need visibility on two things: the cryptographic artifacts it contains (SSH and other keys, certificates, etc.), and the cryptographic operations it carries out. 

Start with artifacts. Suppose I deliver my application in container images. I likely build from a standard base image. What cryptographic material is in that base image? 

At Cryptosense, we ran our filesystem scanner over the most popular 50 container images in the Docker Hub. The results include self-signed certificates, insecure and expired PGP keys, non-FIPS compliant key lengths and more (you can consult the results yourself). None of this poses an immediate vulnerability in the base image, but you don’t want to ship this in your final image. You could fail an audit, or worse, a misconfiguration could end up making those self-signed certificates live.  

In the fast-moving DevOps cycle, we need to be able to check container images quickly, determine their cryptography inventory, then verify it meets our policy. Fortunately, we built the Cryptosense tools for exactly this kind of problem. The Cryptosense Filesystem Scanner runs over a container image (without having to run it) and finds all the cryptographic artifacts in there, even hidden away in configuration files and encrypted keystores. Even better, it can be built into your CI/CD process to automate this scan and deliver 

Now for operations. In practice, applications rarely call cryptography directly from their business logic. Encryption at rest, authentication, and secure networking are all dealt with by the third-party libraries and application frameworks we pull in. This brings cryptographic operations firmly into the supply-chain list of concerns. How do I know that the third-party library I’m using doesn’t carry out insecure cryptographic operations, or break compliance? Does my application set it up the right way to get the compliant encryption that I need? 

Scanning third party binaries for cryptographic algorithms won’t help - I will get both false negatives, since third-party libraries often use other standard component like OpenSSL to do the actual cryptography, and false positives, where a component statically links a whole cryptographic library, but then only uses a few specific algorithms.

At Cryptosense we chose to base our Cryptosense Analyzer Platform (CAP) on application tracing precisely to resolve this problem. Thanks to its IAST-style approach, it sees all cryptographic operations, including those carried out through third-party libraries. Integrating in CI is simple, since by attaching the cryptosense tracer, all functional tests also become cryptographic security tests, giving constant visibility on security and compliance.

Intent to Supply

Supply-chain security is a multi-faceted issue that is occupying some of the best minds in security engineering right now. With new regulations like FedRAMP, the US DoD is clearly labelling cryptographic security as a supply-chain issue that vendors must account for. Solving this problem requires visibility on cryptographic artifacts and operations and all stages of the build pipeline, something currently only Cryptosense Analyzer Platform can do. Find out more about the tooling and get a free trial here.