docs(threat-model): supply chain threat model TF-A
Software supply chain attacks aim to inject malicious code into a
software product. There are several ways a malicious code can be
injected into a software product (open-source project).
These include:
- Malicious code commits
- Malicious dependencies
- Malicious toolchains
This document provides analysis of software supply chain attack
threats for the TF-A project
Change-Id: I03545d65a38dc372f3868a16c725b7378640a771
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
diff --git a/docs/threat_model/supply_chain_threat_model.rst b/docs/threat_model/supply_chain_threat_model.rst
new file mode 100644
index 0000000..386a4b0
--- /dev/null
+++ b/docs/threat_model/supply_chain_threat_model.rst
@@ -0,0 +1,760 @@
+TF-A Supply Chain Threat Model
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Introduction
+************
+
+Software supply chain attacks aim to inject malicious code into a software
+product. There are several ways a malicious code can be injected into a
+software product (open-source project). These include:
+
+- Malicious code commits: This attack directly injects code into a project
+ repository. This can happen for example through developer/maintainer
+ credential hijacks, or malicious external contributors.
+
+- Malicious dependencies: In this case malicious code is introduced into a
+ project through other piece of code or packages the project depends on. This
+ can happen through for example typosquatting attack where an attacker creates
+ a malicious package with a very similar name to a popular package and hosts
+ it on popular package repositories.
+
+- Malicious toolchains: This involves malicious code introduced by compromised
+ resources used throughout the development and/or build process such as
+ compilers and IDEs.
+
+This document provides analysis of software supply chain attack threats for the
+TF-A project.
+
+TF-A Overview
+*************
+
+Figure 1 shows the different software components surrounding the TF-A project.
+A brief description of each component is provided below.
+
+TF-A Repository
+===============
+
+The TF-A repository contains generic and platform code contributed by TF-A
+contributors as well as libraries imported from other open-source projects,
+referred to as internal dependencies on Figure 1. These libraries include:
+
+- *libfdt*: libfdt is a utility library for reading and manipulating Device
+ Tree Binary (DTB) files. It is part of the Device Tree Compiler (DTC)
+ toolchain [1]_. DTC is used as part of the build process on the host machine
+ to build DTB files. libfdt is used to parse the DTB files at boot time.
+
+- *zlib*: zlib is a data compression library imported from [2]_.
+
+- *compiler-rt*: This is a collection of runtime libraries from the LLVM
+ compiler infrastructure project [3]_. We import the builtins library which
+ provides low-level, target-specific compiler builtins from compiler-rt.
+
+The TF-A repository also includes source code for host tools that supplement
+the TF-A build process. These tools include:
+
+- *fiptool*: This tool is used to create a Firmware Image Package (FIP) which
+ allows for packing bootloader images into a single archive that can be
+ loaded by TF-A from non-volatile platform storage.
+
+- *cert_create*: This tool is used to generate certificates for binary images.
+
+- *encrypt_fw*: This tool takes the plain firmware image as input and generates
+ the encrypted firmware image which can then be passed as input to the fiptool
+ utility for creating the FIP.
+
+- *sptool*: This tool is used to build the secure partition packages.
+
+|TF-A System Diagram|
+*Figure 1: TF-A System Diagram*
+
+External Dependencies
+=====================
+
+These are software components that are not part of the TF-A repository but are
+required to build TF-A binaries and host tools.
+
+- *Mbed TLS Library*: This is a cryptography library from trustedfirmware.org
+ (tf.org). It is required to build TF-A binaries where cryptography features
+ are needed, such as Trusted Board Boot (TBB).
+
+- *OpenSSL Library*: This is another cryptography library used by TF-A host
+ tools: fiptool, cert_create, and encrypt_fw.
+
+The following table lists TF-A dependencies including the sources of the
+dependencies.
+
+.. table:: Table 1: TF-A Dependencies
+
+ +-------------+------------------------+------------------------------------+
+ | Dependency | Location of Dependency | Original Source |
+ +=============+========================+====================================+
+ | libfdt | Local copy | [1]_ |
+ +-------------+------------------------+------------------------------------+
+ | zlib | Local copy | [2]_ |
+ +-------------+------------------------+------------------------------------+
+ | compiler-rt | Local copy | [3]_ |
+ +-------------+------------------------+------------------------------------+
+ | Mbed TLS | External | [4]_ |
+ +-------------+------------------------+------------------------------------+
+ | OpenSSL | External | [5]_ |
+ +-------------+------------------------+------------------------------------+
+
+Supplementary Binaries
+======================
+
+These are binaries used to test TF-A based systems. Below is a brief
+description of each component and where they are sourced from.
+
+- *SCP-firmware*: For our tests, we use SCP-firmware binaries supplied by the
+ Arm SCP team built from the source from the GitHub repository [6]_.
+
+- *OP-TEE*: Trusted Execution Environment (TEE) from tf.org that runs as
+ Secure EL1. We use OP-TEE built from source or binaries supplied with Arm
+ Reference Platforms depending on the test configuration.
+
+- *EDK2 UEFI*: Normal world bootloader from the EDK2 project [7]_. We use EDK2
+ UEFI binaries hosted on tf.org servers for testing [8]_.
+
+Other software components used to test TF-A include U-Boot, Linux kernel, RSS,
+MCP, and file systems, all sourced from the Arm Reference Platforms teams.
+
+TF-A Toolchain
+==============
+
+The TF-A project uses several tools to build, analyze and test the TF-A source
+code.
+
+Node.js Tools
+-------------
+
+These are optional quality assurance and developer utility tools that are
+installed through the use of the Node.js package manager. They are pinned to
+specific versions described by the package.json file in the root of the TF-A
+repository, and their dependencies are downloaded from the internet at the
+point of installation. These tools may be installed locally on the developer
+machine and are installed within a Docker container in certain CI jobs. At
+present, these are:
+
+- Commitlint
+
+- Commitizen
+
+- Husky
+
+Infrastructure
+==============
+
+TF-A uses trustedfirmware.org (tf.org) and Arm infrastructures to host the
+source code, review code and run tests. Appendix A provides a security analysis
+of tf.org infrastructure.
+
+TF-A Data Flow
+**************
+
+Figure 2 below shows the data flow diagram for TF-A. The broken red lines
+indicate trust boundaries.
+
+|TF-A Data Flow Diagram|
+*Figure 2: TF-A Data Flow Diagram*
+
+Attack Tree
+***********
+
+|TF-A Attack Tree|
+*Figure 3: TF-A Attack Tree*
+
+Threat Assessment and Mitigations
+*********************************
+
+Impact and Likelihood Ratings
+=============================
+
+ +--------+------------------------------+-----------------------------------+
+ | Rating | Impact | Likelihood |
+ +========+==============================+===================================+
+ | HIGH | Major impact to entire | Threat is relatively easy to |
+ | | organization or single line | exploit by an attacker with |
+ | | of business if exploited. | little effort and skill. |
+ +--------+------------------------------+-----------------------------------+
+ | MEDIUM | Noticeable impact to line of | An expert attacker could exploit |
+ | | business if exploited. | the threat without much |
+ | | | difficulty. |
+ +--------+------------------------------+-----------------------------------+
+ | LOW | Minor damage if exploited or | Exploiting the threat would |
+ | | could be used in conjunction | require considerable effort and |
+ | | with other vulnerabilities | resources. |
+ | | to perform a more serious | |
+ | | attack. | |
+ +--------+------------------------------+-----------------------------------+
+
+Threats and Mitigations
+=======================
+
+Threat naming convention key
+
+- SC – Supply Chain
+
+- SRC – Source
+
+- DEP – Dependency
+
+- TOOL – Toolchain
+
+- REPO – Repository
+
+- MAIN – Maintainer
+
+- CONT – Contributor
+
+ +---------------------------------------------------------------------------+
+ | Threat: TFA-SC-SRC-MAIN-01 |
+ +=============+=============================================================+
+ | Description | An attacker can submit and merge malicious code by posing |
+ | | as a maintainer after compromising maintainers’ |
+ | | credentials. |
+ +-------------+-------------------------------------------------------------+
+ | Impact | HIGH |
+ +-------------+-------------------------------------------------------------+
+ | Likelihood | MEDIUM |
+ +-------------+-------------------------------------------------------------+
+ | Threat and | | In the TF-A code review process all submitted changes |
+ | impact | undergo review by a code owner and a maintainer. If the |
+ | | change is accepted, it will be merged (integrated) into |
+ | | an integration branch by a maintainer. A maintainer has |
+ | | the right to give a code owner review, a maintainer |
+ | | review and merge the submitted change. |
+ | | |
+ | | | tf.org users (including maintainers) are authenticated |
+ | | through GitHub. The likelihood of a credential compromise |
+ | | depends on multiple factors. The authentication mechanism |
+ | | of GitHub is strong if the recommended best practices are |
+ | | followed [9]_ making credential compromise unlikely. |
+ | | GitHub (therefore tf.org) allows logins with two-factor |
+ | | authentication, requiring both a password and access to |
+ | | the user's authentication code. Depending on the strength |
+ | | of the password and factors such as whether the |
+ | | maintainer reuses passwords across services, the |
+ | | likelihood of a compromise can be higher. |
+ | | |
+ | | | If an attacker manages to compromise a maintainer’s |
+ | | credentials, posing as the maintainer, they can in theory |
+ | | submit a malicious change (as a maintainer or as a |
+ | | contributor), give all the necessary reviews and merge |
+ | | the change. |
+ +-------------+-------------------------------------------------------------+
+ | Mitigations | | - Enforce best practices recommended by GitHub [9]_ |
+ | | |
+ | | | - Not allowing a committer to both self-review and merge |
+ | | patches they have submitted. To achieve the commit the |
+ | | attacker would be required to compromise at least two |
+ | | credentials (reviewers and maintainer). |
+ +-------------+-------------------------------------------------------------+
+ | Mitigations | We have not disallowed self-review/merge of patches |
+ | implemented?| |
+ +-------------+-------------------------------------------------------------+
+
+ +---------------------------------------------------------------------------+
+ | Threat: TFA-SC-SRC-MAIN-02 |
+ +=============+=============================================================+
+ | Description | An attacker can submit and merge malicious code after |
+ | | becoming a maintainer through social engineering |
+ | | techniques. |
+ +-------------+-------------------------------------------------------------+
+ | Impact | HIGH |
+ +-------------+-------------------------------------------------------------+
+ | Likelihood | LOW |
+ +-------------+-------------------------------------------------------------+
+ | Threat and | | According to the TF project maintenance process [10]_, |
+ | impact | maintainers of TF-A are selected by their peers based on |
+ | | merit. Some of the criteria of becoming a maintainer |
+ | | include being an active member of the project for a |
+ | | minimum duration and contributing a substantial number of |
+ | | non-trivial and high-quality patches. However, there are |
+ | | some weaknesses in the process: |
+ | | |
+ | | | - There is no structured mechanism to establish trust |
+ | | with a maintainer other than the recommendations by |
+ | | peers |
+ | | | - There is no continuous monitoring of the status of a |
+ | | maintainer (e.g. maintainer can move from one |
+ | | organization to another) |
+ | | |
+ | | | To perform such an attack, in addition to becoming a |
+ | | maintainer, an attacker also must deal with all |
+ | | restrictions put on maintainers. |
+ +-------------+-------------------------------------------------------------+
+ | Mitigations | | - Structured mechanism to establish trust with |
+ | | maintainers |
+ | | |
+ | | | - Not allowing a committer to both self-review and merge |
+ | | patches they have submitted. To achieve the commit the |
+ | | attacker would be required to compromise at least two |
+ | | credentials (reviewers and maintainer). |
+ +-------------+-------------------------------------------------------------+
+ | Mitigations | There is a structured mechanism to establish trust with |
+ | implemented?| maintainers, but self-review/merge of patches is not |
+ | | disallowed |
+ +-------------+-------------------------------------------------------------+
+
+ +---------------------------------------------------------------------------+
+ | Threat: TFA-SC-SRC-CONT-01 |
+ +=============+=============================================================+
+ | Description | An attacker can submit malicious code patch as a |
+ | | contributor. |
+ +-------------+-------------------------------------------------------------+
+ | Impact | HIGH |
+ +-------------+-------------------------------------------------------------+
+ | Likelihood | LOW |
+ +-------------+-------------------------------------------------------------+
+ | Threat and | | TF-A accepts external contributions to both the generic |
+ | impact | and platform code. Unlike maintainers, contributors do |
+ | | not have maintainer review or merging privileges, |
+ | | therefore the likelihood of injecting malicious code as a |
+ | | contributor is lower. However, even though unlikely, it |
+ | | is still possible for a malicious commit to go unnoticed |
+ | | through the code review and verification processes. |
+ | | |
+ | | | If successful, the impact can range from low to high |
+ | | depending on the injected code. For example, an attacker |
+ | | can potentially deliberately insert a memory corruption |
+ | | vulnerability that is hard to notice on code review and |
+ | | will not be detected by the verification process. This |
+ | | vulnerability by itself may have a low impact but can |
+ | | have a major impact if used in combination with other |
+ | | vulnerabilities. |
+ +-------------+-------------------------------------------------------------+
+ | Proposed | - Code review and verification |
+ | Mitigations | - Static analysis to try to pick up issues that typically |
+ | | end in some form of attack vector |
+ +-------------+-------------------------------------------------------------+
+ | Mitigations | Yes, contributions go through the thorough review, |
+ | implemented?| verification, and static analysis process automated through |
+ | | CI |
+ +-------------+-------------------------------------------------------------+
+
+ +---------------------------------------------------------------------------+
+ | Threat: TFA-SC-DEP-01 |
+ +=============+=============================================================+
+ | Description | An attacker can inject malicious code into TF-A internal |
+ | | dependencies. |
+ +-------------+-------------------------------------------------------------+
+ | Impact | HIGH |
+ +-------------+-------------------------------------------------------------+
+ | Likelihood | LOW |
+ +-------------+-------------------------------------------------------------+
+ | Threat and | | TF-A has two types of dependencies: those that are copied |
+ | impact | into the TF-A repository and shipped as part of TF-A code |
+ | | (referred to as *internal dependencies* here) and those |
+ | | that are downloaded from external repositories and used |
+ | | when building TF-A (referred to as |
+ | | *external dependencies* here). |
+ | | |
+ | | | Currently TF-A has three internal dependencies: *libfdt* |
+ | | [1]_, *zlib* [2]_ and *compiler-rt* [3]_ libraries. These |
+ | | libraries are periodically updated by copying them from |
+ | | their source repositories. Although unlikely, it is |
+ | | possible for a contributor to copy the libraries from the |
+ | | wrong (and potentially malicious) repositories. For |
+ | | example, there are already multiple forks of *libfdt* |
+ | | (DTC) on GitHub. In addition to this, the official |
+ | | repositories are not immune to threats described above |
+ | | (TFA-SC-SRC-MAIN-01, TFA-SC-SRC-MAIN-02 and |
+ | | TFA-SC-SRC-CONT-01). |
+ | | |
+ | | | The likelihood of an attack on TF-A through internal |
+ | | dependencies is lower than external dependencies for the |
+ | | following reasons: |
+ | | |
+ | | | - Internal dependencies go through the normal code review |
+ | | process during upgrade |
+ | | | - Once upgraded internal dependencies stay unchanged |
+ | | until the next upgrade. The upgrade window is typically |
+ | | long (for example *libfdt* has only changed 4 times |
+ | | over the past 4 years). This reduces the window of |
+ | | opportunity for an attacker to inject malicious code |
+ | | into the dependencies |
+ +-------------+-------------------------------------------------------------+
+ | Proposed | - Explicitly document versions and official sources of |
+ | Mitigations | dependencies |
+ | | - Keep a copy of a pinned version of the source code inside |
+ | | the TF-A tree so that the risk of getting malicious code |
+ | | from dependencies only arises when we upgrade them |
+ | | - Monitor alerts for vulnerable dependencies from GitHub |
+ | | [11]_ |
+ +-------------+-------------------------------------------------------------+
+ | Mitigations | Yes, we explicitly document versions and official sources |
+ | implemented?| of dependencies, keep a copy of pinned versions of the |
+ | | source code, and monitor alerts for vulnerable dependencies |
+ | | for Python and Node.js, but we aren't able to do this for C |
+ | | dependencies |
+ +-------------+-------------------------------------------------------------+
+
+ +---------------------------------------------------------------------------+
+ | Threat: TFA-SC-DEP-02 |
+ +=============+=============================================================+
+ | Description | An attacker can inject malicious code into TF-A external |
+ | | dependencies. |
+ +-------------+-------------------------------------------------------------+
+ | Impact | HIGH |
+ +-------------+-------------------------------------------------------------+
+ | Likelihood | MEDIUM |
+ +-------------+-------------------------------------------------------------+
+ | Threat and | | Unlike internal dependencies, external dependencies are |
+ | impact | downloaded from external repositories by end-users. |
+ | | Although the TF-A documentation provides information |
+ | | about the versions of dependencies used for testing and |
+ | | links to repositories, it is up to the end-user to decide |
+ | | where to get the dependencies from. As such, the |
+ | | likelihood of an attack through an external dependency is |
+ | | higher compared to an internal dependency. |
+ | | |
+ | | | The impact of an attack ranges from low to critical |
+ | | depending on which dependency and what part of the |
+ | | dependency is affected. For example, a malicious code |
+ | | that affects the signature verification functions in |
+ | | MbedTLS is considered critical as it can be used to |
+ | | bypass the TBB process of TF-A. |
+ +-------------+-------------------------------------------------------------+
+ | Proposed | - Explicitly document versions and official sources of |
+ | Mitigations | dependencies |
+ | | - Provide scripts and build options to automatically fetch |
+ | | the latest stable release of external dependencies |
+ +-------------+-------------------------------------------------------------+
+ | Mitigations | We explicitly document versions and official sources of |
+ | implemented?| dependencies, but do not yet provide scripts and build |
+ | | options to automatically fetch the latest stable release of |
+ | | external dependencies |
+ +-------------+-------------------------------------------------------------+
+
+ +---------------------------------------------------------------------------+
+ | Threat: TFA-SC-REPO-01 |
+ +=============+=============================================================+
+ | Description | An attacker can upload malicious versions of TF-A by |
+ | | compromising credentials of administrator accounts on |
+ | | tf.org or GitHub. |
+ +-------------+-------------------------------------------------------------+
+ | Impact | HIGH |
+ +-------------+-------------------------------------------------------------+
+ | Likelihood | LOW |
+ +-------------+-------------------------------------------------------------+
+ | Threat and | | This attack is like TFA-SC-SRC-MAIN-01, but the |
+ | impact | likelihood and impact of the two attacks are different. |
+ | | |
+ | | | The likelihood of compromising administrator credentials |
+ | | is lower than that of a maintainer’s (assuming both use |
+ | | authentication methods of similar strength) as there are |
+ | | smaller number of administrators than maintainers. On the |
+ | | other hand, the impact is higher since an administrator |
+ | | has more privileges than a maintainer: |
+ | | |
+ | | | - An administrator can upload a malicious TF-A |
+ | | contribution unnoticed by other reviewers |
+ | | - An administrator can potentially rewrite the history of |
+ | | the repository to evade detection |
+ +-------------+-------------------------------------------------------------+
+ | Proposed | Strong authentication (Follow best practices recommended by |
+ | Mitigations | GitHub [9]_) |
+ +-------------+-------------------------------------------------------------+
+ | Mitigations | Yes, strong authentication is implemented through |
+ | implemented?| recommended best practices |
+ +-------------+-------------------------------------------------------------+
+
+ +---------------------------------------------------------------------------+
+ | Threat: TFA-SC-REPO-02 |
+ +=============+=============================================================+
+ | Description | An attacker can upload malicious versions of TF-A after |
+ | | getting write access to the repository by exploiting a |
+ | | vulnerability on tf.org or GitHub. |
+ +-------------+-------------------------------------------------------------+
+ | Impact | HIGH |
+ +-------------+-------------------------------------------------------------+
+ | Likelihood | LOW |
+ +-------------+-------------------------------------------------------------+
+ | Threat and | | There are no reports of someone exploiting a |
+ | impact | vulnerability on GitHub or tf.org to upload malicious |
+ | | contributions. However, there are examples of |
+ | | vulnerabilities that allowed arbitrary code execution on |
+ | | popular hosting services [12]_. Such vulnerabilities can |
+ | | potentially be used to upload malicious packages. In |
+ | | addition to being hard to exploit, vulnerabilities on |
+ | | popular hosting sites such as GitHub are typically |
+ | | detected quickly, making the window of opportunity for |
+ | | such attack small. |
+ +-------------+-------------------------------------------------------------+
+ | Proposed | - Monitor alerts of any vulnerabilities that might affect |
+ | Mitigations | TF-A repository |
+ | | - Ensure tf.org is up to date with latest security patches |
+ +-------------+-------------------------------------------------------------+
+ | Mitigations | Yes, alerts of vulnerabilities are monitored and tf.org is |
+ | implemented?| ensured to be up to date with the latest security patches |
+ +-------------+-------------------------------------------------------------+
+
+ +---------------------------------------------------------------------------+
+ | Threat: TFA-SC-REPO-03 |
+ +=============+=============================================================+
+ | Description | An attacker can host a malicious version of TF-A on an |
+ | | attacker-controlled repository, and trick end-users into |
+ | | downloading from that repository. |
+ +-------------+-------------------------------------------------------------+
+ | Impact | HIGH |
+ +-------------+-------------------------------------------------------------+
+ | Likelihood | MEDIUM |
+ +-------------+-------------------------------------------------------------+
+ | Threat and | | It is not difficult for an attacker to create a website |
+ | impact | with a similar domain name and look as tf.org (website |
+ | | spoofing) and host a malicious TF-A source repository. |
+ | | Similarly, an attacker can create a mirror of the TF-A |
+ | | repository on GitHub with malicious code in it. However, |
+ | | for this attack to succeed the attacker needs to trick |
+ | | the end-user into using the attacker-controlled |
+ | | repositories. |
+ +-------------+-------------------------------------------------------------+
+ | Proposed | - Users should carefully check the URL of the website |
+ | Mitigations | before visiting it and the URL of the repository before |
+ | | checking it out |
+ | | - Accept reports of spoofing attacks on tf.org and |
+ | | broadcast a warning to partners |
+ +-------------+-------------------------------------------------------------+
+ | Mitigations | We accept reports of spoofing attacks on tf.org and will |
+ | implemented?| broadcast a warning to partners |
+ +-------------+-------------------------------------------------------------+
+
+ +---------------------------------------------------------------------------+
+ | Threat: TFA-SC-TOOL-01 |
+ +=============+=============================================================+
+ | Description | Malicious code can be injected at build time through |
+ | | malicious tools. |
+ +-------------+-------------------------------------------------------------+
+ | Impact | HIGH |
+ +-------------+-------------------------------------------------------------+
+ | Likelihood | LOW |
+ +-------------+-------------------------------------------------------------+
+ | Threat and | | End-users of TF-A use make (or cmake), compilers and |
+ | impact | linkers (armgcc, armclang or LLVM) to build TF-A |
+ | | binaries. Although TF-A documentation specifies versions |
+ | | and official sources of tools used to build TF-A, users |
+ | | can potentially be tricked into using unofficial, |
+ | | malicious toolchains. Similar attacks have been used in |
+ | | the past to inject malicious code into final products |
+ | | [13]_. |
+ +-------------+-------------------------------------------------------------+
+ | Proposed | - Explicitly document versions and official sources of |
+ | Mitigations | toolchains |
+ | | - Provide scripts to automatically fetch the latest stable |
+ | | release of toolchains |
+ +-------------+-------------------------------------------------------------+
+ | Mitigations | We explicitly document versions and official sources of |
+ | implemented?| toolchains, but have not yet provided scripts to |
+ | | automatically fetch the latest stable release of toolchains |
+ +-------------+-------------------------------------------------------------+
+
+ +---------------------------------------------------------------------------+
+ | Threat: TFA-SC-TOOL-02 |
+ +=============+=============================================================+
+ | Description | Malicious code can be executed by developer’s tools at |
+ | | installation time through malicious Node.js dependencies. |
+ +-------------+-------------------------------------------------------------+
+ | Impact | HIGH |
+ +-------------+-------------------------------------------------------------+
+ | Likelihood | LOW |
+ +-------------+-------------------------------------------------------------+
+ | Threat and | | Users of the Node.js tools, including the CI, may be |
+ | impact | exposed to malicious dependencies that have been missed |
+ | | by the Node.js dependency auditor. Users of these tools |
+ | | could potentially be executing malicious code when using |
+ | | these tools, which could potentially allow a malicious |
+ | | actor to make silent modifications to the repository or |
+ | | enable retrieval of user credentials. |
+ | | |
+ | | | If successful, the impact can range from low to high |
+ | | depending on the user's credentials. If the user is an |
+ | | administrator, this could imply TFA-SC-REPO-01. |
+ +-------------+-------------------------------------------------------------+
+ | Proposed | - Limit Node.js tools to a minimal set of trusted packages |
+ | Mitigations | - Pin Node.js packages to known versions |
+ | | - Update dependencies for which Node.js’s auditor reports |
+ | | known CVEs |
+ | | - Execute Node.js tools in the CI only from within a |
+ | | trusted container |
+ +-------------+-------------------------------------------------------------+
+ | Mitigations | Yes, Node.js tools are limited to a minimal set of trusted |
+ | implemented?| packages, packages are pinned to known versions, |
+ | | dependencies are updated when there are known CVEs |
+ | | reported, and Node.js tools are only executed within a |
+ | | trusted container in CI |
+ +-------------+-------------------------------------------------------------+
+
+Appendix A
+**********
+
+Summary of trustedfirmware.org security:
+
+.. table:: Table 2: Security information of trustedfirmware.org
+
+ +------------+--------------------+--------------------+--------------------+
+ | Software/ | Source and | Credential and | Security incident |
+ | System | integrity | permission | response plan |
+ | | | management | |
+ +============+====================+====================+====================+
+ | Jenkins | - Jenkins is built | - Use oauth from | - Monitor CVE’s |
+ | (including | using Dockerfile | Github only | and update |
+ | plugins) | which is based | - The password | Jenkins LTS on a |
+ | | on the official | strength follows | monthly cycle |
+ | | Jenkins docker | Github policy | - Keep plugins up- |
+ | | image | - Do not enforce | to-date. But it |
+ | | - Jenkins plugins | using two-factor | is up to the |
+ | | are built using | authentication | plugin owner to |
+ | | the official | - Jenkins uses | maintain said |
+ | | install- | matrix auth | plugin |
+ | | plugins.sh | which allows | |
+ | | | users to manage | |
+ | | | "job" level ACL | |
+ | | | using Jenkins | |
+ | | | Job Builder | |
+ | | | - No API token | |
+ | | | enabled | |
+ | | | - Jenkins uses the | |
+ | | | inbuilt | |
+ | | | credential store | |
+ | | | where we store | |
+ | | | credentials for | |
+ | | | LAVA, Jenkins | |
+ | | | Job Builder, | |
+ | | | DockerHub, AWS | |
+ | | | and Gerrit | |
+ | | | tokens. The | |
+ | | | credentials are | |
+ | | | stored as a | |
+ | | | secret in | |
+ | | | Jenkins | |
+ | | | credential | |
+ | | | store. These | |
+ | | | credentials | |
+ | | | can be accessed | |
+ | | | via a Jenkins | |
+ | | | job, but someone | |
+ | | | would have to | |
+ | | | push a Jenkins | |
+ | | | Job through a | |
+ | | | Gerrit review to | |
+ | | | do this. Gerrit | |
+ | | | maintains the | |
+ | | | ACL for this and | |
+ | | | only admins and | |
+ | | | project approver | |
+ | | | can +2 a review. | |
+ +------------+--------------------+--------------------+--------------------+
+ | Gerrit | - Gerrit package | - Use oauth from | - Keep plugins up- |
+ | (including | is installed | Github only | to-date. But it |
+ | plugins) | from Linaro top | - The password | is up to the |
+ | | level role, | strength follows | plugin owner to |
+ | | which has a | Github policy | maintain said |
+ | | md5sum check | - Do not enforce | plugin |
+ | | - Gerrit Plugins | using two-factor | |
+ | | are installed | authentication | |
+ | | from Ansible | - Gerrit has ACL | |
+ | | playbook, from | setup within the | |
+ | | the official | UI per-project | |
+ | | Gerrit CI. The | level | |
+ | | plugins are | - No API token | |
+ | | downloaded from | enabled | |
+ | | https://gerrit- | - A ci-bot-user | |
+ | | ci.gerritforge. | created for | |
+ | | com/ | getting comments | |
+ | | - Do not check | from Jenkins | |
+ | | md5sum for every | | |
+ | | plugin | | |
+ +------------+--------------------+--------------------+--------------------+
+ | Git | - Package is from | - All credentials | - Monitor all |
+ | | Linaro OBS (Open | use GitHub. So | CVE's and apply |
+ | | Build Service) | password | them immediately |
+ | | with a couple of | strength etc are | and keep servers |
+ | | “Linaro | based on GitHub | up-to-date |
+ | | modifications”. | policy | monthly |
+ | | (reference: | | - The security |
+ | | Ansible playbook | | incident |
+ | | and cgit repo) | | response plan is |
+ | | - No special | | working in |
+ | | integrity check | | progress |
+ +------------+--------------------+--------------------+--------------------+
+ | Mailman | - Installed from | - It has | - Plan to monitor |
+ | | Ubuntu- | administrator | the CVE’s but no |
+ | | distributed | passwords for | timetable at the |
+ | | package | the various | moment |
+ | | - No special | mailing lists | |
+ | | integrity check | - The password | |
+ | | (reply on APT | strength is not | |
+ | | security) | specified | |
+ +------------+--------------------+--------------------+--------------------+
+ | Website | The website is | There are no | - The websites |
+ | | built on the IT | credentials | themselves are |
+ | | Services' CI/CD | associated with | static files |
+ | | server, | the website | hosted on AWS S3 |
+ | | bamboo.linaro.org, | itself. Any | and cached by |
+ | | from a Jekyll git | permissions | AWS CloudFront |
+ | | repository stored | required by bamboo | - The software |
+ | | on GitHub | to carry out its | used to build |
+ | | | tasks are provided | the website is |
+ | | | through AWS | all open source |
+ | | | instance role | and Linaro |
+ | | | permissions | occasionally |
+ | | | | gets reports |
+ | | | | from GitHub when |
+ | | | | an issue is |
+ | | | | detected. Apply |
+ | | | | a fix if it is |
+ | | | | available. This |
+ | | | | includes any |
+ | | | | Javascript |
+ | | | | frameworks that |
+ | | | | might be used |
+ | | | | within the web |
+ | | | | pages |
+ +------------+--------------------+--------------------+--------------------+
+ | ReadTheDocs| - One webhook ID | - One TF-A account | - Keep database |
+ | | per project is | with password | access list up |
+ | | used by TF CI | stored in | to date |
+ | | for building | engineering | - Monitor security |
+ | | documentation | password | advisories |
+ | | hosted by | database is used | |
+ | | ReadTheDocs | to manage | |
+ | | - Secret token | documentation | |
+ | | supplied as part | - Access request | |
+ | | of the webhook | is required | |
+ | | post build | for database | |
+ | | - Updated content | access | |
+ | | goes live | - Token for | |
+ | | automatically | Jenkins webhook | |
+ | | | for CI uses | |
+ | | | secret | |
+ | | | credential | |
+ | | | storage in | |
+ | | | internal Jenkins | |
+ | | | and viewable | |
+ | | | only through | |
+ | | | ReadTheDocs | |
+ | | | admin page | |
+ +------------+--------------------+--------------------+--------------------+
+
+References
+**********
+
+.. [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git
+.. [2] http://zlib.net/
+.. [3] https://compiler-rt.llvm.org/
+.. [4] https://tls.mbed.org/
+.. [5] https://www.openssl.org/
+.. [6] https://github.com/ARM-software/SCP-firmware
+.. [7] https://github.com/tianocore/edk2
+.. [8] https://downloads.trustedfirmware.org/tf-a/
+.. [9] https://docs.github.com/en/github/authenticating-to-github/creating-a-strong-password
+.. [10] https://trustedfirmware-a.readthedocs.io/en/latest/process/maintenance.html#how-to-become-a-maintainer
+.. [11] https://docs.github.com/en/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies
+.. [12] "Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks"
+.. [13] https://www.wired.com/story/supply-chain-hackers-videogames-asus-ccleaner/
+
+*Copyright (c) 2024, Arm Limited. All rights reserved.*
+
+.. |TF-A System Diagram| image:: ../resources/diagrams/tf-a_system_diagram.png
+.. |TF-A Data Flow Diagram| image:: ../resources/diagrams/tf-a_data_flow_diagram.png
+.. |TF-A Attack Tree| image:: ../resources/diagrams/tf-a_attack_tree.png