Rate this article: (1 votes, average: 5.00)
Code signing is a critical component of software development. You spent all this time creating the software — that likely meant lots of late nights coding, lots of QA, and an unhealthy amount of caffeine — don’t you want to make sure that people trust your software? And, perhaps more importantly, don’t you want them to trust you as a developer? This is where implementing code signing best practices can come into play.
Your software likely isn’t just a one-off. You’re trying to build customer relationships — and that starts with trust.
But you already know that; you know you need to be signing your code. You know you need to get a code signing certificate from a trusted certificate authority (CA) like Sectigo (formerly Comodo CA) or DigiCert. You know about the validation involved, the issuance process.
You’re here to learn what the best practices are for signing your code. Whether you use Windows PowerShell or Command Prompt for your scriptwriting, these code signing best practices apply to you as well. So, let’s take a look.
We’ve divided these best PowerShell and general code signing best practices into seven main points:
Your signing key is the most important component of your code signing certificate. Guard it with your life. That means limiting access to it and, ideally, storing it on a hardware security module (HSM) and not anywhere on your network. That HSM should be cryptographic hardware using FIPS 140-2 Level 2 certified cryptographic standards. Additionally, make sure the cryptographic HSM is protected with a randomly generated password that’s at least 16 characters long. Of course, standard password rules apply, and passwords should contain a mix of upper and lower-case letters, numbers and symbols.
It takes a couple of extra steps to configure your signing device to make a call to a timestamp server, but they’re necessary extra steps because failure to do so will render your signatures invalid as soon as your code signing certificate expires. The only thing worse for a developer’s reputation than a user being told that your software isn’t trusted is a user being told your software isn’t trusted AFTER they’ve already been using. Relationship over.
Test-signing certificates don’t require the same rigorous security standards as development code signing certificates do. In fact, most of the time test-signing certificates are self-signed — which is totally acceptable in this context — and chain to a different root than the development signing certificates do. This is a necessary safeguard to ensure internal testing signatures never get confused with release signatures. Ideally, you should develop an entirely independent signing infrastructure for the test signing process.
This has to do with the actual development cycle. Before your release-signing key ever gets anywhere near your software, it needs to be fully authenticated by all stakeholders — meaning that everyone needs to confirm and sign off on the fact that it’s ready. It’s best to develop an entire approval process to ensure that all signings are well documented. This helps for both incident response and compliance.
This really kind of rolls up under the last heading, but it’s also worth stating explicitly. Make sure your software is virus-free before it’s signed. If there’s anything wrong with it and it ends up infecting your users’ computers or devices, not only are you going to have to deal with the fallout from that — it’s also going to cause your signing certificate to be revoked and you’re going to have a REALLY hard time getting another one because of the validation requirements.
Anytime you sign something with your private key, there’s a small degree of risk. Generally, the math behind modern day cryptography is prohibitively difficult for computers — but there’s still risk. And if anything happens with that key and it needs to be revoked, it’s going to invalidate other signatures and other good code. This code signing best practice really is just a modern take on the adage about not putting all your eggs in one basket. Use different keys for different projects and try to spread the risk.
Eventually, everyone ends up having to revoke a certificate for one reason or another. Before you do that, here’s some advice:
Keep in mind, you’re REQUIRED to revoke the certificate if it’s compromised or you discover it’s ever been used to sign malware.
And that does it for our code signing best practices. If you have any other questions, feel free to leave them in the comments section below.
Save up to 42% on Comodo Code Signing Certificates. Works on any platform except Apple.
Purchase Code Signing Certificates