Model | Implementation | Secure Build
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.
| Maturity level | Stream ABuild Process | Stream BSoftware Dependencies | |
|---|---|---|---|
| 1 | Build process is repeatable and consistent. | Create a formal definition of the build process so that it becomes consistent and repeatable. | Create records with Bill of Materials of your applications and opportunistically analyze these. |
| 2 | Build process is optimized and fully integrated into the workflow. | Automate your build pipeline and secure the used tooling. Add security checks in the build pipeline. | Evaluate used dependencies and ensure timely reaction to situations posing risk to your applications. |
| 3 | Build process helps prevent known defects from entering the production environment. | Define mandatory security checks in the build process and ensure that building non-compliant artifacts fails. | Analyze used dependencies for security issues in a comparable way to your own code. |