+I-SB-A Stream A: Build Process
---+I-SB-1-A Define a consistent build process
---+I-SB-2-A Automate the build process
---+I-SB-3-A Enforce a security baseline during build

I-SB-A Stream A: Build Process

A consistent build process ensures the software you are deploying is predictable and directly linked to the source code. Furthermore, you can take advantage of the software build process for various security activities.

1. Prezentare generală

I-SB-1-A Define a consistent build process

Maturity level 1 objective of the practice: Build process is repeatable and consistent.

Benefit: Limited risk of human error during the build process, minimizing security issues

Short description: Create a formal definition of the build process so that it becomes consistent and repeatable.

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.

Results

  • result1
  • result2

Metrics

  • metric1
  • metric2

Costs

TBS.

Personnel

  • Developer
  • Security Engineer
I-SB-2-A Automate the build process

Maturity level 2 objective of the practice: Build process is optimized and fully integrated into the workflow.

Benefit: Efficient build process with integrated security tools

Short description: Automate your build pipeline and secure the used tooling. Add security checks in the build pipeline.

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.

Results

  • result1
  • result2

Metrics

  • metric1
  • metric2

Costs

TBS.

Personnel

  • Developer
  • Security Engineer
I-SB-3-A Enforce a security baseline during build

Maturity level 3 objective of the practice: Build process helps prevent known defects from entering the production environment.

Benefit: Assurance that you build software complying with a security baseline

Short description: Define mandatory security checks in the build process and ensure that building non-compliant artifacts fails.

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.

Results

  • result1
  • result2

Metrics

  • metric1
  • metric2

Costs

TBS.

Personnel

  • Developer
  • Security Engineer

1.1 Referințe

1.2 Cerințe identificate

1.3 Reglementări asociate

2. Cerințe identificate

Cerințe

3. Reglementări asociate

Reglementări
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.