Skip to main content
banner image
venafi logo

6 Scariest Ways Your Developers Can Use Digital Certificates

6 Scariest Ways Your Developers Can Use Digital Certificates

image of a young man sitting on a couch in a living room looking worried
June 4, 2020 | Eddie Glenn


It’s hard to argue that that all web services and applications should not be secured using HTTPS. However, securely obtaining and deploying the certificates needed for securing web services is a challenge, especially for developers.
 

Simply put, there is no easy way for developers to request certificates that comply with corporate policy. First, they need to know where the internal CA is, then they must be granted access to it and possess the proper credential to authenticate. Once they pass those hurdles, they need to know how to request a certificate with the proper characteristics, including who’s using it, what it will be used for and how long it should be valid. All of these delays will tempt developers to sidestep security to meet their SLAs.



 

Here are six DevOps shortcuts that should make the hair on the back of your neck stand on end:
  1. Not using TLS/SSL to secure connections
    When much of the DevOps process is automated, manual certificate processes will disrupt the workflow—something developers would rather avoid. In fact, many developers find it easier to ignore certificates than to allow security to delay the release. Deploying web services without securing them with HTTPS leaves end users vulnerable.

     
  2. Spinning up their own certificate authorities
    Even if they do use certificates, developers often look for shortcuts to simplify typically arduous security processes. They need look no further than to their DevOps platforms, which provide a script or instructions that allow developers to spin up their own internal certificate authority (CA). This allows developers to issue as many certificates as they need as fast as they need them. The challenge is that these “test” certificates are not always replaced by corporate-compliant certificates when the application moves to production. If that happens, your organization will be exposed to a veritable avalanche of certificates that you can’t see or that you may not even know about.

     
  3. Introducing self-signed certificates
    You should also be wary of how your in-house developers are using self-signed certificates. Rather than purchasing CA certificates, developers can download an open source implementation of SSL and TLS called OpenSSL. They can then create the certificates they need in order to develop and test software. When used in production versions of applications, these self-signed certificates can make you vulnerable to unforeseen attacks. If not properly monitored, self-signed certificates can allow cyber-criminals to conduct man-in-the-middle attacks that impersonate banking, e-commerce, and social media websites.

     
  4. Creating certificates with weak signature algorithms
    Dismissing or implementing keys and certificates poorly not only exposes your organization to unnecessary security vulnerabilities, but it can also lead to chaos by inserting inconsistent, manual steps into an increasingly automated environment. If you don’t maintain control over the security of your certificates, you may inadvertently enable attackers to use a compromised, stolen, or forged certificate to impersonate, eavesdrop, and monitor your infrastructure and decrypt communications you thought were private.

     
  5. Sidestepping or completely ignoring security policies
    Finally, developers are typically not security experts and most do not aim to be. They are less likely to consider anything but the most basic security measures to meet their objectives, especially given past struggles with the error-prone manual nature of certificate provisioning. The result is that security policies are either ignored completely or minimized to maintain the velocity of DevOps. This oversight can create blind spots in your security posture that allow cyber criminals to hide in your encrypted tunnels.

     
  6. The speed of DevOps does not have to come at the expense of security. There are ways that you can centralize, standardize, and automate the process of procuring keys and certificates as part of your end-to-end DevOps environment. Automating certificate acquisition will enable your DevOps teams to deliver applications and IT services more effectively and more securely. But to do this, your DevOps practitioners need to understand that they share important responsibilities for security; it isn’t just someone else’s job.
     

  7. Circumventing traditional code signing policies
    Traditional code signing processes set up by InfoSec may not fit well with DevOps CI/CD development pipelines. They may require manual effort, take days (or longer!) to fulfill, not able to be automated, etc. Does this mean that DevOps teams stop code signing their apps? No! Instead, they may find ways to sidestep current processes. This could involve obtaining their own code signing certificates (which may not be up to InfoSec policy standards) or storing private code signing keys on a build server without adequate protection. Either of these practices contributes significant risk to the entire business. Your business’ reputation depends on the fact that your customers can trust that the apps come from you and that a third party hasn’t inserted malware into them. With poor code signing policies or unsafe storage of code signing private keys, cybercriminals can easily circumvent this.


The speed of DevOps does not have to come at the expense of security. There are ways that you can centralize, standardize, and automate the process of procuring keys and certificates as part of your end-to-end DevOps environment. Automating certificate acquisition will enable your DevOps teams to deliver applications and IT services more effectively and more securely. But to do this, your DevOps practitioners need to understand that they share important responsibilities for security; it isn’t just someone else’s job.
 

This blog was originally posted by Scott Carter on October 26, 2017.



 

Related posts

 

 

Like this blog? We think you will love this.
shannon-lietz-devsecops-interview-with-venafi
Featured Blog

Why We Need DevSecOps [Interview with Shannon Lietz]

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

CIO Study: Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

Machine Identity Protection for Dummies
eBook

Machine Identity Protection for Dummies

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
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
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
Chat