Editor’s Note: This article is one in a series of pieces we will publish over the next few weeks that aim to help resolve code signing-related errors for SignTool, Jarsigner, Electron, and Windows.

Uh-oh. It looks like you forgot to define the algorithm.

Cryptographic algorithms are a fundamental part of the code signing and timestamping processes. Nevertheless, not all hashing algorithms are created equal. This is why if you forget to define in your script which type of secure timestamping algorithm SignTool should use, you’ll be greeted by this error message:

What ‘SignTool Error: No File Timestamp Algorithm Specified. Please Specify the Timestamp Algorithm With the /td Flag’ Means

This is another crystal-clear code signing error: you wanted to timestamp your signature, but you didn’t state which algorithm SignTool should use. Oops.

Thankfully, this code signing error is a quick and easy fix.

Possible Cause(s) for This Timestamp Algorithm Error

You omitted the mandatory /td option and algorithm from the code signing and timestamping command. SignTool.exe uses this information to specify the algorithm utilized by the RFC 3161-compliant server to generate your signature’s timestamp.

How to Fix the Error ‘No File Timestamp Algorithm Specified’

Insert the /td option followed by a secure signing algorithm (i.e., SHA256) just after the timestamp server’s URL.

Platform(s)/Systems Affected

SignTool.exe (Windows, Visual Studio Developer Command Prompt, Visual Studio Developer PowerShell).

The post SignTool Error: ‘No File Timestamp Algorithm Specified. Please Specify the Timestamp Algorithm With the /td Flag’ appeared first on Code Signing Store.

During the code signing process, all signing tools (e.g., Jarsigner) access the Keystore to ensure that it includes the valid chain of trust certificates (i.e., the code signing certificate, any intermediate CAs, and the root CA) and your private key. If something goes wrong during the check, then your files aren’t signed and the Jarsigner ‘certificate chain not found” warning may display.  

Editor’s Note: This article is one in a series of pieces we will publish over the next few weeks that aim to help resolve code signing-related errors for SignTool, Jarsigner, Electron, and Windows.

What Does ‘Jarsigner: Certificate Chain Not Found For […]’ Mean

This code signing error indicates that the Keystore item to use for signing either isn’t specified or is incorrect or otherwise invalid.

Possible Cause(s) of This Certificate Chain Error

1. Syntax error. Your signing script doesn’t explicitly specify the correct Keystore or keystoretype for the signature. If you’re using a hardware token to store your certificate, which isn’t considered a file-based keystore, then you’ll need to create a file named eToken.cfg (if you don’t already have one set up) in your JDK bin folder.

2. At least one trust certificate is missing. The specified Keystore doesn’t contain all of the chain of trust certificates. This error could also result from your signing command not correctly referencing the right keypair alias.

How to Fix This Jarsigner Error

Method #1: Review your script and add the wording -storetype PKCS11 before the time stamping information, like this:

jarsigner -keystore NONE -storetype PKCS11 -tsa http://timestamp.digicert.com -providerClass sun.security.pkcs11.SunPKCS11 -providerArg ./eToken.cfg

C:\Users\file_path_to_your_jar_file\example.jar "Alias Info"

NOTE: Notice the ./eToken.cfg file we talked about a little earlier? That’s what will point to your secure USB token where your certificate is stored.

Method #2: Check that the necessary chain of trust’s certificates and your private key are included in the Keystore key entry indicated in your code signing script. Also double-check your command to ensure you’re referencing the correct keypair alias.

Platform(s)/Systems Affected

Java Jarsigner (Windows, Linux, macOS).

The post How to Fix the ‘Jarsigner: Certificate Chain Not Found For […]’ Error appeared first on Code Signing Store.

“SignTool Error: No File Digest Algorithm Specified. Please Specify the Digest Algorithm with the /fd Flag”

Microsoft’s SignTool.exe is an easy-to-use command line tool used to sign all sorts of files compatible with the Windows operating system (OS). But as you can see from the error above, this doesn’t mean your code signing operations will be always mistake-free.

So, let’s explore what the following SignTool.exe error message means and learn how to avoid it.

Editor’s Note: This article is one in a series of pieces we will publish over the next few weeks that aim to help resolve code signing-related errors for SignTool, Jarsigner, Electron, and Windows.

What ‘SignTool Error: No File Digest Algorithm Specified. Please Specify the Digest Algorithm with the /fd Flag’ Means

This SignTool code sign error is probably one of the most straightforward ones you can hope to see. It means exactly what the name implies: your script doesn’t mention the functional dependency (in this case, the algorithm that should be used to add the digital signature to your code).

Possible Cause(s) of This ‘No File Digest Algorithm Specified’ Error

