<p>From what I can see you have done everything correctly, you have stored both the certificate material (i.e. the PFX) and the password for the PFX in a secure location that presumably no one else can access.  Assuming you don't give anyone else permissions on your Azure tenant and you don't blindly accept pull requests that change <code>azure-pipelines.yml</code> then you are in a good place.</p>

<p>If you are feeling paranoid, then you could create a second pipeline using a private repository that is triggered when the previous pipeline completes successfully.  However, IMHO, I would carefully consider the risk you are exposing yourself to against the complexity and fragility of trying to tie two pipelines together.</p>

CC BY-SA 4.0
2019-07-31T22:20:41.027Z
Thank you, I have determined I will add the code signing process to **azure-pipelines.yml** for now. I couldn't see how this would pose any risk given I alone manage the project but my paranoia probably comes from my day job in secure software development.
Jason Bayldon
CC BY-SA 4.0
2019-07-31T19:45:35.867Z
2019-07-31T19:45:35.867Z
Richard Slater
<p>I own a public and open-source Windows Forms/C# application in a Github repo that I want to start code signing with my certificate through Azure Pipelines CI.  I have set up my pipeline and it is building fine, the next step is to integrate automatic code signing, which until this point I have been doing manually. I have taken the following steps:</p>

<ul>
<li>Certificate has been added to Secure File storage</li>
<li>Code Signing Extension Installed <a href="https://marketplace.visualstudio.com/items?itemName=stefankert.codesigning" rel="nofollow noreferrer">https://marketplace.visualstudio.com/items?itemName=stefankert.codesigning</a></li>
<li>Task variables have been created and marked as secret</li>
</ul>

<p>After adding a task, the YML generating is:</p>

<pre><code>- task: codesigning@2
  inputs:
    secureFileId: '$(certName)'
    signCertPassword: '$(certPass)'
    files: '**/*.exe'
    timeServer: 'http://timestamp.digicert.com'
    hashingAlgorithm: 'SHA256'
</code></pre>

<p>So, saving this, it is obviously going to update my <strong>azure-pipelines.yml</strong> in my repository. Is it possible to perform code signing in Azure Pipelines without exposing any information in the repository?  Is this considered best practice for code-signing in Azure Pipelines?</p>

CC BY-SA 4.0
2019-07-31T19:50:48.897Z
Hey - incidentally, it would be worth posting how many users download your application as this materially affects the risk assessment; i.e. if you get 100,000 downloads a month then your application is a might greater target of attacks.  If You get much less than that it's probably not enough of a target for an attacker to try and compromise your pipeline.  I really like this question because you are demonstrating two good practices merged together, those being code signing and CI/CD - well done.
Richard Slater
CC BY-SA 4.0
2019-07-31T22:10:41.327Z
@RichardSlater My application has typically less than 100 downloads per month, it is not that popular of a repository, but I wish to put the security of my project and userbase first and foremost.
Jason Bayldon
<azure-devops><azure><azure-pipelines>
Storing Code Signing Certificate
Jason Bayldon
# Storing Code Signing Certificate

(Asked by: username_0 on 2019-07-31)

I own a public and open-source Windows Forms/C# application in a Github repo that I want to start code signing with my certificate through Azure Pipelines CI.  I have set up my pipeline and it is building fine, the next step is to integrate automatic code signing, which until this point I have been doing manually. I have taken the following steps:

Certificate has been added to Secure File storage
Code Signing Extension Installed https://marketplace.visualstudio.com/items?itemName=stefankert.codesigning
Task variables have been created and marked as secret

After adding a task, the YML generating is:
- task: codesigning@2
  inputs:
    secureFileId: '$(certName)'
    signCertPassword: '$(certPass)'
    files: '**/*.exe'
    timeServer: 'http://timestamp.digicert.com'
    hashingAlgorithm: 'SHA256'

So, saving this, it is obviously going to update my azure-pipelines.yml in my repository. Is it possible to perform code signing in Azure Pipelines without exposing any information in the repository?  Is this considered best practice for code-signing in Azure Pipelines?

**Tags:** azure-devops, azure, azure-pipelines

> **Comments:**
> **username_1**: Hey - incidentally, it would be worth posting how many users download your application as this materially affects the risk assessment; i.e. if you get 100,000 downloads a month then your application is a might greater target of attacks.  If You get much less than that it's probably not enough of a target for an attacker to try and compromise your pipeline.  I really like this question because you are demonstrating two good practices merged together, those being code signing and CI/CD - well done.  
> **username_0**: @RichardSlater My application has typically less than 100 downloads per month, it is not that popular of a repository, but I wish to put the security of my project and userbase first and foremost.  

---

## 1 answers

### Answer by username_1 on 2019-07-31. Score: 2 | Accepted answer

From what I can see you have done everything correctly, you have stored both the certificate material (i.e. the PFX) and the password for the PFX in a secure location that presumably no one else can access. Assuming you don't give anyone else permissions on your Azure tenant and you don't blindly accept pull requests that change `azure-pipelines.yml` then you are in a good place.

If you are feeling paranoid, then you could create a second pipeline using a private repository that is triggered when the previous pipeline completes successfully. However, IMHO, I would carefully consider the risk you are exposing yourself to against the complexity and fragility of trying to tie two pipelines together.

> **Comments:**
> **username_0**: Thank you, I have determined I will add the code signing process to **azure-pipelines.yml** for now. I couldn't see how this would pose any risk given I alone manage the project but my paranoia probably comes from my day job in secure software development.  

---

