ESF Securing the Software Supply Chain. Recommended Practices for Developers

Does your release confirmation that binaries are digitally signed?

Final packages including the correct metadata should be signed by a cryptographically-secure signature algorithm before being uploaded to the repository.

Reference: ESF - Securing the Software Supply Chain - Recommended practices for Developers - 2.5.2 Potential Tactics to Compromise the Software Packages and Updates

Final packages may be compromised while going through the distribution system from the supplier to the customer. An adversary may attempt a man-in-the-middle attack or compromise the source code repository. As a result, malware or vulnerabilities can be introduced to the package, or an older version of the package containing an exploitable vulnerability can be delivered to the customer. Installing the compromised packages will impose risk to the customer organization and its system.

This check looks for the following filenames in the project’s last (five) releases: *.minisig, *.asc (pgp), *.sig, *.sign.

Generate and publish a signing key, if not done already.

The project should not have generated executable (binary) artifacts in the source repository, only the source code should be integrated into the build environment.

Reference: ESF - Securing the Software Supply Chain - Recommended practices for Developers - 2.3.2 Selection and Integration

Including generated executables in the source repository increases user risk. Many programming language systems can generate executables from source code (e.g., C/C++ generated machine code, Java .class files, Python .pyc files, and minified JavaScript). Users will often directly use executables if they are included in the source repository, leading to many dangerous behaviors.

Problems with generated executable (binary) artifacts:

The check is reported when there is a single binary executable file in the source repository for the project.

Are code check-ins gated by code collaborators and source control to prevent anyone from accidentally or intentionally submitting unreviewed code changes?

As part of a check-in process, once of the control is to allow no code that has not been peer or lead reviewed to be checked-in to a source control repository.

Reference: ESF - Securing the Software Supply Chain - Recommended practices for Developers - 2.2.1 Modification or Exploitation of Source Code by Insiders

Fundamental to the protection of the source code repository and its contents are the methods used to control access to it and the validation process used to ascertain whether a check-in is “good.” Access and validation start with good source code management (SCM) principles to track modifications to a source code repository.

The configuration specifies the minimal protection rules that must be enabled on the configured branches to pass this checkpoint:

Follow the instructions to add protected branches rules in GitHub, GitLab or BitBucket.

Please note that in certain special cases the rules may need to be suspended. For example, if a past commit includes illegal or critical content, it may be necessary to use a force push to rewrite the history rather than simply hide the commit.

For fetching certain protection rules for branches, this checkpoint may need administrative access to the target repository. If the access token provided does not have administrator role, and the associated protecting rule is required for the checkpoint, the checkpoint will not be given a "pass" state, as the status of protection rule cannot be determined.

Does the team require code reviews for all code and build scripts / configuration changes?

This check determines whether the project requires code review before pull requests (merge requests) are merged.

Reference: ESF - Securing the Software Supply Chain - Recommended practices for Developers - 2.2.1 Modification or Exploitation of Source Code by Insiders

Reviews detect various unintentional problems, including vulnerabilities that can be fixed immediately before they are merged, which improves the quality of the code.

Reviews may also detect or deter an attacker trying to insert malicious code (either as a malicious contributor or as an attacker who has subverted a contributor’s account), because a reviewer might either detect the subversion, including any attempts made by the attacker to obfuscate malicious code or implant an evil dependency.

Lack of code review increase the risk of unintentional vulnerabilities or possible injection of malicious code.

The check first tries to detect whether Branch-Protection is enabled on the default branch with at least one required reviewer or by requiring Approvals from Code Owners. If this fails, the check determines whether the most recent commits have an approved review or if the merger is different from the committer (implicit review). It also performs a similar check for reviews using Prow (labels "lgtm" or "approved") and Gerrit ("Reviewed-on" and "Reviewed-by").

This check tries to determine if the project runs tests before pull requests are merged.

Reference: ESF - Securing the Software Supply Chain - Recommended practices for Developers - 2.4.2 Reproducible Builds

Running tests helps developers catch mistakes early on, which can reduce the number of vulnerabilities that find their way into a project.

The check works by looking for a set of CI-system names in GitHub CheckRuns and Statuses among the recent commits. A CI-system is considered well-known if its name contains any of the following: appveyor, buildkite, circleci, e2e, github-actions, jenkins, mergeable, test, travis-ci.

Current implementation is limited to repositories hosted on GitHub and Bitbucket, with other systems under development.

Does the project use tools to help update its dependencies?

This check tries to determine if the project uses a dependency update tool. These tools automate the process of updating dependencies by scanning for outdated or insecure requirements, and opening a pull request to update them if found.

Reference: ESF - Securing the Software Supply Chain - Recommended practices for Developers - 2.2.2 Open Source Management Practices

Out-of-date dependencies make a project vulnerable to known flaws and prone to attacks.

There are both open-source and commercial tools available for Software Composition Analysis (SCA) for the process of identifying potential areas of risk from the use of third-party software components.