You forgot to add the /fd tag to your signing script, followed by your chosen hashing function, to specify the hashing algorithm in your code signing command.

How to Fix this SignTool Missing File Digest Error

Add /fd followed by a secure signing algorithm (i.e., SHA256) to the SignTool signing command. Ensure it precedes your file location and name, as shown in the example below:

Platform(s)/Systems Affected

SignTool.exe (Windows, Visual Studio Developer Command Prompt, Visual Studio Developer PowerShell).

The post SignTool Error: ‘No File Digest Algorithm Specified. Please Specify the Digest Algorithm with the /fd Flag’ appeared first on Code Signing Store.

Editor’s Note: This article is one in a series of pieces we will publish over the next few weeks that aim to help resolve code signing-related errors for SignTool, Jarsigner, Electron, and Windows.

Jarsigner is notorious for blurting out ambiguous warnings, as is the case with the error “only one alias can be specified.” It’s one such message that may seem straightforward on the surface, but when you dig deeper, you’ll find that there’s more to it than you realize.

Let’s say you wanted to sign a .jar file without overwriting the original .jar. You type your signing command, incorporating the -signedjar option, followed by your chosen .jar file, and hit enter. But to your dismay, it didn’t work, resulting in displaying this error:

Jarsigner: only one alias can be specified

Image caption: The screenshot shows the “only one alias” alert.

What ‘Jarsigner: Only One Alias Can Be Specified’ Means

When the code signing process fails with this error, it’s usually due to typos in variables or because your Jarsigner file signing script includes more than one alias.  

Possible Cause(s) of This Error

1. Your code signing command includes more than one alias. This is to be expected from the name of the error, right? But what if it’s not the only cause?
2. The code signing command has a small typo or similar issue. An example could be a mistyped filepath folder or a file name that includes spaces but isn’t wrapped in quotation marks. In the case of our example above, the “-” sign in front of the “signedjar” option is missing.

How to Fix This Jarsigner Issue

1. Double-check for any typos. If there aren’t any, then rename your filepath folder or file and either remove the spaces or enclose it in quotation marks. For example, it could look like MyFiletoSign or “My_File_to_Sign.”
2. Remove spaces from your filepath folder or file name. If there aren’t any typos or character issues, it could be that you’ve included spaces. (Jarsigner isn’t a fan of spaces in pathnames and such.) Rename your filepath folder or file and either remove the spaces or enclose it in quotation marks to see if it fixes the problem. For example, it could look like MyFiletoSign or “My_File_to_Sign.”
3. Compare your script with the example below. Ensure that they match:

jarsigner -verbose -keystore NONE -storetype PKCS11 -tsa http://timestamp.digicert.com -providerClass sun.security.pkcs11.SunPKCS11 -providerArg ./eToken.cfg -signedjar  C:\Users\file_path_to_your_jar_file\YourNewFileName.jar C:\Users\file_path_to_your_jar_file\YourFile.jar "Private Key Alias Name"

Platform(s)/Systems Affected

Java Jarsigner (Windows, Linux, macOS).

The post How to Fix the ‘Jarsigner: Only One Alias Can Be Specified’ Error appeared first on Code Signing Store.

To sign a Java code with Java Jarsigner, you need to know your private key’s alias that can be identified with a simple command line (CMD) script:

keytool -list -keystore NONE -storetype PKCS11 -providerclass sun.security.pkcs11.SunPKCS11 -providerArg eToken.cfg

However, you might end up receiving an error message like the one below:

What does it mean and what can you do to fix it?

What ‘Keytool Error: Java.Security.KeyStoreException: PKCS11 Not Found’ Means

The public-key cryptography standard #11 (PKCS11) specifies the interface between a software app (e.g., Jarsigner) and a secure, cryptographic device (e.g., the USB hardware token where your private key is stored). When Java Jarsigner can’t find your secure hardware, or if there’s an issue with your configuration file, the code signing process fails.

Possible Cause(s) of the Java Security KeyStoreException PKCS11 Not Found Error

1. Your token or authentication client driver isn’t properly installed or is corrupted.
2. The token’s slot number (specified in the eToken.cfg file) is incorrect.
3. You are missing one or more secure token device drivers.

How to Fix It

Ready to make this Java security keystoreexception pkcs11 not found error a thing of the past?

1. Reinstall your authentication client. For example, if you’re using a DigiCert Code Signing Certificate, then you’ll need to reinstall the SafeNet Authentication Client.
2. Ensure that your eTPKCS11.dll is located in the correct directory. This should be located at library=c:\WINDOWS\system32\eTPKCS11.dll.
3. Change/add your slot number in the eToken.cfg file. The eToken.cfg file should be located in your PDF bin folder (e.g.., C:\Program Files\Java\jdk-21\bin). If you don’t have one, then you’ll need to create one. When updating the slot number, start with slot=0 and slowly increase it one slot number at a time until you find the right one.
4. Install driver updates for your token or authentication client. Visit the token manufacturer’s website for the latest software updates.

Platform(s)/Systems Affected

Java Jarsigner (Windows, Linux, macOS).

The post How to Fix ‘Keytool Error: Java.Security.KeyStoreException: PKCS11 Not Found’ appeared first on Code Signing Store.

“A certificate chain processed but terminated in a root certificate which is not trusted by the trust provider.”

Did you try to verify the signature of a Windows file with SignTool.exe before releasing it to the public and wind up receiving the following error message?

The certificate hierarchy, also known as a “chain of trust” or “trust chain,” serves as the foundation of trust for your code signing certificate (and, by extension, your software). This chain of certificates provides assurance to software users that your software is authentic and hasn’t been modified by any unauthorized third parties.

Fear not. We’ll help you rectify the situation so that you can deploy your code on time.

Editor’s Note: This article is one in a series of pieces we will publish over the next few weeks that aim to help resolve code signing-related errors for SignTool, Jarsigner, Electron, and Windows.

What ‘SignTool Error: A Certificate Chain Processed, But Terminated in a Root Certificate Which Is Not Trusted by the Trust Provider’ Means

The code you are verifying has been signed. However, the root certificate included in the certificate chain isn’t trusted.

Possible Cause(s)

1. The verify command typed in the CMD is incorrect. Thus, SignTool based the verification on the Windows Driver Verification Policy. Try using this instead: signtool verify file_example.exe. (NOTE: SignTool doesn’t require a hyphen [-] in front of verify.)
2. The code has been signed with a self-signed certificate. Self-signed certificates are untrusted, so they’re going to always populate errors when you try to use them in external use cases.

How to Fix It

1. Add /pa to the command. This way, SignTool will use the correct verification policy (i.e., Windows Default Authentication Verification Policy) to ensure that Microsoft’s Authenticode verification conditions have been met.

signtool verify /pa file_example.exe

2. Re-sign the code using a trusted code signing certificate. This is a publicly trusted certificate (i.e., not a self-signed certificate) that you got from a third-party CA or an authorized reseller such as CodeSigningStore.com.

Platform(s)/Systems Affected

SignTool.exe (Windows, Visual Studio Developer Command Prompt, Visual Studio Developer PowerShell).

The post ‘SignTool Error: A Certificate Chain Processed, But Terminated in a Root Certificate Which Is Not Trusted by the Trust Provider’ appeared first on Code Signing Store.

Editor’s Note: This article is one in a series of pieces we will publish over the next few weeks that aim to help resolve code signing-related errors for SignTool, Jarsigner, Electron, and Windows.

No developer ever wants to receive the following error message in SignTool:

SignTool Error: An unexpected internal error has occurred. Error information: “Error: SignerSign() failed.” (-2147024885 / 0x8007000B)

SignTool.exe errors are like those washed-out road signs. If you’re lucky – like in this case – you might be able to understand a bit (e.g., code signing failed) but you still have to figure out the rest.

The good news is that you’re here now, and we’ve already done the work for you.

What “SignTool Error: An Unexpected Internal Error Has Occurred. Error Information: “Error: SignerSign() Failed.” (-2147024885 / 0x8007000B)’ Means

In a nutshell, this error means that SignTool couldn’t sign the file or executable due to an unexpected issue with the package content or the hashing algorithm.

Possible Cause(s)

This particular warning may be caused by different issues, such as:

1. A corrupt package.
2. The hashing algorithm used for signing doesn’t match the algorithm specified in the app block map.
3. The manifest publisher’s name differs from the name listed on the code signing certificate.

How to Fix It

1. Review the event log and implement the solutions described by DigiCert’s documentation. This approach requires you to check your Event Viewer event log for more specific details. You can access this tool by typing in Event Viewer in the Run bar.

• 2. Alternatively, add the /debug option before the full SignTool command. This will allow you to view more information about the issue and fix it accordingly.

Platform(s)/Systems Affected

SignTool.exe (Windows, Visual Studio Developer Command Prompt, Visual Studio Developer PowerShell).

The post How to Fix ‘SignTool Error: An Unexpected Internal Error Has Occurred. Error Information: “Error: SignerSign() Failed.”’ appeared first on Code Signing Store.

Jarsigner empowers developers and software publishers to digitally sign and verify Java codes or get a detailed view of a code signing certificate’s information. These things help underscore the authenticity and integrity of the software apps and code they create.

