9 Common Software Signing Mistakes to Avoid in Your Next Project

1 Star2 Stars3 Stars4 Stars5 Stars (5 votes, average: 5.00 out of 5)

Don’t let software signing mistakes ruin your next application project. Discover how to fix nine of the most common errors faced by software developers and publishers to avoid shipping vulnerable products

We all make mistakes — we’re human, after all. However, sometimes oversights can have nasty consequences. Verizon’s 2024 Data Breach Investigation Report (DBIR) confirms it: Human errors were among the root causes of 68% of data breaches.

In application development, even a small software signing error can significantly increase the chance of your organization or customers falling prey to attacks and malware infections.

In this article, we’ll explore the nine most common software signing blunders people make and a few down-to-earth solutions to prevent them. Our goal is to help prevent you from shipping a vulnerable final product that endangers your organization’s reputation, customers, and data.   

9 Mistakes to Avoid When Signing Software

John Lennon once said: “A mistake is only an error. It becomes a mistake when you fail to correct it.” So, let’s find out how to prevent nine frequent software signing snafus from becoming costly mistakes.

Software Signing Issue #1. Failing to Integrate Code Signing Into Your SDLC

The 2024 Docker State of Application Development Report shows that 34% of developers put security-related tasks at the top of their difficult/very difficult-to-do list part of their software development process. However, skipping those tasks or relegating them to the end of the software development process is a dangerous game. Code tampering can happen at any time in your software development life cycle (SDLC). This is why it’s crucial to properly integrate code signing into the dev lifecycle early on to help mitigate vulnerabilities and protect the integrity of your software apps and code.

How to Fix It

An illustration of how cloud code signing simplifies software signing
Image caption: A cloud-based code signing certificate allows you to digitally sign your software from anywhere, no matter when, without having to bring a physical USB token.

Software Signing Issue #2. Using a Self-Signed Code Signing Certificate in Production

Self-signed certificates are often used during software development and testing. They’re quick and easy to generate, don’t cost a dime, and they don’t expire, as the generator sets the policies. However, these very characteristics also make them unsuitable (and unsafe) for production.

Forgetting to replace these internal certificates before releasing the software to the public can cost you more than you think. For instance, when a user attempts to install a self-signed software app, their operating system (OS) will display a security warning. Imagine how many potential customers you might lose because of it and the damage to your reputation.

Software Signing screenshot: When you digitally sign your software applications they'll display your verified organizational identity info in the User Account Control (UAC) window.

Image caption: A trusted code signing certificate will transform the security warning on the left into the reassuring message on the right. 

How to Fix It

  • Purchase a trusted code signing certificate from a trusted source. This includes certificate authorities (CAs) like Sectigo and DigiCert or an authorized reseller like CodeSigningStore.com. They’re the best alternatives that’ll give you the best bang for your buck.
  • Review your code before releasing it. It’ll ensure all self-signed certificates have been replaced by trusted ones.
  • Use trusted certificates everywhere. Software trust doesn’t have to be limited to production only. You can extend the benefits of software signing with a trusted code signing certificate to your testing and development environments. This way, nothing gets overlooked when transitioning from dev to production (i.e., you don’t forget to swap out a self-signed certificate before distribution).

Software Signing Issue #3. Software Signing Without a Timestamp

Did you know that publicly trusted code signing certificates expire between one to three years? And when it happens, the dreaded unknown publisher warning will come back with a vengeance every time a user downloads/installs the software signed with the expired certificate. The same goes for revoked certificates.

The one thing that can change this depressing scenario is adding a digital timestamp to your software after signing it. Without timestamping, every code signed with that particular certificate will be regarded as unsafe and will have to be re-signed with a valid certificate. This can cause many headaches for you, your customers, and other software users.

How to Fix It

A screenshot of signing a Jar file as a method of software signing
Image caption: The screenshot shows the script utilized to sign and timestamp a .jar file with Java JarSigner.

