Model | Implementation | Secure Build | Build Process
Benefit
Limited risk of human error during build process minimizing security issues
Activity
Define the build process, breaking it down into a set of clear instructions to either be followed by a person or an automated tool. The build process definition describes the whole process end-to-end so that the person or tool can follow it consistently each time and produce the same result. The definition is stored centrally and accessible to any tools or people. Avoid storing multiple copies as they may become unaligned and outdated.
The process definition does not include any secrets (specifically considering those needed during the build process).
Review any build tools, ensuring that they are actively maintained by vendors and up-to-date with security patches. Harden each tool’s configuration so that it is aligned with vendor guidelines and industry best practices.
Determine a value for each generated artifact that can be later used to verify its integrity, such as a signature or a hash. Protect this value and, if the artifact is signed, the private signing certificate.
Ensure that build tools are routinely patched and properly hardened.
Question
Is your full build process formally described?
Quality criteria
You have enough information to recreate the build processes |
Your build documentation up to date |
Your build documentation is stored in an accessible location |
Produced artifact checksums are created during build to support later verification |
You harden the tools that are used within the build process |
Answers
No |
Yes, for some applications |
Yes, for at least half of the applications |
Yes, for most or all of the applications |
Benefit
Efficient build process with integrated security tools
Activity
Automate the build process so that builds can be executed consistently anytime. The build process shouldn’t typically require any intervention, further reducing the likelihood of human error.
The use of an automated system increases reliance on security of the build tooling and makes hardening and maintaining the toolset even more critical. Pay particular attention to the interfaces of those tools, such as web-based portals and how they can be locked-down. The exposure of a build tool to the network could allow a malicious actor to tamper with the integrity of the process. This might, for example, allow malicious code to be built into software.
The automated process may require access to credentials and secrets required to build the software, such as the code signing certificate or access to repositories. Handle these with care. Sign generated artifacts using a certificate that identifies the organization or business unit that built it, so you can verify its integrity.
Finally, add appropriate automated security checks (e.g. using SAST tools) in the pipeline to leverage the automation for security benefit.
Question
Is the build process fully automated?
Quality criteria
The build process itself doesn't require any human interaction |
Your build tools are hardened as per best practice and vendor guidance |
You encrypt the secrets required by the build tools and control access based on the principle of least privilege |
Answers
No |
Yes, for some applications |
Yes, for at least half of the applications |
Yes, for most or all of the applications |
Benefit
Assurance that you build software complying with a security baseline
Activity
Define security checks suitable to be carried out during the build process, as well as minimum criteria for passing the build - these might differ according to the risk profiles of various applications. Include the respective security checks in the build and enforce breaking the build process in case the predefined criteria are not met. Trigger warnings for issues below the threshold and log these to a centralized system to track them and take actions. If sensible, implement an exception mechanism to bypass this behavior if the risk of a particular vulnerability has been accepted or mitigated. However, ensure these cases are explicitly approved first and log their occurrence together with a rationale.
If technical limitations prevent the organization from breaking the build automatically, ensure the same effect via other measures, such as a clear policy and regular audit.
Handle code signing on a separate centralized server which does not expose the certificate to the system executing the build. Where possible, use a deterministic method that outputs byte-for-byte reproducible artifacts.
Question
Do you enforce automated security checks in your build processes?
Quality criteria
Builds fail if the application doesn't meet a predefined security baseline |
You have a maximum accepted severity for vulnerabilities |
You log warnings and failures in a centralized system |
You select and configure tools to evaluate each application against its security requirements at least once a year |
Answers
No |
Yes, for some applications |
Yes, for at least half of the applications |
Yes, for most or all of the applications |
Stream Guidance
- SAMM team guidance Google Doc
- Community guidance Google Doc
Want to contribute?
Complete this Google Form with guidance for this Stream.
To learn more about Stream guidance for the SAMM model, see the Stream guidance page.