Did you know that the command used to verify the integrity of a digital signature can also result in code signing failure messages? Here’s a quick example of the jarsigner error java.lang.RuntimeException keystore load issue you might see that infers it cannot find the file (or “the system cannot find the path specified” if a similar message displays):

Editor’s Note: This article is one in a series of pieces we will publish over the next few weeks that aim to help resolve code signing-related errors for SignTool, Jarsigner, Electron, and Windows.

What This Jarsigner Error java.lang.RuntimeException Keystore Load Actually Means

So, seeing this code signing error message when you’re using the Jarsigner verify command is a bit misleading. The warning itself isn’t necessarily caused by an issue with the specified file in all cases; sometimes, it stems from the fact that the Jarsigner verification command you typed is incorrect.

Let’s consider some possible causes for what makes the jarsigner error java.lang.runtimeexception keystore load message appear.

Possible Cause(s)

• The file path may be mistyped or pointing to the wrong folder.
• The file in question doesn’t exist in the specified location.
• Ensure the command verify isn’t introduced by the “-” sign (i.e., the dash is missing).

How to Fix This Jarsigner-Related Error

• Double-check your code for any mistyped commands or file paths. Otherwise, it can lead to the jarsigner keystore-related error.
• Verify the file in question is, in fact, available at the specified path.
• Correct your script by adding the dash before the command verify. Here’s what it should look like:

jarsigner -verify C:\Users\file_path_to_your_jar_file\YourFile.jar

Looking for more Jarsigner code signing errors and warnings? Check out Oracle Jarsigner’s documentation.

Platform(s)/Systems Affected

Java Jarsigner (Windows, Linux, macOS).

The post How to Fix ‘Jarsigner Error: Java.Lang.RuntimeException: Keystore Load […] (The System Cannot Find the File Specified)’ appeared first on Code Signing Store.

If your organization uses Google Cloud and has developers signing remotely or in the cloud, we have great news: Google Cloud Key Management Service (Cloud KMS) now integrates seamlessly with Sectigo code signing certificates.

Why use Google Cloud KSM with Sectigo? To avoid the limitations and hassles of secure USB hardware. Since June 2023, all publicly trusted code signing certificates must be generated and stored on secure hardware. This means that many developers have to manage one or more secure hardware tokens, which can be an annoyance for any business, let alone those with employees working in different geographic locations or using cloud-based DevOps systems.

Get to Know Google Cloud Key Management Service

Google Cloud KMS is a secrets storage solution that allows you to securely generate, store, and manage your public and private cryptographic keys for use in compatible services and applications. In short, organizations can digitally sign scripts, apps, and other workloads in cloud environments while simultaneously improving security and devops efficiency.

It’s a win-win for your organization’s security (and the sanity of your developers): no muss, no fuss, and no more having to track down and manage your company’s hardware tokens.

Google Cloud KMS + Sectigo = A Power Play in Software Security

Google Cloud Key Management Service now supports Sectigo code signing certificates.

With Google Cloud KMS, you can securely generate your certificate(s) cryptographic keys using Google’s fully managed FIPS 140-2 3-compliant hardware security modules (HSMs). This means you get to enjoy the benefits of a secure HSM without the hassle of managing on-prem appliances.  

This key management service offers reassurance that your secrets remain secure and won’t be compromised while:

• integrating with your Google Cloud account and specified (enabled) projects.
• enabling your remote developers to sign software apps without requiring direct access to your signing keys.
• streamlining your key management tasks by allowing you to store and manage groups of keys (keyrings) simultaneously and organize them by work environment (e.g., testing, staging, and production).

Now, pair this with a Sectigo Code Signing Certificate and you’ll be golden. Sectigo, formerly Comodo CA, is a trusted name within web and software security communities.

Get Familiar with Google Cloud KMS Code Signing to See If It’s the Right Fit

Want to get a better idea of all that’s involved? Be sure to check out our guide on How to Use Google KMS With a Sectigo Code Signing Certificate, as you’ll need to set up several resources inside Google Cloud and delegate permissions.

The process can be a bit advanced, so it’s helpful if you’re already familiar with Google Cloud.

How to Start Signing in the Cloud with a Sectigo Code Signing Certificate

When purchasing a Sectigo Code Signing Certificate to use with Google Cloud KMS, be sure to select the Install on Existing HSM option when adding it to your cart. (You’ll have the ability to choose your specific HSM type momentarily.)

Once you complete your order, you’ll quickly move through another guided process on CertificateGeneration.com.

Choose Google Cloud KMS as Your Existing HSM Type

In Step 4, be sure to select Google Cloud KMS (Cloud HSM) as the Certificate Collection Method. This enables your key to be generated and stored on Cloud Cloud’s secure HSM in compliance with the code signing industry’s security baseline requirements.  

