The Secure Build (SB) practice emphasises the importance of building software in a standardised, repeatable manner, and of doing so using secure components, including 3rd party software dependencies.
The first stream focuses on removing any subjectivity from the build process by striving for full automation. An automated build pipeline can include additional automated security checks such as SAST and DAST to gain further assurance and flag security regressions early by failing the build, for example.
The second stream acknowledges the prevalence of software dependencies in modern applications. It aims to identify them and track their security status in order to contain the impact of their insecurity on an otherwise secure application. In an advanced form, it applies similar security checks to software dependencies as to the application itself.
Overview
| Maturity 1 | Maturity 2 | Maturity 3 | |
|---|---|---|---|
| Objective | Build process is repeatable and consistent. | Build process is optimized and fully integrated into the workflow. | Build process helps prevent known defects from entering the production environment. |
Streams
A: Build Process
| Maturity 1 | Maturity 2 | Maturity 3 |
|---|---|---|
| Create a formal definition of the build process so that it becomes consistent and repeatable. | Automate your build pipeline and secure the used tooling. Add security checks in the build pipeline. | Define mandatory security checks in the build process and ensure that building non-compliant artifacts fails. |
B: Software Dependencies
| Maturity 1 | Maturity 2 | Maturity 3 |
|---|---|---|
| Create records with Bill of Materials of your applications and opportunistically analyze these. | Evaluate used dependencies and ensure timely reaction to situations posing risk to your applications. | Analyze used dependencies for security issues in a comparable way to your own code. |