Available for Advanced Code Signing, Code Signing Gateway. Required for Open Source Code Signing.
Abstract
Trusted build systems create a trust relationship between SignPath and certain systems used in your build pipeline. They are typically implemented as connectors and configured in SignPath.
Origin verification
The primary function of trusted build systems is to serve as the foundation of origin verifcation. This feature allows build systems to provide reliable origin metadata with your signing requests, so that SignPath can execute advanced policies based on trusted information.
See origin verifcation for details.
Direct use
Trusted build systems can also be used to simply restrict signing to certain build systems. Use them to make sure that certain signing policies and certificates can only be used from build agents with specific properties.
See below for details.
Supported build systems
The following build systems are currently supported by SignPath:
Generic support for any build system is available with the Double Authentication Proxy.
Configuration
To add a trusted build system to your SignPath organization:
- go to the Trusted Build Systems page (top menu) and click Add custom or Add predefined.
- enter a name, slug and (optionally) description
- for custom Trusted Build Systems, remember the token that is created as a result
Custom Trusted Build Systems
The token that was generated must be used to configure the connector (see the connector documentation for the respective build system). You can now link this trusted build system to your projects.
To use a trusted build system in a project:
- open the project
- find the Trusted build systems section
- click Link
- select one of the trusted build systems of your organization
The build system can now be used to submit signing requests with origin metadata. A trusted build system is required for signing policies with origin verification enabled.
Direct use of trusted build systems
Possible policies include:
- Prevent root access: allow code signing only from build agents that don’t allow any build scripts to modify systems settings
- Prevent network access: guarantee that artifacts cannot be arbitrarily received from internet sources
- Restrict user access: don’t let development teams connect to the build agent, with or without administrative permissions (if you need build nodes with wider permission sets, consider separating the process of compilation and packaging from other steps such as running tests)
- Require current security policies: avoid misuse of recently restored or otherwise not up-to-date build agents
See the Double Authentication Proxy for a simple way to achieve this using machine certificate enrollment.