Follow our guide to generate the CSR and download the key attestation in Google Cloud.

Google Cloud KMS is one of the alternative code signing certificate delivery methods you can choose from when getting a certificate from CodeSigningStore.com.

The post Sectigo + Google Cloud KMS Code Signing appeared first on Code Signing Store.

2024 was another rough ride for organizations of all sizes. Ransomware hit unprecedented new highs, with nearly three-quarters of the businesses polled by OpenText reporting experiencing at least one attack that year.

Supply chain attacks continued to wreak havoc, occurring at a pace of “at least one every two days in 2024.” Credential phishing attacks swept the world and surged by an alarming 703% in the second half of the year.

So, even if the past year was a tough battle in the trenches, it’s time to arm yourself with the knowledge you’ve learned from the frontline. In this article, we’ll look at seven real-world examples of software security-related incidents that made headlines in 2024 and discover how to avoid making the same mistakes in 2025.

Cybersecurity in 2025 TLDR: What to Learn From 7 Real-World Software Security Incidents 

Here is a summary table giving you an overview of the lessons to learn and actions you can implement to boost your organization’s security in 2025. Don’t stop reading, though. We’ve included a lot of “juicy bits” (insights) regarding each incident and lessons learned in detail throughout the rest of the article.

Lesson #1: Assess Your Vendors and Limit Access to Sensitive Systems and Data (Snowflake)

Let’s start with a bang. I’m sure you remember the Snowflake attack. The multi-cloud data hosting company made news in April 2024 when at least 165 of its corporate customers fell victim to devastating data breaches.

How did it happen? It was easier than you think. Cybercriminals accessed and downloaded data using credentials previously stolen through a remote access Trojan (RAT). The operation was further facilitated by three key factors:

1. Weak authentication. The sensitive data stored in the cloud was accessible via login with a traditional ID and password.
2. Unchanged passwords. The credentials exploited by the bad guys were still valid. Yup, the victims didn’t change their passwords after a previous breach.
3. Too broad permissions. Several accounts granted unrestricted permissions and access to sensitive data and databases.

This explains a lot.

Who/What Was Impacted

The impact was so severe that the attack was dubbed by many as the “mother of all data breaches.” Millions of customers’ sensitive data were compromised. Here, are a few examples:

• Ticketmaster. Over 40 million users were affected and 560 million records (e.g., customer names, email addresses, payment data) were leaked.
• AT&T. Hackers stole records relating to nearly all AT&T customers’ phone number, text messages, and phone calls. Some records even include the location of cell towers closest to a “subset” of subscribers. That’s a massive leak of nearly 110 million customers’ data.  
• Santander Bank. The records of more than 12,000 Santander U.S. employees were compromised. The leak included names, bank account information, and social security numbers.

What Can You Learn from This Breach?

One of the big mistakes AT&T and other affected organizations made was to unquestioningly trust Snowflake’s security posture. Don’t make the same error.

• Carefully evaluate your software providers and other third-party vendors. Minimize exposures and risks by conducting thorough vendor risk assessments, following the best practices issued by the National Institute of Standards and Technology (NIST).
• Update your account credentials. The cybersecurity firm hired by many organizations targeted in the campaign, Mandiant, reports that many of the impacted accounts used credentials that had been exposed in previous third-party breaches but had never been rotated or updated.
• Enforce multi-factor authentication (MFA). Replace the traditional ID and password with the more secure MFA that requires users to provide two or more verification factors. Even better, opt for passwordless authentication. This way, hackers won’t have anything left to steal.  
• Implement the principle of least privilege (PoLP). Regulate permissions by giving vendors and users access to only what they need to do their jobs. Joe from the HR department doesn’t need to access your customers’ sensitive data to carry out his duties, right?

Lesson #2: Scan & Secure Your Websites, Cloud Apps, Software and Other Assets (Amazon Web Services)

Cybercriminals are always hungry for more — more vulnerabilities to exploit, more financial opportunities, and more invaluable customer data. In August 2024, AWS customers were targeted by hackers connected to the cybercriminals involved in the Ticketmaster attack.  

The crooks scanned 26+ million AWS IP addresses for vulnerabilities and misconfigurations. They also analyzed secure socket layer/transport layer security (SSL/TLS) certificates and did a reverse IP lookup to extract domain names. Dark Reading reports that they were able to do this by targeting “flaws present on the customer application side of the shared responsibility cloud model and did not reflect any fault of AWS.”

As soon as the operation was completed, the little devils swept the listed vulnerable endpoints and extracted every sensitive data, credentials, and secret they could find.

Who/What Was Impacted

Once again, the spoils were pretty rich. In just a few weeks’ time, the attackers extracted two terabytes of data, including:

• 1,526 unique and valid AWS credentials. The loot included private keys and secrets for GitHub, the communication API Twilio, and cryptocurrency platforms.
• 8,244 accessible private buckets (i.e., the cloud storage version of file folders).
• Over 252,000 exposed GIT repositories.

What Can You Learn from This Breach?

The digital world is a dangerous place, above all “up in the cloud.” Protect your organization, customers, and data:

• Invest in a web application firewall (WAF). A WAF is a cost-effective way to protect your web application from the bad guys. Think of it as an all-seeing eye between your website and the internet that filters, controls, and blocks suspicious traffic.
• Scan your website for vulnerabilities. According to CVEdetails.com, more than 11,000 recent or updated vulnerabilities were detected in 2024 when compared to the previous year (which had a total of 29,066 vulnerabilities). This is a massive increase, considering that fewer than 4,000 common vulnerabilities and exposures (CVEs) were published or updated in 2023. So, pick your favorite free or paid scanning software and automatically scan your websites and applications for vulnerabilities.
• Use canary tokens. Time to start trapping! Prepare your trap line by sprinkling these little nets in critical places across your website. Did you get an alert? It means a canary token has been triggered and you now know that someone is trying to access your secrets. Isn’t it sweet? And you don’t even have to wait for trapping season to place them.
• Shield your keys and certificates. Protect your code signing certificates and keys. If you own several keys and certificates, DigiCert Software Trust Manager provides HSM storage and certificate revocation and rotation to granular permission management and activity logs.  

Lesson #3: Safely Store Your Certificates and Keys, and Never Underestimate Anomalies (AnyDesk)

In February 2024, AnyDesk announced that hackers had broken into its production servers. Jackpot. Although the firm didn’t share many details about the incident, it’s thought that the root cause was likely a misconfiguration problem.

Even if AnyDesk identified some evidence of breaches in their production servers in mid-January 2024, bad actors were already freely running all over the platform since December 2023.

Who/What Was Impacted

OK, as far as we know, the aftermath didn’t involve any lawsuit in this case. However, AnyDesk and its clients — the company’s remote desktop software programs used by at least 170,000 organizations worldwide — had to invest a lot of time and effort to get back to normal, as:

• Over 180,000 customer credentials were posted for sale on the dark web.
• Code signing certificates and keys were stolen. AnyDesk had to revoke all code signing certificates and keys used to digitally sign their software. The company reported it also revoked all customer web portal account passwords out of an abundance of caution.
• Customers were unable to access the portal for several days. Fixing a breach takes time, and this incident wasn’t an exception.

What Can You Learn from This Breach?

Incidents do happen. The following measures will help you prevent or at least minimize their impact.

• Store your code signing certificate’s private keys on a hardware security module (HSM). When your cryptographic keys are saved on an HSM, neither users nor applications can see, touch, or alter them. Corporations can opt for a highly secure, self-managed, on-premises FIPS 140-2 Level 2 compliant HSM. Smaller businesses usually go for more affordable managed solutions. Purchase a code signing certificate and store it on a fully managed HSM-backed cloud solution or use a secure key management solution like DigiCert Key Locker and Azure Key Vault. 
• Never underestimate anomalies (or your guts). AnyDesk ruled out that the customer credentials listed on the Dark Web were related to the breach. Nevertheless, the company did the right thing by forcing a mass password change and taking additional security measures. So, the next time you notice something suspicious during a routine audit or monitoring, don’t ignore it. Take action right away, as doing so might save your day (and your job).
• Monitor and log network traffic and activities. Keep an eye on your network traffic, analyze logs, and set up automatic alerts for unusual patterns or unauthorized behavior. Don’t stop at traditional website scanning processes; regularly pen test your applications.

Lesson #4: Rigorously Test Updates/Patches and Deploy Them Incrementally (CrowdStrike)

Did you ever imagine that a simple feature update gone wrong would bring half the world to a halt? That’s what happened in July 2024, when CrowdStrike’s Falcon security platform update was rolled out and blue screens of death (BSOD) popped up on millions of Windows systems globally.

According to CrowdStrike’s official statement about the issue, the situation boiled down to a basic input field mismatch within the sensor system. The sensor expected one thing (i.e., 20 input fields) while the update provided another (i.e., 21 input fields). While this error is small, it had a big effect that resulted in system crashes.

The event was so catastrophic that the company won the DEF CON Epic Fail Pwnie Award, a trophy for top failures that is typically awarded at the annual cybersecurity conference in Las Vegas.

Who/What Was Impacted

Yup, it was a real Armageddon that grabbed the attention of the U.S. Cyber Security & Infrastructure Security Agency (CISA) and:

