Editions and Pricing explained

This page explains how the quotas and features of all SignPath Editions.

Quotas

Code signing certificates

What is the advantage of Extended Validation (EV) code signing certificates?

EV certificates are considered more trustworthy because they

• they require stricter identity checks by the certificate authority (CA)
• are only issued on secure hardware (USB token or HSM)

For non-EV certificates, Windows will warn users about new and newly re-issued certificates.

This does not happen with EV certificates, since they start with full reputation for Microsoft SmartScreen. You will also need EV certificates to sign Windows drivers.

What are test certificates used for?

You may create any number of self-signed test certificates and assign them to signing policies. These are used for test-signing your projects.

Test-signing is used to avoid the security implications of release-signing with EV certificates, which

• to test your signing configuration (especially artifact configurations) without the (which would be )

Projects

Code Signing Starter and Code Signing Basic are priced based on the number of projects you can create in SignPath. Choose the number of projects you need when you buy your subscription, or upgrade later. If you need more than max. projects, you need to upgrade to another the subscription type.

We recommend to use one SignPath project for each actual software project.

If your project produces several artifacts, you have these options to handle them with a single SignPath project:

• Use deep signing: Sign an installer and the files it contains
• Package your artifacts into a ZIP archive: Sign all artifacts that result from a single build job in one step
• Use multiple artifact configurations within one project (not available for Code Signing Starter)

Users

Code Signing Starter and Code Signing Basic are priced based on the number of active user accounts. Choose the number of users you need when you buy your subscription, or upgrade later. If you need more than max. users, you need to upgrade to another subscription type.

User accounts are required for all interactions with the SignPath user interface, including

• manual upload and approval of signing requests
• administration of your SignPath organization and projects
• checking the status of signing requests
• creating reports
• receiving notifications

This quota does not limit the number of CI user accounts or build agents you can use.

Signing requests

Code Signing Starter and Code Signing Basic have an upper limit for the number of signing requests.

Included signing requests per year and project:

Example: a Code Signing Basic subscription with 3 projects allows you to complete

• 150 release-signing requests per year (50 × 3)
• 750 test-signing requests per year (250 × 3)

The signing requests quota can be used freely between projects. You may upgrade the available projects of your subscription to get more signing requests per year.

How many signing requests will I need?

We recommend that you create one signing request per release of your software. This makes it easier to integrate with CI systems, use security-enhancing artifact configurations, and track your signining requests.

• Consider packing your artifacts into a single ZIP archive for signing
  • if your software consist of multiple artifacts (e.g. several EXE and DLL files)
  • if you produce several variants of your software for each release (e.g. runtime environments, processor architectures, customer variants)
• Consider using deep signing if you produce packages in supported formats such as MSI installers

Individual signatures

Each signed file inside a signing request counts towards the individual signatures quota.

• Example: an MSI file containing 1 EXE and 2 DLL files would result in 4 individual signatures.

You may sign up to 100 files per available signing request (i.e. the sum of release- and test-signing requests).

• Example: 900 signing requests are available in the previous example (150 + 750). That would result in 900 × 100 = 90,000 individual signatures per year.

You can adjust the artifact configuration to specify which files should be signed.

CI pipelines

Code Signing Starter: one CI pipeline at a time.

Code Signing Basic: one CI pipeline per available project at a time.

Additional signing requests submitted from CI pipelines may be rejected and have to be repeated later.

Signing methods and file types

SignPath directly supports signing various file formats. See the artifact configuration reference for details about available signing methods and file types.

Microsoft Office macros

Available for Advanced Code Signing.

Sign Office macros to protect against macro malware.

With a policy-based code signing process, you can sign your company’s Office macros for internal and/or external use. As an immediate benefit, you can disable execution of unsigned macros, thus preventing macro viruses and other macro-based malware deterministically.

See Office macros for more information.

XML Signing

Available for Advanced Code Signing.

SignPath supports signing XML files using XMLDSIG.

See artifact configuration for details.

Container image signing

Available for Advanced Code Signing, Open Source Code Signing.

SignPath supports signing Docker container images and tags using cosign and Docker Content Trust (DCT). See Signing Container Images for details.

Bills of Material

Available for Advanced Code Signing.

Sign Bills of Material (BOM) in the Cyclone DX XML format. This includes

• Software Bill of Materials (SBOM)
• Software-as-a-Service Bill of Materials (SaaSBOM)
• Hardware Bill of Materials (HBOM)
• and others

See this artifact configuration sample for details.

Crypto providers and hash signing

Available for Code Signing Gateway.

Use SignPath cryptographic providers with any code signing tool that supports either of these interfaces:

Note that with hash-based signing, artifacts are not transferred to and signed by the SignPath application, but locally on the user machine or build agent. The signing operation is always executed synchronously, typically through one of the cryptographic providers listed above.

Advanced usage scenarios

Certain features are not available for hash-based signing with these cryptographic providers. However, they may be used in certain scenarios when directly using SignPath REST APIs. Contact SignPath Support for more information.

• Signing multiple files in a single signing request
• User-defined parameters
• Manual approval
• Origin verification
• Build and source code policies

Artifact configuration

Artifact configurations define what artifacts to sign and how. They can either simply define the file type, or they can be detailed specifications of complex artifacts that contain other (nested) artifacts. See setting up projects for details.

Deep signing

Sign installers, packages etc. and their content in a single step. See signing nested artifacts

Multiple versions

Available for Code Signing Basic, Advanced Code Signing, Code Signing Gateway, Open Source Code Signing.

Create multiple artifact configurations for

• projects that create different artifact at different times, but you want to use the same signing policies
• artifact configurations that change significantly over time (versioning)

Metadata constraints

Available for Advanced Code Signing. Required for Open Source Code Signing.

You can restrict some file attributes in the artifact configuration.

This is useful if you want to

• enforce metadata policies (signed binaries must use consistent publisher metadata)
• avoid unintentional signing of third-party components
• defend against unauthorized signing (while this can be circumvented by aware parties, the attempt is reported and can be investigated)

User-defined parameters

Available for Advanced Code Signing, Code Signing Gateway, Open Source Code Signing.

You can define parameters for each signing request.

Use this to

• create more restrictive artifact configurations
• track arbitrary values across signing requests
• include build-time values

Policy enforcement

Manual approval

Available for Code Signing Basic, Advanced Code Signing, Code Signing Gateway. Required for Open Source Code Signing.

Specify that one or more approvals are required before a signing request is processed.

This is typically used for release-signing. Note that origin verification allows to create secure signing policies without manual approval.

Quorum approval

Available for Advanced Code Signing, Code Signing Gateway, Open Source Code Signing.

You may also specify that a certain number approvals is required (a.k.a. k-out-of-n approval).

See approval process for more information about manual approval.

Signing policies per project

For Code Signing Starter and Code Signing Basic, you get two signing policies per project:

• a test-signing policy for testing the signing configuration and signing test builds
• a release-signing policy for signing builds that will be delivered to end users

Advanced Code Signing and Code Signing Gateway allow to define any number of singing policies per project. You can use this to create policies with different levels of manual and automatic verification.

Example:

• test signing without verification, using a test certificate
• pre-release signing with origin verification, using a certificate that is recognized by QA devices
• release signing with origin verification and a constraint on release branches only
• exception release signing with origin verification, no branch constraints, but manual approval instead
• emergency signing without origin verification, but manual approval with 3 required approvals

See code signing certificates.

Resubmit

Available for Advanced Code Signing, Open Source Code Signing.

Resubmit signing requests for signing using different policies and/or certificates.

This can be used to sign release candidates with test certificates at first, and re-sign them with release certificates once they have been tested and approved for release.

See signing code.

Certificate policies

Available for Advanced Code Signing, Code Signing Gateway. Required for Open Source Code Signing.

Specify that certain validation criteria must be enabled for specific certificates. This enforces these policies for all projects end their respective signing policies.

See managing certificates.

Pipeline Integrity

Origin verification

Available for Advanced Code Signing, Code Signing Gateway. Required for Open Source Code Signing.

When a CI build is submitted to SignPath, certain metadata will be retrieved and verified by SignPath. This includes

• source code repository
• repository branch
• source code commit
• build information

Verification ensures that a person or system with knowledge of the API token cannot simply submit an unauthorized signing request.

Origin verification enables the most advanced level of code signing security. Even without origin verification, SignPath prevents many attack vectors using a combination of authentication and permissions, artifact configurations and constraints, malware scanning, notifications, and auditing. However, as soon as somebody gets access to the CI user token, security cannot be guaranteed.

Origin verification traces a software build back to the original source code, making it virtually impossible to sign unauthorized code.

For full security, make sure

• that the source code repository is the single source of truth for software builds, including build scripts and CI configurations
• that all upstream components are signed by their publishers, and signatures are verified
• that your repository and CI infrastructure is secure

See origin verfication for more information.

Origin-based policies

Specify the source code repository for a SignPath project, and (optionally) the branch name(s) for a signing policy. This ensures that only software from legitimate builds of these repositories can be signed using this policy.

Manual origin verification

When using manual approval on top of origin verification, approvers will have reliable information to base their decisions on. Also, they can be sure that builds will not even be presented for approval if they don’t meet the policy requirements.

Build validation

For some CI systems, SignPath offers connectors that can validate software builds for security. This ensures that development teams do not use or enable inherently insecure mechanisms in their release build configurations. Insecure practices include caching on build nodes, interactive access to build nodes, ad-hoc build configuration changes and more.

SCM and CI policy control

For some CI systems, SignPath allows defining detailed policies for Source Code Management (SCM) and CI/CD policies. You can set requirements for branch protection, build agents and other properties per signing policy.