Software Signing Issue #4. Not Scanning Your Software for Malware Before Signing It

According to ReasonLabs, malware was the top security threat detected in Q1 2024, accounting for nearly 50% of all global detections. Software signing an infected code could have dramatic consequences on your organization’s reputation and finances.

Once downloaded, malware can infect your customers’ devices. One single infected machine can quickly snowball into a giant data breach, as demonstrated by the Snowflake incident impacting more than 165 major companies. (as of this article’s date of writing).

How to Fix It

Prove Your Software Is Trustworthy

Signing your code shows users that your software and updates can be trusted.

A 3D screenshot of the Code Signing Best Practices Guide from CodeSigningStore.com

Download our free code signing best practices eBook to learn how to help keep your supply chain secure and your company, customers & end-users safe.

Software Signing Issue #5. Trying to Manage Your Certificate Lifecycle Manually

62% of organizations interviewed by KeyFactor in 2022 didn’t even know how many certificates they had. Two years later, 84% confirmed that the increasing use of certificates and keys is still a challenge for their operation teams.

We get it. Decentralized teams, changes to security requirements, and evolving attacks aren’t making things easier. However, when you don’t know where your keys and certificates are, who is using them, and how and when they’re being used, then the risk of being stolen and exploited to sign malware is just around the corner.

How to Fix It

  • Keep all your software signing certificates and keys under one roof. Go for a certificate management software such as DigiCert Software Trust Manager. This integrative platform facilitates software threat detection, secure code signing, and SBOM generation.
  • Manage your whole certificate and key lifecycle automatically. Do you manage a high number of certificates and keys? Ideal for large enterprises, the same DigiCert Software Trust Manager platform we previously mentioned will also remove the burden of manual tracking for enterprises that have many certificates to manually track by enabling the use of automation.

A screenshot from the DigiCert Software Trust Manager platform
Image caption: DigiCert Software Trust Manager enables you to quickly and easily manage your software certificate lifecycle while offering a slew of other benefits, including threat detection and SBOM generation.

Software Signing Issue #6. Failing to Protect Your Private Key

In 2023, attackers stole and posted on the dark web an MSI computer manufacturer’s private keys for Intel Boot Guard, which were used on 116 MSI software products. This was a serious breach for many reasons, particularly when you consider that Intel Boot Guard’s purpose is to protect devices against malicious installation and download of malicious or vulnerable UEFI firmware.

The stolen keys enabled cybercriminals to sign malicious software and updates that, once downloaded, would have allowed malware to be installed on devices without being blocked by Boot Guard’s code integrity check. 

How to Fix It

  • Store your keys securely. Save your keys on a secure hardware security module (HSM) compliant with the CA/B Forum’s June 2023 security standard.
  • Limit keys and certificate access. Give only access to keys and certificates to those in charge of software signing (principle of least privilege) and remove it when they change roles or leave the company.
  • Implement multifactor authentication (MFA). It’ll help you ensure that the software signing person is really who they say they are. Are you using DigiCert Software Trust Manager? Two-factor (2FA) authentication is already included in it.
  • Assign tasks to different individuals. Segregation of duties is crucial for security. Ensure your organization’s key generation and software signing responsibilities aren’t handled by the same person (separation of duties).

Software Signing Issue #7. Skipping Monitoring and Auditing Activities

In 2023, developers interviewed by Checkmarx left 57% of vulnerabilities they found in their code unresolved. Furthermore, nearly one-third of surveyed chief information security officers (CISOs) knowingly deployed vulnerable code with the hope that the issues would remain undiscovered. That’s downright scary.

In today’s digital world, where everything changes at lightning speed, you can’t bury your head under the sand and ignore security procedures to cut corners. You also can’t just hope and pray for the best. These approaches put your organization, code, and customers at risk while exponentially increasing your technical debt.

