Hardening the security of an organization is extremely important as time goes on, since new techniques for infiltration are discovered often. Attacks can come from several different attack vectors, and one of the more common attacks executed today are code signing attacks. These attacks are exploited from several different means, but there are methods to harden security from these types of attacks. By following code signing best practices, you can harden your organization’s security against these attacks.
Why You Should Follow Code Signing Best Practices
As many organizations know, some of the most prevalent types of attacks today are supply chain attacks. Supply chain attacks are implemented on organizations that interact with a number of smaller organizations daily. What I mean by this is that supply chain attacks focus on organizations that provide software or tools to a number of smaller organizations. This allows threat actors to infect a tool or piece of software provided by a single organization, and in turn infect all the smaller organizations that use that tool. Code signing supply chain attacks specifically compromise the software update mechanism itself, as in SolarWinds (2020), where a build pipeline was compromised and malware was signed with a legitimate certificate before distribution, or the 3CX incident (2023), where a similar build-compromise pattern let malware ship as a trusted, signed update.
Code signing best practices as an operating model, defined: not a checklist to review once, but enforceable controls, HSM-backed keys, role-based access with separation of duties, mandatory approvals, scheduled rotation, tamper-evident audit logs, tested revocation, and build isolation, that a signing platform enforces automatically rather than depending on individuals remembering to follow a policy document.
Key Takeaways
- A policy document isn’t a control. Best practices only reduce risk when a platform enforces them automatically, HSM key storage, mandatory approval gates, and access restrictions that can’t be bypassed by an individual’s judgment call.
- This page covers the business case and the full control set at a summary level. For the detailed implementation walkthrough, see Code Signing Best Practices in the SDLC; to measure where your organization stands today, see Code Signing Maturity Uncovered and its self-assessment scorecard.
Code Signing in the Industry
Though code signing is not a new technology, as companies have used it for many years, there are still gaps found in code signing techniques regularly. Though not related to code signing, recently a flaw was found in the Java coding language, the Log4J vulnerability, which has been in Java code for years. This vulnerability, even though it was only recently discovered, is within the basis of the majority of Java code on the Internet.
This recent flaw has sent the majority of the world’s companies into a panic attempting to patch this vulnerability. Many of these organizations will need to harden their security due to this flaw and keep up-to-date on updates from Java when an official patch does come out. This type of vulnerability is why it is so important to keep your systems updated with the best practices for code signing, as a large flaw like this may be found in the future.
Top Code Signing Best Practices
Below are the controls that turn code signing best practices into an enforceable operating model, not just a policy document.
- HSM-backed keys: Private keys used for code signing certificates must be stored in a Hardware Security Module, not on a filesystem, in a script, or in environment variables. An HSM requires physical access plus proper credentials to extract a key, which is why the CA/Browser Forum has mandated HSM or equivalent hardware storage (FIPS 140-2 Level 2 or Common Criteria EAL 4+ minimum) for all publicly trusted code signing certificates since June 1, 2023.
- Role-based access control and separation of duties: Access to signing keys and the HSM must be restricted to the principle of least privilege, and the person who can trigger a build should not be the same person who can approve its signing. This separation is what stops a single compromised account from signing and shipping malicious code unilaterally.
- Mandatory approval workflows: Every signing request beyond routine test builds should require sign-off from a second, trusted identity before the signature is applied. This is the control that catches an insider threat or a compromised pipeline attempting to push an unauthorized update through an otherwise legitimate signing process.
- Scheduled key rotation: Keys should rotate on a defined schedule, not only in response to a suspected compromise, reducing the exposure window if a key is compromised without anyone noticing.
- Tamper-evident audit logging: Every signing event should be logged with the artifact hash, key identifier, approving identity, and timestamp. This is what makes a code signing breach forensically traceable rather than a mystery, and what compliance frameworks like SOC 2 and NIST expect to see during an audit.
- Tested revocation procedures: A documented, rehearsed revocation process matters because the CA/Browser Forum requires revocation within 24 hours of confirmed key compromise. Building that capability during an actual incident, rather than before one, costs valuable response time.
- Timestamping: Every signature should include an RFC 3161 timestamp so signed software remains verifiable after its certificate expires, increasingly important now that publicly trusted code signing certificates are capped at 460 days.
- Build isolation: Signing should happen in a dedicated, hardened environment used only for that purpose, not on a general-purpose machine running other software that expands the attack surface unrelated to signing itself.
Frequently Asked Questions
Is a written code signing policy enough to satisfy an audit?
No. Auditors increasingly expect evidence that controls are enforced by the platform, not just documented, tamper-evident logs, HSM attestations, and approval records that show the policy was followed, not just written.
Which of these practices matters most if we can only implement one first?
HSM-backed key storage. It’s the CA/Browser Forum’s actual baseline requirement, and every other control (approvals, rotation, audit logging) assumes the key itself isn’t sitting exposed on a filesystem to begin with.
How do I know where my organization currently stands against these practices?
See Code Signing Maturity Uncovered for a self-assessment scorecard across key custody, access control, revocation, build isolation, and audit trail.
Conclusion
As you can tell, hardening security whenever possible is very important to ensure the continued safety of an organization. Following best practice in all areas of computer security is very important, as a big flaw like the log4j vulnerability could be found at any time by any organization. Another great way to ensure an organization is following best practice is to monitor cybersecurity news and ensure that any patches or new methods of securing systems are updated when necessary. To learn more about how to implement our code signing product, visit our website at www.encryptionconsulting.com.