• Affected 8.5 million Windows devices. “Blue screens of death” (BSODs) appeared all over the world and across various private and public sectors. From banks and government agencies to airlines, retailers, and healthcare services — organizations around the world were thrown into a state of chaos.
• Required an extremely time-consuming recovery process. Businesses had to spend weeks to restore normal operations.
• Was immediately exploited by cybercriminals. Attackers targeted CrowdStrike customers with malware and phishing.  

What Can You Learn from It?

On top of what we’ve mentioned so far:

• Test patches and updates. Don’t rush into deploying patches and updates. Test them in a sandbox environment first and on a limited set of devices. This approach will help you catch compatibility issues and flaws before deployment. 
• Go for incremental rollouts. Implement a patch and update management process that ensures rollout in stages. If something goes wrong, the damage will be limited to a few devices and won’t jeopardize your whole organization.
• Have a plan B. Set up a strong disaster recovery and business continuity plan. Outages happen, but if you have a system redundancy in place and a backup on hand, you can reduce your operations’ downtime and impact on customers and users. 

Lesson #5: Sign Your Code & Train Your Employees (Ascension)

In May 2024, bad actors launched what became the third-largest healthcare data breach of the year. An Ascension employee downloaded a legit-looking malware-infected file that spread like wildfire, finally resulting in a ransomware attack.

The investigation was concluded only in December 2024. Apparently, no ransom was paid, but the impact on the company’s reputation, patient relationships, and operations was humongous.

Who/What Was Impacted

As a result of the incident:

• 5.5 million patient records were stolen. The files included medical, insurance, and payment information, and other personal data such as passport numbers, date of birth, and addresses.
• Operations were severely disrupted. Ambulances were diverted, patient appointments, non-urgent operations, and tests were postponed for days.
• Patients’ records were locked. Thus, Ascension employees had to go back to the 90s and note everything on paper, from triages and procedures to prescribing and dealing out medications.

What Can You Learn from It?

• Train your employees. Set up comprehensive cybersecurity training for your whole staff. Include exercises on spotting phishing emails and scanning attachments and codes for malware using a reputable antivirus tool. Show them how easy it is to check the authenticity and integrity of software by verifying its digital signature. When this knowledge is applied to real-world circumstances, this approach will significantly reduce the risk of falling for scams.
• Allow only downloads from trusted sources. Implement security policies so that your employees stick to software vetted by your IT department or coming from trusted app stores (e.g., Microsoft App Store or Google Play for mobile devices). Be sure to enforce an antivirus scan before any download, regardless of where a file or app is coming from.
• Sign and timestamp your code and executables with a trusted code signing certificate. A code signing certificate lets you add a digital signature to your software. Thus, when an employee downloads the signed code, the client verifies the signature and alerts him if the software has been modified. The code/ attachment isn’t signed? Then it isn’t safe and shouldn’t be trusted or run — no exceptions.

Lesson #6: Build Your Products Following the Secure-By-Design Approach (Ivanti/CISA)

In today’s digital world, no one is safe, not even the experts. Beginning in 2023, cybercriminals repeatedly exploited flaws in two Ivanti security solutions to breach government agencies and enterprise networks. 

If this wasn’t bad enough, even when Ivanti issued a fix for the vulnerabilities and created a tool for its customers to check whether they were compromised, the attackers bypassed both mitigation measures and Ivanti’s integrity checker after a mere few days.

The Ivanti Connect Secure and Ivanti Policy Secure Vulnerabilities became a major incident, and CISA was one of the victims.

Who/What Was Impacted

Obviously, when government agencies are involved, the level of impact is always pretty high. This one, was no exception. 

• Potentially, 100,000+ individuals were affected. The breached CISA’s Chemical Security Assessment Tool (CSAT) contained a wealth of screening data screening on people and companies that had access to high-risk chemicals in the U.S, and private sector chemical security plans.
• Two CISA systems had to be taken offline for days. On top of the CSAT application, CISA has to temporarily take offline also its portal used to secure critical infrastructure (CISA Gateway).
• Ivanti had to officially apologize and change their cybersecurity approach. The company’s reputation was badly hit. Ivanti had to invest time, money, and resources to put it right and change the way their cybersecurity strategy.

What Can You Learn from It?

• Run different software tests (and do it often). During development, test your code, often and early. Use static and dynamic software testing to find errors, bugs and evaluate its performance. Assess the security of your application by getting a pentester to simulate cyberattacks. Check all configurations to eliminate weaknesses and potential security issues. You’re not sure where to start? CISA’s recently published Top 10 Cybersecurity Misconfigurations document will help put you on the right path.
• Implement a strong patch management process. Stress-test your patches with different systems in an isolated test environment before rolling them out. Automate the deployment using a critical-updates-first approach so that the most critical patches are installed first.
• Opt for a secure-by-design approach. Strictly speaking, embed security into every stage of the software development lifecycle, starting from the very beginning. Learn more about how to implement it by reading CISA’s whitepaper and following OWASP’s recommended secure coding practice checklist.  
• Hash and salt or encrypt your data at rest. Worried one of the bad guys will find a way around your security measures? Make his efforts fruitless by scrambling your sensitive data at rest (e.g., stored credentials, personal information, etc.) to add another layer of protection. For personal info, encrypt the data. For passwords, salt and hash it.

Lesson #7: Monitor Your Systems/Network & Don’t Hardcode Credentials (Sisense)

In April 2024, malicious actors exploited a hardcoded token embedded in one of Sisense’s self-hosted GitLab repositories and gained a free ride into Sisense’s Amazon S3 bucket in the cloud.

To make matters worse, the attackers even didn’t break a sweat as the data stored in the bucket was unencrypted.  The situation is akin to Sisense handing the bad guys its data on a silver platter. The event was so extreme that CISA took an active role in the investigation.

Who/What Was Impacted

The volume of stolen data and secrets was just one of the multiple repercussions.

• Attackers exfiltrated several terabytes of data. The leak included access tokens, SSL/TLS certificates, email credentials, and sensitive customer data.
• Third-party services were also affected. The breach put at risk also services connected to the stolen information such asSalesforce, Amazon S3, Amazon RDS, and GitHub.
• Critical infrastructure providers were among the victims. Financial services, telecommunications, healthcare, and education were just a few of the over a thousand organizations compromised.

What Can You Learn from It?

• Never hardcode credentials. Hardcoded cloud credentials are one of the biggest threats to cloud security, as demonstrated by case studies and real-life examples. Be proactive. Invest in secret management tools and use secret detection platforms to detect and eliminate hardcoded credentials. Some can even automatically delete, encrypt, or redact the identified secrets.
• Monitor your systems and network. You don’t need to break the bank to get a unified view of your infrastructure and applications. Open-source software like Nagios or Prometheus gives you real-time visibility of your systems and network for suspicious activities so that nothing can slip through the cracks. 
• Generate a software as a service bill of materials (SaaSBOM). Just like the traditional SBOM documents every component of a software app’s code, an SaaSBOM lists all SaaS applications used within an organization. It gives you a clearer picture of your organization’s data flow and overall infrastructure to provide meaningful insights into critical areas such as rogue applications (think shadow IT and unauthorized software usage), data handling and governance, and vendors.

A Quick Look at the Potential Consequences of Unaddressed Software Security Issues

Cybersecurity incidents can happen to any business and the aftermath can have short and long-term effects on the organization as a whole, leading to (among other issues):

• Reputation/Brand harm and damages. Vercara’s latest survey shows that 70% of consumers would stop buying from a company victim of a data breach. Bad news travels fast, but reputational damage can take ages to mend. 
• Financial losses. This is probably the first and most immediate impact. Monetary losses go beyond remediation costs. CrowdStrike’s shares went down by nearly 20% when the incident happened. There are also concerns regarding the loss of sales contracts and future business opportunities that directly impact your company’s bottom line.
• Legal or compliance-related issues. Failing to comply with data protection and privacy regulations can cost you big money in fines. Lawsuits followed many of the incidents mentioned in this article. For instance, CrowdStrike’s shareholders filed a class action and Delta Airlines sued the company for the mass flight cancellations.
• Operational disruptions. Incidents can shut down an organization’s operations for hours or days. Downtime may affect customers and third parties. Consider what happened with Ascension and CrowdStrike. In both cases, a snowball effect seriously impacted millions of customers and systems. 

Final Thoughts About 7 Software Security Lessons to Avoid Repeating in 2025

OK, we all know that bad guys will never stop looking for ways to sneak into organizations’ systems and that cyber threats are unending. However, you can mitigate the risk of attacks and stay ahead of emerging threats by adopting a multi-layered and proactive defense strategy.

Use the lessons learned from the 2024 battlefield as your cybersecurity blueprint for 2025 to lead your company through the modern minefield. 

• Sign your code with a trusted code signing certificate during the whole software development life cycle (SDLC),
• Implement the principle of least privilege,
• Secure your private keys,
• Never hard code credentials/secrets,
• Configure your apps and systems with care, and
• Encrypt your data at rest and in transfer.

Last but not least, create a robust open-source vendor evaluation checklist and supercharge your software supply chain security to prevent potential third-party vulnerabilities. 2025 is here; it’s time to flex your muscles and get ready for the fight.

The post 7 Software Security Lessons to Avoid Repeating in 2025 appeared first on Code Signing Store.