Secure Build

Business function
Implementation
Assigned to
Chris Cooper (chris.cooper@owasp.org)
Progress
40/100 40%

Short Description

This practice focuses on creating a consistently repeatable build process and accounting for the security of dependencies.

Long Description

The Secure Build 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

A: Build Process B: Software Dependencies
Maturity 1 - Build process is repeatable and consistent The build process is defined and consistent. All application dependencies are identified and documented
Maturity 2 - Build process is optimized and fully integrated into the workflow The build process is fully automated and does not require intervention by the developer. All components and dependencies are periodically reviewed for known security vulnerabilities and licensing issues
Maturity 3 - Build process helps prevent known defects from entering the production environment. Security defects may trigger the build to stop executing Components and dependencies are independently scanned for vulnerabilities

A: Build Process

Maturity 1

Benefit

Consistent and repeatable builds help developers focus on application-specific issues, and make it possible to automate builds in the future. This reduces the likelihood of human error during builds which can lead to security vulnerabilities.

Activity

Define the build process, breaking it down into a set of clear instuctions to either be followed by a person or an automated tool. The process is complete so that the person or tool can follow it consistently each time and produce the same result.

The process definition does not include any secrets (specifically considering those needed during the build process). Use individual credentials that authenticate, authorize, and account to access build tools, and code repositories. Include shared secrets only where you cannot avoid it, managing them with care, preferably via an encrypted password vault.

The build process is stored centrally and accessible to any tools or people who might need access. Do not store or distribute multiple copies, some of which may become outdated.

Review any build tools routinely, 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.

Questions

  • Do you use repeatable build processes?
    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
    Answer Options:
    • No - 0
    • Yes, for some applications - 0.25
    • Yes, for at least half of the applications - 0.5
    • Yes, for the majority of applications - 1

  • Do you sign artifacts produced during builds?
    Criteria:
    • Signing is documented in the build processes
    Answer Options:
    • No - 0
    • Yes, for some applications - 0.25
    • Yes, for at least half of the applications - 0.5
    • Yes, for the majority of applications - 1

Maturity 2

Benefit

A fully automated build system allows easy integration of automated security checks at all stages of the build process, and ensures separate but consistent build environments.

Activity

Implement the build process as an automated system, so that builds can be executed repeatedly and consistently. The build process is reliable and does not require developer intervention, further reducing the likelihood of human error.

Automation makes it easier to include security checks during the build process. Implement static application security testing (SAST) to run as part of the build process. Refer to guidance in Verification > Security Testing > A3.

The use of an automated system to setup the build pipeline increases reliance on the build tools for security, 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. Refer to Implementation > Secure Deployment > B.

Sign generated artifacts using a certificate that identifies the organization or business unit that built it, such that its integrity and can be verified later.

Questions

  • Are build processes automated?
    Criteria:
    • 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
    Answer Options:
    • No - 0
    • Yes, for some applications - 0.25
    • Yes, for at least half of the applications - 0.5
    • Yes, for the majority of applications - 1

Maturity 3

Benefit

You can enforce a minimal clear security baseline in production. You can automatically deploy compliant applications.

Activity

The build process includes automated security checks which break the build if they fail. Static Application Security Testing (SAST), with an appropriate and custom ruleset, is triggered each time the build process executes. Refer to guidance in Verification > Security Testing > A.

The organization sets an appropriate threshold for build failure based on the application’s risk appetite. For instance, “High” and “Critical” vulnerabilities, or those with a CVSS score above 7.0. The types of vulnerabilities that the organization consider unacceptable in a build and their typical scores/ratings are considered when setting this threshold. An application with more sensitive functions might have a lower threshold, for instance. Trigger warnings for vulnerabilities below the threshold, and log them to a centralized system to track them and take actions.

Put in place a mechanism to bypass this behaviour when a vulnerability has been accepted or mitigated to stop it from breaking the build. Carefully control and approve it, and log all exceptions with a rationale.

If any of the security tests like SAST are not carried out successfully, the build fails.

If technical limitations prevent the organisation from breaking the build automatically, achieve the same effect via other means, such as a clear policy for the developer not to deploy or execute a build with defects meeting certain criteria.

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. Compare the binary output with that from other equivalent build systems to ensure it hasn’t been tampered with.

Questions

  • Do you integrate automated security checks in build processes?
    Criteria:
    • You have a maximum accepted severity for vulnerabilties
    • You log warnings and failures in a centralized system
    • Build processes prevent deployment to production when security checks fail
    • You select and configure tools to evaluate each application against its security requirements
    Answer Options:
    • No - 0
    • Yes, for some applications - 0.25
    • Yes, for at least half of the applications - 0.5
    • Yes, for the majority of applications - 1

B: Software Dependencies

Maturity 1

Benefit

You know which production components are at risk from a known vulnerable 3rd party dependencies. Dependencies include 3rd party software dependencies and operating system dependencies. 3rd party dependencies often inculde more dependencies (called transitive dependencies).

