Skip to main content
banner image
venafi logo

The Problem with Code Signing Private Key Sprawl

The Problem with Code Signing Private Key Sprawl

The Problem with Code Signing Private Key Sprawl
July 11, 2019 | Eddie Glenn

People hide keys under their welcome mats, under the potted plant next to the front door, above the door jam or maybe under that fake-looking rock next to the front walk. But why would they hide their front door key in such obvious places? If I were a burglar, these are the first places that I would check (well, I would first check to see if the front door was even locked).

But some people are smarter than this. Instead of putting the spare key in an obvious hiding place, they make a few copies and hand them out to the dog sitter, the next-door neighbor, their boyfriend/girlfriend du jour or the handyman fixing the washing machine. Before they know it, they’ve lost track of who they have given keys to and their house is vulnerable once again.

Even though these scenarios are trite, it’s no laughing matter when it comes to securing code signing private keys. ASUS recently discovered this. D-Link discovered this a while back as have other businesses. In fact, over 25 million malicious binaries have been signed with stolen, purchased or altered code signing certificates.

Why does this keep happening? Is InfoSec asleep at the wheel? According to a recent study, that is not likely the case—InfoSec was responsible for managing private code signing keys only 40% of the time. Who manages code signing keys the other 60% of the time? Either the development team or a combination of the development team with InfoSec. But sometimes the InfoSec team just has no idea who’s managing the keys. That’s the problem.



Developers like convenience. They like automation. They like things to happen fast. Think DevOps, Continuous Delivery or Agile Development. Get a quality release out ahead of schedule and you get your bonus. Safeguarding private code signing keys doesn’t contribute to these results so it is not likely to be a priority for developers. As a result of this, code signing private keys end up on build servers, on a developer’s local desktop or laptop, somewhere in the cloud or on that computer in the lab at the far end of the building that people only use occasionally.

This is a problem for a business with a single, small development team. But just imagine how the problem grows for an organization with hundreds of development teams with thousands of developers spread around the globe.

This is private key sprawl.

And it’s a big problem for InfoSec teams because ultimately, they own the responsibility of securing their business’s data—including code signing certificates and private keys. With private key sprawl, it’s not just that private keys may be unprotected, but there is a lack of visibility into how bad the problem may really be. If you aren’t aware of that development team in Romania using a code signing certificate from ABC certificate authority, how would you even know to ask if the private keys were secured? So, just imagine the horror when, one day, your CISO asks why malware has been signed with a legitimate code signing certificate with your company’s name on it. “Uh…I didn’t know about it” doesn’t seem like a very good answer.

So, why don’t InfoSec teams just take control, seize all private code signing keys, keep them locked up safe and do all code signing operations themselves? Scalability and productivity. Remember when I said earlier that software development teams liked things convenient, automated and fast? Well, having all code signing activities funneled through a single, under-staffed team offers none of these things. And hence, this is why businesses end up with private code signing key sprawl.

Yes, requiring the use of HSM’s and security procedures can help mitigate the problem, but it doesn’t really address private key sprawl. Developers will always want things convenient, automated and fast and they will store private keys in places to achieve this, even if insecure.

What’s needed is a next-generation code signing solution that not only addresses security best practices, but is convenient, automated and fast for developers to use. In addition, if it can eliminate the burden that software development teams incur when obtaining and managing their own code signing certificates, all the better.

Private key sprawl is one of the problems that Venafi sought to solve when developing its Next-Gen Code Signing solution. Find out how it can help your organization solve this problem by reading our solution brief.



Related posts


Like this blog? We think you will love this.
Featured Blog

What Is the Difference Between a Public Key and a Private Key?

Symmetric and asymmetric encryption

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

Subscribe Now

See Popular Tags

You might also like

TLS Machine Identity Management for Dummies

TLS Machine Identity Management for Dummies

Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

About the author

Eddie Glenn
Eddie Glenn

Eddie is the Product Marketing Manager over Code Signing at Venafi. A product marketing professional in SaaS, Enterprise, and Embedded Software, he has a strong technical background and experience with inbound and outbound marketing, business and marketing strategy, and marketing operations.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more