Documentation

SignPath aims to turn code signing into a controlled and repeatable process that aligns the needs of both development teams and InfoSec people.

While practices, tools and services for code signing usually focus on certificate management, there are also important process requirements. There are many recommendations, but they are hard and expensive to implement. SignPath addresses code signing from a process perspective. Our topmost priority is to make it easy to set up a code signing process that just works for development teams and is secure and auditable at the same time.

There is often a conflict of interests: development teams need to be responsive and productive and want InfoSec to get out of the way. On the other hand, InfoSec is responsible for minimizing the considerable risk associated with code signing and therefore need to get control over the process.

Developer priorities InfoSec priorities
  • Sign code so it will work for end-users
    • Installation of downloaded files
    • App store submissions
    • DevOps: Use application control/whitelisting on dedicated servers
  • Simplicity
    • Sign multiple artifacts in one final step
    • Including nested artifacts (e.g. programs contained in installers)
    • Tool support, clear error messages
  • Agility
    • Minimize overhead per release
    • Support release processes and branching models
  • Continuous integration (CI)
    • Simle integration with CI tools and services
    • No messing with complicated tools, dongles, certificate stores
    • Fully automated builds
  • Sign code so execution policies can be installed
    • Windows: WDAC Code Integrity or AppLocker
    • Third party whitelisting products
  • Control certificate issuance and renewal
    • Get certificates from commercial or in-house Certificate Authorities
    • Monitor validity periods
  • Private key security
    • Secure HSM key generation and storage
    • Create certificate signing requests
    • Prevent direct access to HSM
  • Ensure reliable signing methods
    • Only use secure algorithms and ciphers, strong keys
    • Always use time stamps
  • Constrain certificate usage for products and projects
    • Restrictions based on content
  • Enforce signing process through policies
    • Focus on policy definition, automate enforcement for individual signing requests
    • Define test- and release-signing policies per product/project
    • CA-issued certificates require stricter policies and monitoring than test certificates
    • Assign user roles for submission and approval
  • Full auditing and notifications
    • Audit data must retain to release process
    • Detect unusual activities

SignPath provides a simple model that meets the requirements of both parties. It's easy to set up and does not interfere with development processes, while at the same time providing full control for toe InfoSec team.

Setting up SignPath

Step Responsible Description
Create an organization InfoSec Register for a free trial (paid subscriptions coming soon)
Create or import certificates InfoSec
  • Create self-signed certificates for test-signing
  • Create Certificate Signing Requests (CSRs) and import certificates from a commercial Certificate Authority (CA) or an in-house CA.
  • Import existing certificates (potentially insecure)
  • Disable existing certificates
You will need at least two certificates (for test- and release-signing), but may choose to get different certificates for each product, customer, etc.
Invite users InfoSec
  • Invite other users to your team or organization
  • Create CI user accounts to integrate SignPath in your automated builds
Create projects Development Identify projects that need to be signed, restrict their content and define which elements need signing.
  • Multiple files can be signed in a single step (includes deep signing of nested artifacts)
  • The artifact configuration may be maintained by the development team and submitted to SignPath administrators when they change.
Create signing policies InfoSec For each project
  • Create at least a test-signing and a release-signing policy
  • Assign a certificate and user permissions to each signing policy
Integrate into CI builds Development Use our Powershell module or call our API for automatically submitting signing requests to SignPath. See Build system integration

See Key concepts for details about projects and signing policies.

Note that currently, all setup steps have to be performed using the Administrator role. This role might be assigned to InfoSec staff only, or shared with dedicated people from the development teams. If you aim for the highest security, we recommend giving this role only to InfoSec people and have them working directly with the development teams.

Using SignPath

Signing

There are two ways for submitting signing requests:

  • Use the Web application to submit artifacts for signing
    • Go to application dashboard
    • Select a project and signing policy
    • Upload a file
  • Use the PowerShell module or call our API

In any case, you will receive e-mail notifications for your request and be able to monitor them in the Web application.

Approval

For signing policies that require approval, each approver will receive an e-mail notification whenever an approval is requested. They can also review signing request waiting for their approval in the Web application.

Administration

Administrator will be notified about important events. They can also use the Web application to see a full activity audit for each entity, including users, certificates, projects and policies, and signing requests.


Last modified: 15. November 2018