Dependency Update tools automate part of the dependency-update process by integrating with the SCM, detecting out-of-date or vulnerable dependencies, and creating a pull request with the change in project dependencies descriptors, that could be accepted for merge.

The check looks for well-known tools in use, specifically dependabot, renovatebot, Depfu, Dependencies.io and Dependaroo.

For GitHub, see instructions for dependabot or renovatebot.

There are many ways to implement dependency updates, and it is challenging for an automated tool to detect them all. A FAIL status is therefore not a definitive indication that the project is at risk.

Do you perform binary composition analysis of the final package?

Binary software composition analysis tools can investigate what exactly is included in the final deliverables and identify potential issues in the final packages.

Reference: ESF SECURING THE SOFTWARE SUPPLY CHAIN. Recomended Practices for Developers - 2.5.1 Final Package Validation.

The final package or update to be delivered to a customer may have issues that expose the developer and customers to cybersecurity and privacy risks. For example, it may contain confidential information (e.g., hard coded credentials, personal data), open source software license issues, and components included in files with unknown origin. Moreover, the deliverable may have been built with improper compiler options or build settings.

The check looks for automatic scanning of packages in the release pipeline.

Ensure automatic scanning of packages for vulnerabilities is enabled at the release branch.

Set automatic scanning of packages for vulnerabilities at the release branch.

Do you perform input fuzzing as part of a regular process for your component or product’s inputs?

As part of the release readiness criteria a Fuzzing Test should be included.

Reference: ESF. Securing the Software Supply Chain: Recommended Practices for Developers - 2.1 Secure product criteria and management - Subsection Security test plans.

Fuzzing should be performed on all software components during development to ensure that they exhibit expected behavior with different inputs. Results should be documented, and any anomalies or vulnerabilities should be addressed

This check tries to determine if the project uses fuzzing by checking:

As fuzzers are more relevant for certain languages, the set of languages that should be considered by the check could be configured.

Example: for OSS-Fuzz over GitHub follow the instructions here.

There are many fuzzer tools and ways to run in the build and CI tools, and it is challenging for an automated tool to detect them all. A FAIL status is therefore not a definitive indication that the project is at risk.

This check verifies when a build and test job is currently active in pipeline configuration.

Reference: ESF - Securing the Software Supply Chain - Recommended practices for Developers - 2.2.1 Malicious Modification of Source Code - Subsection 3 Conduct nightly builds with security and regression tests

To ensure the integrity and quality of the development process, nightly builds should be performed that include manual and automated security and regression tests. Test cases should be implemented during the design of the software and extended during coding to validate all areas of functionality for both “good” and “bad” scenarios. Using this process, any flaws or changes, whether malicious or inadvertent, can be recognized and addressed.

The check looks for a scheduled pipeline in an hourly time range, that runs a build or compile command.

It is a standard practice to define a nightly build process for daily compiling and testing the software, and when possible to run security analyses to identify known vulnerabilities, secrets leaks, misconfigurations in the build/deployment tools or potential code tampering, etc.

Do you ensure only required modules are included in the product and “unused” modules and code out of scope of the requirements and design document are uninstalled or removed, mitigating “living off-the-land” attacks and decreasing the attack surface?

A project which is not active might not be patched, have its dependencies patched, or be actively tested and used. It might hold possibly unpatched vulnerabilities.

Reference: ESF - Securing the Software Supply Chain - Recommended practices for Developers - 2.2.1 Modification or Exploitation of Source Code by Insiders

It is important that all components and functionality of a product are architected and designed to interact with the system using secure design practices, including threat modeling and attack surface analysis. Once all security risks are identified and mitigated, architecture and design documents are finalized and disseminated to development groups for implementation.

Lowlevel design and functional specifications are created that map directly to the given architecture and high-level design, and development tasks and schedules are mapped out. During the coding and implementation of the system, care must be taken to ensure that all development efforts map to specific system requirements and that there is no “feature creep” that might compromise product integrity or inject vulnerabilities.

If the project is archived, it receives the lowest score with FAIL compliance.

The activity considered on the project during the previous period (of 90 days by default) is:

If the activity per week (number of commits or issue changes) exceeds the minimum activity threshold per week, the project receives a PASS with maximum score.

If the activity is below this threshold, the project receives a PARTIAL compliance.

There is no remediation work needed from projects not passing this checkpoint. The check simply provides insight into the project activity and maintenance commitment.

External users should determine whether the software is the type that would not normally need active maintenance.

Does the project use a static code analysis tool?

Before the integration of third-party components, each component must be evaluated for the potential security risk that might be associated with it. The evaluation includes reviewing and testing the software.

This check tries to determine if the project uses Static Application Security Testing (SAST), also known as static code analysis.

Reference: ESF SECURING THE SOFTWARE SUPPLY CHAIN. Recomended Practices for Developers (2.3.2).

