Answers: <p>You essentially have three threats here:</p>
  
  <ol>
  <li>Someone could modify <code>.travis-ci</code> and use that to exfiltrate the unencrypted key material.</li>
  <li>You could accidentally check-in or publish the decrypted key material as part of your release process.</li>
  <li>Someone could attempt to attack the encrypted key-material directly; this is very unlikely given modern practice and current computing power.</li>
  </ol>
  
  <p>The challenge of secret management is common in open source projects; one approach I have taken in the past is to have a second "deploy" stage in a private repository and pipeline.  A private repository and pipeline, then ring-fences the sensitive data from malicious actors entirely, protecting yourself from 1 and 3.  You can safeguard against two by whitelisting files that can be checked in to decrease the probability of making a mistake.</p>
  
  <p>Finally, an approach that can be used to increase the detectability of an attack is to store the key in <a href="https://aws.amazon.com/cloudhsm/" rel="nofollow noreferrer">AWS CloudHSM</a>, <a href="https://cloud.google.com/hsm/" rel="nofollow noreferrer">Google Cloud HSM</a> or <a href="https://azure.microsoft.com/en-gb/services/key-vault/" rel="nofollow noreferrer">Azure KeyVault</a> with the goal of marking the private key as <em>non-exportable</em> and then handing off any encrypt, wrap or sign requests to the cloud.  This means even if the credentials for the HSM/KeyVault do get exfiltrated you know every time they are used to sign something and can effectively revoke access to the key entirely.  Unfortunately, there doesn't seem to be any way of doing this with SSH keys at the moment, however, it works will with code-signing certificates.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-10-31T15:31:36.530Z
Answers: 2019-10-31T15:31:36.530Z
Answers: Richard Slater
Body: <p>In the processes of setting up continuous deployment for an open source project with Travis I came across a predicament, can the encrypted private key be easily exfilitrated? For context, the deployment workflow is:</p>
  
  <ol>
  <li>In a Travis build job, build and test code</li>
  <li>If it passes, deploy the code</li>
  <li>Decrypt the encrypted private SSH key and start the SSH client</li>
  <li>Push to the Git remote on the production server</li>
  </ol>
  
  <p>Using <code>travis encrypt-file deploy_rsa --add</code>, the private key is encrypted and only decryptable within the Travis build job. Am I correct in the assumption that someone forking the repo and creating a Travis build job will not be able to decrypt the key? In addition, the <strong>only attack vector</strong> would be for someone with push rights to modify the <code>.travis-ci</code> script to decrypt the key and send it to themselves?</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-02-17T19:28:43.583Z
Comments: Fork, add a dump of the key somewhere in the build, make a pull request, if pull requests are built the key will be shown in the public build log of Travis...
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-02-17T22:16:31.940Z
Comments: This is not the case, at least for Travis https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
Comments: Moritz
Comments: CC BY-SA 3.0
Comments: 2018-02-18T08:29:34.137Z
Comments: So you have your answer :) (but the Travis-ci file is still not the only attack vector for someone allowed to push)
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-02-18T15:29:28.070Z
Comments: What else should I consider?
Comments: Moritz
Comments: CC BY-SA 3.0
Comments: 2018-02-18T16:42:18.693Z
Comments: Whatever build system is used, scripts, even the code could exfil datas during unit tests, usually that's not a real concern on open source projects and/or build and deploy are separated. Some quality test of code (sonar/checkmark) can test for suspicious patterns also
Comments: Tensibai
Tags: <continuous-deployment><travis-ci><open-source>
Title: What are the security risks of CD in an open source project?
UserDisplayName: Moritz
ThreadText: # What are the security risks of CD in an open source project?
  
  (Asked by: username_0 on 2018-02-17)
  
  In the processes of setting up continuous deployment for an open source project with Travis I came across a predicament, can the encrypted private key be easily exfilitrated? For context, the deployment workflow is:
  
  1. In a Travis build job, build and test code
  2. If it passes, deploy the code
  3. Decrypt the encrypted private SSH key and start the SSH client
  4. Push to the Git remote on the production server
  
  Using `travis encrypt-file deploy_rsa --add`, the private key is encrypted and only decryptable within the Travis build job. Am I correct in the assumption that someone forking the repo and creating a Travis build job will not be able to decrypt the key? In addition, the **only attack vector** would be for someone with push rights to modify the `.travis-ci` script to decrypt the key and send it to themselves?
  
  **Tags:** continuous-deployment, travis-ci, open-source
  
  > **Comments:**
  > **username_1**: Fork, add a dump of the key somewhere in the build, make a pull request, if pull requests are built the key will be shown in the public build log of Travis...  
  > **username_0**: This is not the case, at least for Travis https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions  
  > **username_1**: So you have your answer :) (but the Travis-ci file is still not the only attack vector for someone allowed to push)  
  > **username_0**: What else should I consider?  
  > **username_1**: Whatever build system is used, scripts, even the code could exfil datas during unit tests, usually that's not a real concern on open source projects and/or build and deploy are separated. Some quality test of code (sonar/checkmark) can test for suspicious patterns also  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2019-10-31. Score: 1 | Accepted answer
  
  You essentially have three threats here:
  
  1. Someone could modify `.travis-ci` and use that to exfiltrate the unencrypted key material.
  2. You could accidentally check-in or publish the decrypted key material as part of your release process.
  3. Someone could attempt to attack the encrypted key-material directly; this is very unlikely given modern practice and current computing power.
  
  The challenge of secret management is common in open source projects; one approach I have taken in the past is to have a second "deploy" stage in a private repository and pipeline. A private repository and pipeline, then ring-fences the sensitive data from malicious actors entirely, protecting yourself from 1 and 3. You can safeguard against two by whitelisting files that can be checked in to decrease the probability of making a mistake.
  
  Finally, an approach that can be used to increase the detectability of an attack is to store the key in [AWS CloudHSM](https://aws.amazon.com/cloudhsm/), [Google Cloud HSM](https://cloud.google.com/hsm/) or [Azure KeyVault](https://azure.microsoft.com/en-gb/services/key-vault/) with the goal of marking the private key as *non-exportable* and then handing off any encrypt, wrap or sign requests to the cloud. This means even if the credentials for the HSM/KeyVault do get exfiltrated you know every time they are used to sign something and can effectively revoke access to the key entirely. Unfortunately, there doesn't seem to be any way of doing this with SSH keys at the moment, however, it works will with code-signing certificates.
  
  
  ---
  
  