How to Fix It

  • Regularly audit and monitor software signing procedures compliance. We all know how tempting it is to cut corners to respect tight deadlines. Ensure that everyone follows the agreed-upon procedures and updates them when needed to reflect the latest vulnerability trends.
  • Subscribe to security newsletters. Check that your software signing processes and tools are updated against the latest flaws.
  • Monitor your software signing logs. Always know who signed what, with which certificate and keys, and when the recorded activities took place using logging.
  • Sign your software bills of materials (SBOMs). This way, if an SBOM or code is modified without authorization, you’ll be immediately alerted. (Check out the following video to learn more about what SBOMs are and how they work.)

Software Signing Issue #8. Not Following (and Sharing) Industry Standards Changes

Let’s keep on talking about critical changes. In June 2023, the industry standard’s body issued new software signing guidelines requiring all private keys to be issued on secure hardware (e.g., a token or HSM) compliant with FIPS 140 Level 2, Common Criteria EAL 4+, or equivalent.

In summer 2024, the National Institute of Standards and Technology (NIST) will publish the new post-quantum cryptography (PQC) Federal Information Processing (FIPS) standards (FIPS 203, 204, and 205).

Are the developers and users in your organization unaware of such changes? If so, they might generate insecure keys, store them incorrectly, or use vulnerable algorithms to generate them. Any one of these scenarios represents an open door to trouble.

How to Fix It

  • Prepare for post-quantum algorithms. It’s never too early to prepare for the next threats. DigiCert Software Trust Manager already supports and lets you generate quantum-safe machine learning-based digital signature algorithms (MLDSAs).
  • Educate your users and employees. Teach them about the importance of industry standards through traditional brown bag sessions or online training.
  • Check your team is up to date with key processes and industry changes. Now that all code signing certificates’ private keys are issued on or with secure hardware i.e., a USB token by default), verify that all developers know how the new software signing process works.

Want to know more? Discover in this video how a comprehensive digital certificate management solution can protect the integrity of your code along your whole software supply chain.

Software Signing Issue #9. Overusing Your Private Keys and Certificates

In February 2024, the remote desktop software provider AnyDesk announced that attackers stole some of their code signing keys and certificates. One day later, more than 18,000 credentials were advertised for sale on the dark web.

The outage lasted several days and impacted millions of users. The company had to revoke all code signing certificates and keys and request its 170,000 customers to change their passwords and install the latest, newly signed version of AnyDesk.

So, how can you prevent something like this from happening to your organization?

How to Fix It

  • Diversify your software signing activities. Always use different code signing certificates and keys. This way, if one key gets compromised it won’t affect your whole product range.
  • Set up automated key rotation. Harness the power of certificate and key management tools like DigiCert Software Trust Manager and Azure Key Vault to automatically change the keys used for code signing on a regular basis.
A screenshot of the key rotation feature of the DigiCert Software Trust Manager platform
Image caption: A screenshot of DigiCert Software Trust Manager’s Key Rotation feature.
  • Follow key rotation standards. NIST SP 800-57 part 1 rev. 4 will help you define the correct cryptoperiod (i.e., a key’s validity period) for your needs.

Here’s a basic overview of what the key rotation process looks like:

A basic illustration of the key rotation concept
Image caption: The graphic shows how to secure software signing with key rotation. The key rotation process encompasses everything from replacing the old key and ensuring everything encrypted with it has been secured using a new key to safely before securely disposing of the old key.

Final Thoughts About These Common Software Signing Snafus

Software signing is a powerful tool that’ll help you secure your whole software supply chain and organization against threats (so long as it’s implemented correctly). It:

  • Confirms your identity as a trusted software publisher (authentication),
  • Proves your customers that the code hasn’t been altered since it was signed (i.e., ensures data integrity), and
  • Boosts your reputation and customers’ confidence in your products.

 If poorly implemented or managed, it can become one of the worst chinks in your organization’s armor. Understanding the most common software signing errors is the first step toward a robust and secure software signing ecosystem.

Make your security armor shine again. Start repairing those dangerous chinks now. It’ll protect your products, customers, and business in the never-ending battle against bad guys.