blob: 386a4b00c52ca5c0f0f90f8cfdf779ba0d944fd2 [file] [log] [blame]
laurenw-arm54212082023-12-08 15:00:07 -06001TF-A Supply Chain Threat Model
2~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3
4Introduction
5************
6
7Software supply chain attacks aim to inject malicious code into a software
8product. There are several ways a malicious code can be injected into a
9software product (open-source project). These include:
10
11- Malicious code commits: This attack directly injects code into a project
12 repository. This can happen for example through developer/maintainer
13 credential hijacks, or malicious external contributors.
14
15- Malicious dependencies: In this case malicious code is introduced into a
16 project through other piece of code or packages the project depends on. This
17 can happen through for example typosquatting attack where an attacker creates
18 a malicious package with a very similar name to a popular package and hosts
19 it on popular package repositories.
20
21- Malicious toolchains: This involves malicious code introduced by compromised
22 resources used throughout the development and/or build process such as
23 compilers and IDEs.
24
25This document provides analysis of software supply chain attack threats for the
26TF-A project.
27
28TF-A Overview
29*************
30
31Figure 1 shows the different software components surrounding the TF-A project.
32A brief description of each component is provided below.
33
34TF-A Repository
35===============
36
37The TF-A repository contains generic and platform code contributed by TF-A
38contributors as well as libraries imported from other open-source projects,
39referred to as internal dependencies on Figure 1. These libraries include:
40
41- *libfdt*: libfdt is a utility library for reading and manipulating Device
42 Tree Binary (DTB) files. It is part of the Device Tree Compiler (DTC)
43 toolchain [1]_. DTC is used as part of the build process on the host machine
44 to build DTB files. libfdt is used to parse the DTB files at boot time.
45
46- *zlib*: zlib is a data compression library imported from [2]_.
47
48- *compiler-rt*: This is a collection of runtime libraries from the LLVM
49 compiler infrastructure project [3]_. We import the builtins library which
50 provides low-level, target-specific compiler builtins from compiler-rt.
51
52The TF-A repository also includes source code for host tools that supplement
53the TF-A build process. These tools include:
54
55- *fiptool*: This tool is used to create a Firmware Image Package (FIP) which
56 allows for packing bootloader images into a single archive that can be
57 loaded by TF-A from non-volatile platform storage.
58
59- *cert_create*: This tool is used to generate certificates for binary images.
60
61- *encrypt_fw*: This tool takes the plain firmware image as input and generates
62 the encrypted firmware image which can then be passed as input to the fiptool
63 utility for creating the FIP.
64
65- *sptool*: This tool is used to build the secure partition packages.
66
67|TF-A System Diagram|
68*Figure 1: TF-A System Diagram*
69
70External Dependencies
71=====================
72
73These are software components that are not part of the TF-A repository but are
74required to build TF-A binaries and host tools.
75
76- *Mbed TLS Library*: This is a cryptography library from trustedfirmware.org
77 (tf.org). It is required to build TF-A binaries where cryptography features
78 are needed, such as Trusted Board Boot (TBB).
79
80- *OpenSSL Library*: This is another cryptography library used by TF-A host
81 tools: fiptool, cert_create, and encrypt_fw.
82
83The following table lists TF-A dependencies including the sources of the
84dependencies.
85
86.. table:: Table 1: TF-A Dependencies
87
88 +-------------+------------------------+------------------------------------+
89 | Dependency | Location of Dependency | Original Source |
90 +=============+========================+====================================+
91 | libfdt | Local copy | [1]_ |
92 +-------------+------------------------+------------------------------------+
93 | zlib | Local copy | [2]_ |
94 +-------------+------------------------+------------------------------------+
95 | compiler-rt | Local copy | [3]_ |
96 +-------------+------------------------+------------------------------------+
97 | Mbed TLS | External | [4]_ |
98 +-------------+------------------------+------------------------------------+
99 | OpenSSL | External | [5]_ |
100 +-------------+------------------------+------------------------------------+
101
102Supplementary Binaries
103======================
104
105These are binaries used to test TF-A based systems. Below is a brief
106description of each component and where they are sourced from.
107
108- *SCP-firmware*: For our tests, we use SCP-firmware binaries supplied by the
109 Arm SCP team built from the source from the GitHub repository [6]_.
110
111- *OP-TEE*: Trusted Execution Environment (TEE) from tf.org that runs as
112 Secure EL1. We use OP-TEE built from source or binaries supplied with Arm
113 Reference Platforms depending on the test configuration.
114
115- *EDK2 UEFI*: Normal world bootloader from the EDK2 project [7]_. We use EDK2
116 UEFI binaries hosted on tf.org servers for testing [8]_.
117
118Other software components used to test TF-A include U-Boot, Linux kernel, RSS,
119MCP, and file systems, all sourced from the Arm Reference Platforms teams.
120
121TF-A Toolchain
122==============
123
124The TF-A project uses several tools to build, analyze and test the TF-A source
125code.
126
127Node.js Tools
128-------------
129
130These are optional quality assurance and developer utility tools that are
131installed through the use of the Node.js package manager. They are pinned to
132specific versions described by the package.json file in the root of the TF-A
133repository, and their dependencies are downloaded from the internet at the
134point of installation. These tools may be installed locally on the developer
135machine and are installed within a Docker container in certain CI jobs. At
136present, these are:
137
138- Commitlint
139
140- Commitizen
141
142- Husky
143
144Infrastructure
145==============
146
147TF-A uses trustedfirmware.org (tf.org) and Arm infrastructures to host the
148source code, review code and run tests. Appendix A provides a security analysis
149of tf.org infrastructure.
150
151TF-A Data Flow
152**************
153
154Figure 2 below shows the data flow diagram for TF-A. The broken red lines
155indicate trust boundaries.
156
157|TF-A Data Flow Diagram|
158*Figure 2: TF-A Data Flow Diagram*
159
160Attack Tree
161***********
162
163|TF-A Attack Tree|
164*Figure 3: TF-A Attack Tree*
165
166Threat Assessment and Mitigations
167*********************************
168
169Impact and Likelihood Ratings
170=============================
171
172 +--------+------------------------------+-----------------------------------+
173 | Rating | Impact | Likelihood |
174 +========+==============================+===================================+
175 | HIGH | Major impact to entire | Threat is relatively easy to |
176 | | organization or single line | exploit by an attacker with |
177 | | of business if exploited. | little effort and skill. |
178 +--------+------------------------------+-----------------------------------+
179 | MEDIUM | Noticeable impact to line of | An expert attacker could exploit |
180 | | business if exploited. | the threat without much |
181 | | | difficulty. |
182 +--------+------------------------------+-----------------------------------+
183 | LOW | Minor damage if exploited or | Exploiting the threat would |
184 | | could be used in conjunction | require considerable effort and |
185 | | with other vulnerabilities | resources. |
186 | | to perform a more serious | |
187 | | attack. | |
188 +--------+------------------------------+-----------------------------------+
189
190Threats and Mitigations
191=======================
192
193Threat naming convention key
194
195- SC – Supply Chain
196
197- SRC – Source
198
199- DEP – Dependency
200
201- TOOL – Toolchain
202
203- REPO – Repository
204
205- MAIN – Maintainer
206
207- CONT – Contributor
208
209 +---------------------------------------------------------------------------+
210 | Threat: TFA-SC-SRC-MAIN-01 |
211 +=============+=============================================================+
212 | Description | An attacker can submit and merge malicious code by posing |
213 | | as a maintainer after compromising maintainers’ |
214 | | credentials. |
215 +-------------+-------------------------------------------------------------+
216 | Impact | HIGH |
217 +-------------+-------------------------------------------------------------+
218 | Likelihood | MEDIUM |
219 +-------------+-------------------------------------------------------------+
220 | Threat and | | In the TF-A code review process all submitted changes |
221 | impact | undergo review by a code owner and a maintainer. If the |
222 | | change is accepted, it will be merged (integrated) into  |
223 | | an integration branch by a maintainer. A maintainer has |
224 | | the right to give a code owner review, a maintainer |
225 | | review and merge the submitted change.  |
226 | | |
227 | | | tf.org users (including maintainers) are authenticated |
228 | | through GitHub. The likelihood of a credential compromise |
229 | | depends on multiple factors. The authentication mechanism |
230 | | of GitHub is strong if the recommended best practices are |
231 | | followed [9]_ making credential compromise unlikely. |
232 | | GitHub (therefore tf.org) allows logins with two-factor |
233 | | authentication, requiring both a password and access to |
234 | | the user's authentication code. Depending on the strength |
235 | | of the password and factors such as whether the |
236 | | maintainer reuses passwords across services, the |
237 | | likelihood of a compromise can be higher. |
238 | | |
239 | | | If an attacker manages to compromise a maintainer’s |
240 | | credentials, posing as the maintainer, they can in theory |
241 | | submit a malicious change (as a maintainer or as a |
242 | | contributor), give all the necessary reviews and merge |
243 | | the change. |
244 +-------------+-------------------------------------------------------------+
245 | Mitigations | | - Enforce best practices recommended by GitHub [9]_ |
246 | | |
247 | | | - Not allowing a committer to both self-review and merge |
248 | | patches they have submitted. To achieve the commit the |
249 | | attacker would be required to compromise at least two |
250 | | credentials (reviewers and maintainer). |
251 +-------------+-------------------------------------------------------------+
252 | Mitigations | We have not disallowed self-review/merge of patches |
253 | implemented?| |
254 +-------------+-------------------------------------------------------------+
255
256 +---------------------------------------------------------------------------+
257 | Threat: TFA-SC-SRC-MAIN-02 |
258 +=============+=============================================================+
259 | Description | An attacker can submit and merge malicious code after |
260 | | becoming a maintainer through social engineering |
261 | | techniques. |
262 +-------------+-------------------------------------------------------------+
263 | Impact | HIGH |
264 +-------------+-------------------------------------------------------------+
265 | Likelihood | LOW |
266 +-------------+-------------------------------------------------------------+
267 | Threat and | | According to the TF project maintenance process [10]_, |
268 | impact | maintainers of TF-A are selected by their peers based on |
269 | | merit. Some of the criteria of becoming a maintainer |
270 | | include being an active member of the project for a |
271 | | minimum duration and contributing a substantial number of |
272 | | non-trivial and high-quality patches. However, there are |
273 | | some weaknesses in the process: |
274 | | |
275 | | | - There is no structured mechanism to establish trust |
276 | | with a maintainer other than the recommendations by |
277 | | peers |
278 | | | - There is no continuous monitoring of the status of a |
279 | | maintainer (e.g. maintainer can move from one |
280 | | organization to another) |
281 | | |
282 | | | To perform such an attack, in addition to becoming a |
283 | | maintainer, an attacker also must deal with all |
284 | | restrictions put on maintainers. |
285 +-------------+-------------------------------------------------------------+
286 | Mitigations | | - Structured mechanism to establish trust with |
287 | | maintainers |
288 | | |
289 | | | - Not allowing a committer to both self-review and merge |
290 | | patches they have submitted. To achieve the commit the |
291 | | attacker would be required to compromise at least two |
292 | | credentials (reviewers and maintainer). |
293 +-------------+-------------------------------------------------------------+
294 | Mitigations | There is a structured mechanism to establish trust with |
295 | implemented?| maintainers, but self-review/merge of patches is not |
296 | | disallowed |
297 +-------------+-------------------------------------------------------------+
298
299 +---------------------------------------------------------------------------+
300 | Threat: TFA-SC-SRC-CONT-01 |
301 +=============+=============================================================+
302 | Description | An attacker can submit malicious code patch as a |
303 | | contributor. |
304 +-------------+-------------------------------------------------------------+
305 | Impact | HIGH |
306 +-------------+-------------------------------------------------------------+
307 | Likelihood | LOW |
308 +-------------+-------------------------------------------------------------+
309 | Threat and | | TF-A accepts external contributions to both the generic |
310 | impact | and platform code. Unlike maintainers, contributors do |
311 | | not have maintainer review or merging privileges, |
312 | | therefore the likelihood of injecting malicious code as a |
313 | | contributor is lower. However, even though unlikely, it |
314 | | is still possible for a malicious commit to go unnoticed |
315 | | through the code review and verification processes. |
316 | | |
317 | | | If successful, the impact can range from low to high |
318 | | depending on the injected code. For example, an attacker |
319 | | can potentially deliberately insert a memory corruption |
320 | | vulnerability that is hard to notice on code review and |
321 | | will not be detected by the verification process. This |
322 | | vulnerability by itself may have a low impact but can |
323 | | have a major impact if used in combination with other |
324 | | vulnerabilities. |
325 +-------------+-------------------------------------------------------------+
326 | Proposed | - Code review and verification |
327 | Mitigations | - Static analysis to try to pick up issues that typically |
328 | | end in some form of attack vector |
329 +-------------+-------------------------------------------------------------+
330 | Mitigations | Yes, contributions go through the thorough review, |
331 | implemented?| verification, and static analysis process automated through |
332 | | CI |
333 +-------------+-------------------------------------------------------------+
334
335 +---------------------------------------------------------------------------+
336 | Threat: TFA-SC-DEP-01 |
337 +=============+=============================================================+
338 | Description | An attacker can inject malicious code into TF-A internal |
339 | | dependencies.  |
340 +-------------+-------------------------------------------------------------+
341 | Impact | HIGH |
342 +-------------+-------------------------------------------------------------+
343 | Likelihood | LOW |
344 +-------------+-------------------------------------------------------------+
345 | Threat and | | TF-A has two types of dependencies: those that are copied |
346 | impact | into the TF-A repository and shipped as part of TF-A code |
347 | | (referred to as *internal dependencies* here) and those |
348 | | that are downloaded from external repositories and used |
349 | | when building TF-A (referred to as |
350 | | *external dependencies* here).  |
351 | | |
352 | | | Currently TF-A has three internal dependencies: *libfdt* |
353 | | [1]_, *zlib* [2]_ and *compiler-rt* [3]_ libraries. These |
354 | | libraries are periodically updated by copying them from |
355 | | their source repositories. Although unlikely, it is |
356 | | possible for a contributor to copy the libraries from the |
357 | | wrong (and potentially malicious) repositories. For |
358 | | example, there are already multiple forks of *libfdt* |
359 | | (DTC) on GitHub. In addition to this, the official |
360 | | repositories are not immune to threats described above |
361 | | (TFA-SC-SRC-MAIN-01, TFA-SC-SRC-MAIN-02 and |
362 | | TFA-SC-SRC-CONT-01). |
363 | | |
364 | | | The likelihood of an attack on TF-A through internal |
365 | | dependencies is lower than external dependencies for the |
366 | | following reasons:  |
367 | | |
368 | | | - Internal dependencies go through the normal code review |
369 | | process during upgrade |
370 | | | - Once upgraded internal dependencies stay unchanged |
371 | | until the next upgrade. The upgrade window is typically |
372 | | long (for example *libfdt* has only changed 4 times |
373 | | over the past 4 years). This reduces the window of |
374 | | opportunity for an attacker to inject malicious code |
375 | | into the dependencies |
376 +-------------+-------------------------------------------------------------+
377 | Proposed | - Explicitly document versions and official sources of |
378 | Mitigations | dependencies |
379 | | - Keep a copy of a pinned version of the source code inside |
380 | | the TF-A tree so that the risk of getting malicious code |
381 | | from dependencies only arises when we upgrade them |
382 | | - Monitor alerts for vulnerable dependencies from GitHub |
383 | | [11]_ |
384 +-------------+-------------------------------------------------------------+
385 | Mitigations | Yes, we explicitly document versions and official sources |
386 | implemented?| of dependencies, keep a copy of pinned versions of the |
387 | | source code, and monitor alerts for vulnerable dependencies |
388 | | for Python and Node.js, but we aren't able to do this for C |
389 | | dependencies |
390 +-------------+-------------------------------------------------------------+
391
392 +---------------------------------------------------------------------------+
393 | Threat: TFA-SC-DEP-02 |
394 +=============+=============================================================+
395 | Description | An attacker can inject malicious code into TF-A external |
396 | | dependencies. |
397 +-------------+-------------------------------------------------------------+
398 | Impact | HIGH |
399 +-------------+-------------------------------------------------------------+
400 | Likelihood | MEDIUM |
401 +-------------+-------------------------------------------------------------+
402 | Threat and | | Unlike internal dependencies, external dependencies are |
403 | impact | downloaded from external repositories by end-users. |
404 | | Although the TF-A documentation provides information |
405 | | about the versions of dependencies used for testing and |
406 | | links to repositories, it is up to the end-user to decide |
407 | | where to get the dependencies from. As such, the |
408 | | likelihood of an attack through an external dependency is |
409 | | higher compared to an internal dependency. |
410 | | |
411 | | | The impact of an attack ranges from low to critical |
412 | | depending on which dependency and what part of the |
413 | | dependency is affected. For example, a malicious code |
414 | | that affects the signature verification functions in |
415 | | MbedTLS is considered critical as it can be used to |
416 | | bypass the TBB process of TF-A. |
417 +-------------+-------------------------------------------------------------+
418 | Proposed | - Explicitly document versions and official sources of |
419 | Mitigations | dependencies |
420 | | - Provide scripts and build options to automatically fetch |
421 | | the latest stable release of external dependencies |
422 +-------------+-------------------------------------------------------------+
423 | Mitigations | We explicitly document versions and official sources of |
424 | implemented?| dependencies, but do not yet provide scripts and build |
425 | | options to automatically fetch the latest stable release of |
426 | | external dependencies |
427 +-------------+-------------------------------------------------------------+
428
429 +---------------------------------------------------------------------------+
430 | Threat: TFA-SC-REPO-01 |
431 +=============+=============================================================+
432 | Description | An attacker can upload malicious versions of TF-A by |
433 | | compromising credentials of administrator accounts on |
434 | | tf.org or GitHub. |
435 +-------------+-------------------------------------------------------------+
436 | Impact | HIGH |
437 +-------------+-------------------------------------------------------------+
438 | Likelihood | LOW |
439 +-------------+-------------------------------------------------------------+
440 | Threat and | | This attack is like TFA-SC-SRC-MAIN-01, but the |
441 | impact | likelihood and impact of the two attacks are different. |
442 | | |
443 | | | The likelihood of compromising administrator credentials |
444 | | is lower than that of a maintainer’s (assuming both use |
445 | | authentication methods of similar strength) as there are |
446 | | smaller number of administrators than maintainers. On the |
447 | | other hand, the impact is higher since an administrator |
448 | | has more privileges than a maintainer: |
449 | | |
450 | | | - An administrator can upload a malicious TF-A |
451 | | contribution unnoticed by other reviewers |
452 | | - An administrator can potentially rewrite the history of |
453 | | the repository to evade detection |
454 +-------------+-------------------------------------------------------------+
455 | Proposed | Strong authentication (Follow best practices recommended by |
456 | Mitigations | GitHub [9]_) |
457 +-------------+-------------------------------------------------------------+
458 | Mitigations | Yes, strong authentication is implemented through |
459 | implemented?| recommended best practices |
460 +-------------+-------------------------------------------------------------+
461
462 +---------------------------------------------------------------------------+
463 | Threat: TFA-SC-REPO-02 |
464 +=============+=============================================================+
465 | Description | An attacker can upload malicious versions of TF-A after |
466 | | getting write access to the repository by exploiting a |
467 | | vulnerability on tf.org or GitHub. |
468 +-------------+-------------------------------------------------------------+
469 | Impact | HIGH |
470 +-------------+-------------------------------------------------------------+
471 | Likelihood | LOW |
472 +-------------+-------------------------------------------------------------+
473 | Threat and | | There are no reports of someone exploiting a |
474 | impact | vulnerability on GitHub or tf.org to upload malicious |
475 | | contributions. However, there are examples of |
476 | | vulnerabilities that allowed arbitrary code execution on |
477 | | popular hosting services [12]_. Such vulnerabilities can |
478 | | potentially be used to upload malicious packages. In |
479 | | addition to being hard to exploit, vulnerabilities on |
480 | | popular hosting sites such as GitHub are typically |
481 | | detected quickly, making the window of opportunity for |
482 | | such attack small. |
483 +-------------+-------------------------------------------------------------+
484 | Proposed | - Monitor alerts of any vulnerabilities that might affect |
485 | Mitigations | TF-A repository |
486 | | - Ensure tf.org is up to date with latest security patches |
487 +-------------+-------------------------------------------------------------+
488 | Mitigations | Yes, alerts of vulnerabilities are monitored and tf.org is |
489 | implemented?| ensured to be up to date with the latest security patches |
490 +-------------+-------------------------------------------------------------+
491
492 +---------------------------------------------------------------------------+
493 | Threat: TFA-SC-REPO-03 |
494 +=============+=============================================================+
495 | Description | An attacker can host a malicious version of TF-A on an |
496 | | attacker-controlled repository, and trick end-users into |
497 | | downloading from that repository. |
498 +-------------+-------------------------------------------------------------+
499 | Impact | HIGH |
500 +-------------+-------------------------------------------------------------+
501 | Likelihood | MEDIUM |
502 +-------------+-------------------------------------------------------------+
503 | Threat and | | It is not difficult for an attacker to create a website |
504 | impact | with a similar domain name and look as tf.org (website |
505 | | spoofing) and host a malicious TF-A source repository. |
506 | | Similarly, an attacker can create a mirror of the TF-A |
507 | | repository on GitHub with malicious code in it. However, |
508 | | for this attack to succeed the attacker needs to trick |
509 | | the end-user into using the attacker-controlled |
510 | | repositories. |
511 +-------------+-------------------------------------------------------------+
512 | Proposed | - Users should carefully check the URL of the website |
513 | Mitigations | before visiting it and the URL of the repository before |
514 | | checking it out |
515 | | - Accept reports of spoofing attacks on tf.org and |
516 | | broadcast a warning to partners |
517 +-------------+-------------------------------------------------------------+
518 | Mitigations | We accept reports of spoofing attacks on tf.org and will |
519 | implemented?| broadcast a warning to partners |
520 +-------------+-------------------------------------------------------------+
521
522 +---------------------------------------------------------------------------+
523 | Threat: TFA-SC-TOOL-01 |
524 +=============+=============================================================+
525 | Description | Malicious code can be injected at build time through |
526 | | malicious tools. |
527 +-------------+-------------------------------------------------------------+
528 | Impact | HIGH |
529 +-------------+-------------------------------------------------------------+
530 | Likelihood | LOW |
531 +-------------+-------------------------------------------------------------+
532 | Threat and | | End-users of TF-A use make (or cmake), compilers and |
533 | impact | linkers (armgcc, armclang or LLVM) to build TF-A |
534 | | binaries. Although TF-A documentation specifies versions |
535 | | and official sources of tools used to build TF-A, users |
536 | | can potentially be tricked into using unofficial, |
537 | | malicious toolchains. Similar attacks have been used in |
538 | | the past to inject malicious code into final products |
539 | | [13]_. |
540 +-------------+-------------------------------------------------------------+
541 | Proposed | - Explicitly document versions and official sources of |
542 | Mitigations | toolchains |
543 | | - Provide scripts to automatically fetch the latest stable |
544 | | release of toolchains |
545 +-------------+-------------------------------------------------------------+
546 | Mitigations | We explicitly document versions and official sources of |
547 | implemented?| toolchains, but have not yet provided scripts to |
548 | | automatically fetch the latest stable release of toolchains |
549 +-------------+-------------------------------------------------------------+
550
551 +---------------------------------------------------------------------------+
552 | Threat: TFA-SC-TOOL-02 |
553 +=============+=============================================================+
554 | Description | Malicious code can be executed by developer’s tools at |
555 | | installation time through malicious Node.js dependencies. |
556 +-------------+-------------------------------------------------------------+
557 | Impact | HIGH |
558 +-------------+-------------------------------------------------------------+
559 | Likelihood | LOW |
560 +-------------+-------------------------------------------------------------+
561 | Threat and | | Users of the Node.js tools, including the CI, may be |
562 | impact | exposed to malicious dependencies that have been missed |
563 | | by the Node.js dependency auditor. Users of these tools |
564 | | could potentially be executing malicious code when using |
565 | | these tools, which could potentially allow a malicious |
566 | | actor to make silent modifications to the repository or |
567 | | enable retrieval of user credentials. |
568 | | |
569 | | | If successful, the impact can range from low to high |
570 | | depending on the user's credentials. If the user is an |
571 | | administrator, this could imply TFA-SC-REPO-01. |
572 +-------------+-------------------------------------------------------------+
573 | Proposed | - Limit Node.js tools to a minimal set of trusted packages |
574 | Mitigations | - Pin Node.js packages to known versions |
575 | | - Update dependencies for which Node.js’s auditor reports |
576 | | known CVEs |
577 | | - Execute Node.js tools in the CI only from within a |
578 | | trusted container |
579 +-------------+-------------------------------------------------------------+
580 | Mitigations | Yes, Node.js tools are limited to a minimal set of trusted |
581 | implemented?| packages, packages are pinned to known versions, |
582 | | dependencies are updated when there are known CVEs |
583 | | reported, and Node.js tools are only executed within a |
584 | | trusted container in CI |
585 +-------------+-------------------------------------------------------------+
586
587Appendix A
588**********
589
590Summary of trustedfirmware.org security:
591
592.. table:: Table 2: Security information of trustedfirmware.org
593
594 +------------+--------------------+--------------------+--------------------+
595 | Software/ | Source and | Credential and | Security incident |
596 | System | integrity | permission | response plan |
597 | | | management | |
598 +============+====================+====================+====================+
599 | Jenkins | - Jenkins is built | - Use oauth from | - Monitor CVE’s |
600 | (including | using Dockerfile | Github only | and update |
601 | plugins) | which is based | - The password | Jenkins LTS on a |
602 | | on the official | strength follows | monthly cycle |
603 | | Jenkins docker | Github policy | - Keep plugins up- |
604 | | image | - Do not enforce | to-date. But it |
605 | | - Jenkins plugins | using two-factor | is up to the |
606 | | are built using | authentication | plugin owner to |
607 | | the official | - Jenkins uses | maintain said |
608 | | install- | matrix auth | plugin |
609 | | plugins.sh | which allows | |
610 | | | users to manage | |
611 | | | "job" level ACL | |
612 | | | using Jenkins | |
613 | | | Job Builder | |
614 | | | - No API token | |
615 | | | enabled | |
616 | | | - Jenkins uses the | |
617 | | | inbuilt | |
618 | | | credential store | |
619 | | | where we store | |
620 | | | credentials for | |
621 | | | LAVA, Jenkins | |
622 | | | Job Builder, | |
623 | | | DockerHub, AWS | |
624 | | | and Gerrit | |
625 | | | tokens. The | |
626 | | | credentials are | |
627 | | | stored as a | |
628 | | | secret in | |
629 | | | Jenkins | |
630 | | | credential | |
631 | | | store. These | |
632 | | | credentials | |
633 | | | can be accessed | |
634 | | | via a Jenkins | |
635 | | | job, but someone | |
636 | | | would have to | |
637 | | | push a Jenkins | |
638 | | | Job through a | |
639 | | | Gerrit review to | |
640 | | | do this. Gerrit | |
641 | | | maintains the | |
642 | | | ACL for this and | |
643 | | | only admins and | |
644 | | | project approver | |
645 | | | can +2 a review. | |
646 +------------+--------------------+--------------------+--------------------+
647 | Gerrit | - Gerrit package | - Use oauth from | - Keep plugins up- |
648 | (including | is installed | Github only | to-date. But it |
649 | plugins) | from Linaro top | - The password | is up to the |
650 | | level role, | strength follows | plugin owner to |
651 | | which has a | Github policy | maintain said |
652 | | md5sum check | - Do not enforce | plugin |
653 | | - Gerrit Plugins | using two-factor | |
654 | | are installed | authentication | |
655 | | from Ansible | - Gerrit has ACL | |
656 | | playbook, from | setup within the | |
657 | | the official | UI per-project | |
658 | | Gerrit CI. The | level | |
659 | | plugins are | - No API token | |
660 | | downloaded from | enabled | |
661 | | https://gerrit- | - A ci-bot-user | |
662 | | ci.gerritforge. | created for | |
663 | | com/ | getting comments | |
664 | | - Do not check | from Jenkins | |
665 | | md5sum for every | | |
666 | | plugin | | |
667 +------------+--------------------+--------------------+--------------------+
668 | Git | - Package is from | - All credentials | - Monitor all |
669 | | Linaro OBS (Open | use GitHub. So | CVE's and apply |
670 | | Build Service) | password | them immediately |
671 | | with a couple of | strength etc are | and keep servers |
672 | | “Linaro | based on GitHub | up-to-date |
673 | | modifications”. | policy | monthly |
674 | | (reference: | | - The security |
675 | | Ansible playbook | | incident |
676 | | and cgit repo) | | response plan is |
677 | | - No special | | working in |
678 | | integrity check | | progress |
679 +------------+--------------------+--------------------+--------------------+
680 | Mailman | - Installed from | - It has | - Plan to monitor |
681 | | Ubuntu- | administrator | the CVE’s but no |
682 | | distributed | passwords for | timetable at the |
683 | | package | the various | moment |
684 | | - No special | mailing lists | |
685 | | integrity check | - The password | |
686 | | (reply on APT | strength is not | |
687 | | security) | specified | |
688 +------------+--------------------+--------------------+--------------------+
689 | Website | The website is | There are no | - The websites |
690 | | built on the IT | credentials | themselves are |
691 | | Services' CI/CD | associated with | static files |
692 | | server, | the website | hosted on AWS S3 |
693 | | bamboo.linaro.org, | itself. Any | and cached by |
694 | | from a Jekyll git | permissions | AWS CloudFront |
695 | | repository stored | required by bamboo | - The software |
696 | | on GitHub | to carry out its | used to build |
697 | | | tasks are provided | the website is |
698 | | | through AWS | all open source |
699 | | | instance role | and Linaro |
700 | | | permissions | occasionally |
701 | | | | gets reports |
702 | | | | from GitHub when |
703 | | | | an issue is |
704 | | | | detected. Apply |
705 | | | | a fix if it is |
706 | | | | available. This |
707 | | | | includes any |
708 | | | | Javascript |
709 | | | | frameworks that |
710 | | | | might be used |
711 | | | | within the web |
712 | | | | pages |
713 +------------+--------------------+--------------------+--------------------+
714 | ReadTheDocs| - One webhook ID | - One TF-A account | - Keep database |
715 | | per project is | with password | access list up |
716 | | used by TF CI | stored in | to date |
717 | | for building | engineering | - Monitor security |
718 | | documentation | password | advisories |
719 | | hosted by | database is used | |
720 | | ReadTheDocs | to manage | |
721 | | - Secret token | documentation | |
722 | | supplied as part | - Access request | |
723 | | of the webhook | is required | |
724 | | post build | for database | |
725 | | - Updated content | access | |
726 | | goes live | - Token for | |
727 | | automatically | Jenkins webhook | |
728 | | | for CI uses | |
729 | | | secret | |
730 | | | credential | |
731 | | | storage in | |
732 | | | internal Jenkins | |
733 | | | and viewable | |
734 | | | only through | |
735 | | | ReadTheDocs | |
736 | | | admin page | |
737 +------------+--------------------+--------------------+--------------------+
738
739References
740**********
741
742.. [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git
743.. [2] http://zlib.net/
744.. [3] https://compiler-rt.llvm.org/
745.. [4] https://tls.mbed.org/
746.. [5] https://www.openssl.org/
747.. [6] https://github.com/ARM-software/SCP-firmware
748.. [7] https://github.com/tianocore/edk2
749.. [8] https://downloads.trustedfirmware.org/tf-a/
750.. [9] https://docs.github.com/en/github/authenticating-to-github/creating-a-strong-password
751.. [10] https://trustedfirmware-a.readthedocs.io/en/latest/process/maintenance.html#how-to-become-a-maintainer
752.. [11] https://docs.github.com/en/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies
753.. [12] "Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks"
754.. [13] https://www.wired.com/story/supply-chain-hackers-videogames-asus-ccleaner/
755
756*Copyright (c) 2024, Arm Limited. All rights reserved.*
757
758.. |TF-A System Diagram| image:: ../resources/diagrams/tf-a_system_diagram.png
759.. |TF-A Data Flow Diagram| image:: ../resources/diagrams/tf-a_data_flow_diagram.png
760.. |TF-A Attack Tree| image:: ../resources/diagrams/tf-a_attack_tree.png