Activity

Keep a record of all dependencies used throughout the target production environment. This is sometimes referred to as a Bill of Materials (BOM). In building these records, consider the various locations where dependencies might be specified: - configuration files - the project’s directory on disk - package management tool - code (e.g. via an IDE that supports listing dependencies)

Consider that the different dependencies and aspects of the application may consume entirely different dependencies. For example, if the software package is a web app, cover both the server-side application code and client-side scripts.

The records include the following information about each dependency:

  • Where it is used or referenced
  • Why it is required
  • Version used
  • License
  • Source information (link to repository, author’s name, etc.)
  • Open source or proprietary
  • Support and maintenance status of the dependency

Check the records, whenever practical, to discover any dependencies with known vulnerabilities and update or replace them accordingly.

Ensure that providers actively maintain dependencies, and that they deal with security vulnerabilities appropriately. Gain assurance when dealing with open source dependencies, either through agreements with a commercial vendor, or other means, for example, by looking at repository activity, and the developers’ responses to security issues raised by the community.

Questions

  • Do you evaluate security risk stemming from used dependencies?
    Criteria:
    • You have current bill of materials (BOM) for every application
    • You can quickly find out which applications are affected by a particular CVE
    • You have provably analyzed and addressed findings from dependencies at least once in the last three months
    Answer Options:
    • No - 0
    • Yes, for some applications - 0.25
    • Yes, for at least half of the applications - 0.5
    • Yes, for the majority of applications - 1

Maturity 2

Benefit

There is an audit trail of all 3rd party dependencies used in development and you know and track their security status at any given time.

Activity

Evaluate dependencies to establish a whitelist of acceptable code dependencies approved for use within a project, team, or the wider organization.

Alternatively, introduce a central repository of approved dependencies that all software must be built from.

Review dependencies regularly to ensure that:

  • they remain correctly licensed
  • no known and significant vulnerabilities are present
  • there is support and active maintenance for the dependency
  • there is a good business reason to include the dependency

You may need tools to automate some or all of this process, such as analyzing where the dependency is used, or checking for updates via a package manager. Consider using an automated tool to scan for vulnerable dependencies.

Questions

  • Is 3rd party dependency risk handled by a formal process?
    Criteria:
    • Dependencies are automatically evaluated for new CVEs
    • Above defined criticality threshold, responsible staff is alerted
    • License changes with possible impact on legal application usage are automatically detected and alerted
    • Usage of unmaintained dependencies is tracked and alerted
    Answer Options:
    • No - 0
    • Yes, for some applications - 0.25
    • Yes, for at least half of the applications - 0.5
    • Yes, for the majority of applications - 1

Quality Indicators

  • There is an automatically generated BOM for each software release
  • You can query the security status of all 3rd party dependencies anytime
  • There is a well-defined procedure for addressing vulnerabilities in 3rd party dependencies

Maturity 3

Benefit

The application’s security level is more indicative of its real security, by consistently assessing its 3rd party dependencies.

Activity

Perform verification tests against dependencies in the same way you do against the target application. Refer to Verification > Security Testing. Depending on the build process maturity level, the discovery of significant issues might cause the build to fail.

Log results centrally, triage and validate findings appropriately as described in Implementation > Defect Management. Vulnerable dependencies should be blacklisted and not permitted to be used during builds. Feed findings back to the vendor or open source project, following a set of ethical disclosure guidelines.

Questions

  • Do you prevent build of software if it's affected by vulnerabilities in dependencies?
    Criteria:
    • Your build system is connected to a system for tracking 3rd party dependency risk, causing build to fail unless the vulnerability is evaluated to be a false positive or the risk is explicitely accepted.
    Answer Options:
    • No - 0
    • Yes, for some applications - 0.25
    • Yes, for at least half of the applications - 0.5
    • Yes, for the majority of applications - 1

  • Do you analyze 3rd party code in a comparable way to your own code?
    Criteria:
    • You scan your dependencies using a static analysis tool
    • You report findings back to dependency authors using an established responsible disclosure process
    • Using a new dependency which has not been evaluated for security risk causes failing the build
    Answer Options:
    • No - 0
    • Yes, for some applications - 0.25
    • Yes, for at least half of the applications - 0.5
    • Yes, for the majority of applications - 1

Quality Indicators

  • You assess the security of important 3rd party dependencies. The dependencies are either flagged during a risk analysis or threat modelling, or are of high value to business
  • The organisation actively contributes security improvements to important 3rd party dependencies (testing, reports, features)
  • Security is an important factor during 3rd party dependency selection
  • Important 3rd party dependencies have an assigned owner within the organisation. For sufficiently important dependencies, the owner may also be the dependency’s champion
  • You use multiple intelligence feeds to track the security of 3rd party dependencies
  • There is an active policy to minimise the number of different versions of 3rd party dependencies