Developers often put sensitive code signing credentials, such as private keys, in areas convenient and accessible to their build automation scripts. However, this practice puts these critical resources at risk for being misused or compromised. Plus, the practice of individually storing code signing keys results in an inscrutable and unsafe labyrinth of encryption keys, often referred to as key sprawl.
Anyone who has access to the network resource where the key is stored has access to the private key and can easily use it to sign software or a software artifact.
Lack of visibility into the software organization
Many InfoSec teams don’t have the visibility into what their software development teams are doing. In addition, code signing often plays second-fiddle to other information security issues and isn’t viewed as a high priority. However, InfoSec teams need to understand that significant risks exist around poor code signing hygiene. If code signing isn’t carefully controlled and monitored, attackers can insert malicious code into the applications and misuse applications to achieve nefarious purposes, and you may never know about it.
Attackers are extremely clever and the code they use may even be signed by an entity similar to or exactly the same as your own certificate authority (CA). So, it will be difficult to detect. Plus, you won’t know which machine identities are being used where.
Improperly configured code signing keys and certificates
Because many developers aren’t public key infrastructure (PKI) experts, they may not request a code signing certificate that has been configured correctly or may not know to use a significantly strong encryption key. Furthermore, they may not invoke the code signing operation properly.
An example of this error is not using a timestamp when signing a piece of code. Code signing certificates are issued for a given period of time. The expiration of a code signing certificate means that you can’t create new signatures. All past signatures will work for a given timestamp. If time stamps aren’t used, then when the certificate expires, the software won’t be able to execute anymore, stopping you from using software that’s been delivered to you, or keeping your customers from using the software you sent them.
Conclusion
Even if your organization doesn’t deliver software to your customers, you likely have internal groups that are developing software for use in your organization or scripts to automate critical IT operations. This likely means that your organization is already using code signing to protect this software. But do you have visibility into:
- What parts of your organization are signing code?
- Where they’re storing the private code signing keys?
- What software is being signed?
- Who’s approving the use of a critical code signing key?
Most code signing activities are handled by the authors of the software rather than a centralized group, such as information security (InfoSec). In years past, InfoSec may have been the central keeper of code signing. But with digital transformation and DevOps, a central group just can’t keep up with the demand from hundreds or thousands of developers around your organization.
Even though code signing has protected businesses and consumers for decades, there has been a recent increase in cybercriminals stealing, forging, or leveraging vulnerabilities through insecure code signing processes. This exposure increases the risk that critical internal software infrastructure is compromised by hackers or the reputation of a business is damaged when malware is inserted by a third party into their software products.
