If there is one thing that recent supply chain attacks at companies such as SolarWinds, Codecov, and Kaseya have taught us, it's that software build pipelines are being targeted for attacks more than ever before. Hackers are no longer just attacking the bits and bytes of source code that go into our products, but also the development, testing, and build infrastructure tools that are used to build these products.
Even if you believe your company is at low risk of an attack, it's important to think about your customers. If you have high profile customers—like government agencies or large, multinational corporations—attackers might target you by hacking your company, or more specifically, the software you provide them.
The incidents at Solarwinds, Codecov, and Kaseya have shown us that traditional approaches to security are often failing to prevent attacks. Instead of targeting the software that these companies use, attackers targeted software these companies develop. Attackers may be targeting the source code you write, the open source code your team uses, and the development tools that you rely on. This is why companies like Venafi and GitLab are partnering to make it easier for developers to prevent attacks and make software supply chains more secure.
At Venafi, we believe that a new approach is necessary to secure the software supply chain, especially in the development stage. We also believe it is imperative that engineers incorporate more security controls in the development, build, test, and delivery pipelines.
No single security measure can prevent future attacks. Instead, engineers must adopt multiple software development measures, including a change in mindset about the security of the development infrastructure and who has the ultimate responsibility. Any lasting solution requires collaboration between industry leaders in software development, software security, and application provisioning. But successful collaboration must be led from an engineering-first perspective.
One effective approach software teams can take is to 'sign early, sign often' on all artifacts used by the software build process. A digital signature is an electronic signature that is used to authenticate the identity of the individual or organization that signed a file (for example a program, a document, etc). The digital signature will also make sure that the original content of the file has not been changed. While most people think of digitally signing (code signing) program executables (because operating systems often require it), digital signatures can be applied to any intermediate artifact like source code, build scripts, recipes, deployment containers, and third-party tools used by the development team.
Code signing uses cryptographic hashing that can validate the authenticity of software and ensure the integrity of code by verifying it has not been tampered with since being published. Code signing plays an important role in verifying the integrity of software used or distributed by organizations and individuals.
Why sign early and often?
Even if you've checked in a piece of source code to your repository, anyone else could alter that source code later – perhaps even someone pretending to be you. But if the source code was digitally signed, then a malicious actor could not introduce a change without also obtaining the digital code signing key used.
Another scenario to consider is if a development team member downloads the latest version of a third-party app but doesn't run it through your security team's protocols first. If the app contains malware, then your build system was just infected. By ensuring that only authorized versions of tools, libraries, and source code (which have passed security checks) are digitally signed by your company, sources of malware can be minimized.
Now consider automated build infrastructure, such as GitLab. If your pipeline doesn't require digital signatures of all artifacts used to build your products, then anyone could slip in a malicious change that is incorporated automatically, producing a malware-infected executable that could be delivered to your customers.
The devil is in the details
Managing PKI, managing code signing certificates, and configuring encryption keys is complicated. Code signing done incorrectly is simply not effective. Also, most code signing tools require easy access to the encryption private key, ending up on the build server or a developer's laptop. Here, hackers have easy access to misuse them.
The code signing process must also be convenient for developers. One way to make things easy on developers is to integrate code signing tools with the technology they use every day, like GitLab. We've found that if code signing technology is difficult, inconvenient, or in any way slows down a build pipeline, developers will avoid it.
Finally, if code signing is to be used as a security measure, your company's security teams need visibility into the process and the ability to define security policies.
Venafi and GitLab partnered together to make it easy for developers to sign source code and other artifacts, all from within your GitLab environment.
How Venafi can help
Venafi CodeSign Protect is a unique solution that focuses on both the needs of software development teams as well as security teams. Venafi is integrated within the GitLab environment so developers can easily sign their source code and other build artifacts without needing to know anything about PKI, code signing certificates, or code signing keys.