SAST/DAST and other appropriate review such as composition analysis must be performed to determine if the risk is acceptable. Once determined, the source code (not binaries alone) should be integrated into the build environment allowing the security scanning processes of the build environment approved by the organization to take place. Whenever possible, images should be built from the source and not downloaded from the internet, unless there is an understanding of the provenance and trust of delivery.

Lack of SAST increase the risk of unknown bugs (and security vulnerabilities for the security-focused tools) in the delivered software.

The check looks for execution of known SAST tools in the recent merged PRs, or the usage of these tools in CI workflows.

Follow the instructions of the particular SAST tool for invocation in the project’s CI workflows.

There are many SAST tools and ways of invoking them, and it is challenging for an automated tool to detect them all. A FAIL result is therefore not a definitive indication that the project is at risk.

Do you have and use security tools for Software Composition Analysis?

Reference: ESF SECURING THE SOFTWARE SUPPLY CHAIN. Recomended Practices for Developers (2.3.2).

Automatic scanning for vulnerabilities detects known vulnerabilities in packages and dependencies in use, allowing faster patching when one is found. Such vulnerabilities can lead to a massive breach if not handled as fast as possible, as attackers will also know about those vulnerabilities and swiftly try to take advantage of them. Scanning packages regularly for vulnerabilities can also verify usage compliance with the organization’s security policy.

Gathering the dependencies graph and analyzing each dependency for vulnerabilities and other issues is named "Software Composition Analysis" or SCA. Tools that automate such analysis are called SCA tools.

Ensure automatic dependency scanning for vulnerabilities is enabled.

Add dependency scanning tool to pipeline.

Do you have and adhere to responsible disclosure requirements for all externally identified vulnerabilities?

Establish a vulnerability disclosure program, and make it easy for security researchers to learn about your program and report possible vulnerabilities.

Reference: ESF - Securing the Software Supply Chain - Recommended practices for Developers - 2.2.1 Malicious Modification of Source Code - Subsection 3 Conduct nightly builds with security and regression tests

At some point in the life of any software project, someone (a user, a contributor, or a security researcher) will find a vulnerability that affects the safety and usefulness of the software.

A security policy (typically a SECURITY.md file) can give users information about what constitutes a vulnerability and how to report one securely so that information about a bug is not publicly visible.

Such security policy should document at least:

This check works by looking for a file named SECURITY.md (case-insensitive) in a few well-known directories.

Do you use the toolchain to automatically gather information that informs security decision-making?

Use a tool that automate the collection of information about security decision making, the current state and changes that affect security at SDLC supply chain.

Reference: ESF SECURING THE SOFTWARE SUPPLY CHAIN. Build Chain Exploits (2.4.1).

Software Supply Chain security issues and attacks has been increased as the software release cycles time is reduced due to faster pace of business. A criteria for Secure Software Supply Chain should be define and use as part of the SDLC, in order to support the criteria an automation process to gather and validate current security state and security changes is required to implements that practice at scale and reduce human effort.

The check looks for execution of known Software Supply Chain Secure (SSCS) tools in the recent merged PRs, or the usage of these tools in CI workflows.

There are many SAST tools and ways of invoking them, and it is challenging for an automated tool to detect them all. A FAIL result is therefore not a definitive indication that the project is at risk.

SBOM (Software Bill of Materials) is a file that specifies each component of software or a build process. It should be generated after every pipeline run. After it is generated, it must then be signed. You can configure tools or run commands to check for workflows uses tools to verify this. The parameter are tools and commands.

The final package or update to be delivered to a customer may have issues that expose the developer and customers to cybersecurity and privacy risks.

A recommended mitigation is to run a binary scanning or composition analysis tool and ensure the integrity of its product before delivery. The tool can detect potential vulnerabitities and threats, then produce a SBOM of the final package for the customer.

For each pipeline, ensure it signs the Software Bill of Materials it produces on every run.

For each pipeline, configure it to sign its produced Software Bill of Materials on every run.

Do you track all third-party components you use directly and all internal components in a secure and persistent repository?

Both third-party and proprietary components must be stored and consumed from trusted repositories. That repositories should be placed internally if possible and be handle only by administrators.

Reference: ESF SECURING THE SOFTWARE SUPPLY CHAIN. Obtain Components from a Known and Trusted Supplier (2.3.3).

When the organization makes decisions concerning selection, use, changes, or updates of thirdparty or open-source software for its products, it should perform a risk assessment and ensure the residual risks are acceptable.

One key point related to store thirdparty, open source or internally develop components in a secure repository, and all artifacts were analyzed and determined if risk is acceptable before included.

For example, whenever possible, images should be built from the source and not downloaded from the internet, unless there is an understanding of the provenance and trust of delivery, then upload to internal secure repository to be consumed from application lifecycle.

Initially the check identify untrusted public repositories configure by default, it could be changed in checkpoint configuration file to add other public untrusted repositories, or add in trusted private repositories. When any private repository is declared, the public repository list does not take effect.

Following package managers and repositories are analyzed: