Code Signing Best Practices

7 Microsoft and PowerShell code signing best practices you can implement immediately

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.

7 Code Signing Best Practices

We’ve divided these best PowerShell and general code signing best practices into seven main points:

1. Employ Strong Key Security

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.

2. Timestamp Everything

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.

3. Understand the Difference Between Test- and Release-Signing

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.

4. Authenticate the Code You Sign

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.

5. Virus Scan Before Signing

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.

6. Use More Than One Key

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.

7. Tips on Revocation

Eventually, everyone ends up having to revoke a certificate for one reason or another. Before you do that, here’s some advice:

• When a compromise or some other issue arises, immediately notify your CA.
• The revocation date will affect the validity of your timestamped signatures. This means that you may want to select a date before the day the compromise was discovered.

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.