From 476e7b1cbc30dd383ef2235c818423c32fefb778 Mon Sep 17 00:00:00 2001 From: Meg Bird Date: Mon, 28 Jun 2021 08:10:51 -0600 Subject: [PATCH] Update content/actions/learn-github-actions/security-hardening-for-github-actions.md --- .../security-hardening-for-github-actions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/actions/learn-github-actions/security-hardening-for-github-actions.md b/content/actions/learn-github-actions/security-hardening-for-github-actions.md index 1d7181ac85..4e1b705df1 100644 --- a/content/actions/learn-github-actions/security-hardening-for-github-actions.md +++ b/content/actions/learn-github-actions/security-hardening-for-github-actions.md @@ -253,7 +253,7 @@ You should also consider the environment of the self-hosted runner machines: - What sensitive information resides on the machine configured as a self-hosted runner? For example, private SSH keys, API access tokens, among others. - Does the machine have network access to sensitive services? For example, Azure or AWS metadata services. The amount of sensitive information in this environment should be kept to a minimum, and you should always be mindful that any user capable of invoking workflows has access to this environment. -Some customers might attempt to partially mitigate these risks by implementing systems that automatically destroy the self-hosted runner after each job execution. However, this approach might not be as effective as intended, as there is no way to guarantee that a self-hosted runner only runs one job. Some jobs will use secrets as command line arguments which can be seen by another job running on the same runner, e.g. by running `ps x -w`. This can leads to secret leakages. +Some customers might attempt to partially mitigate these risks by implementing systems that automatically destroy the self-hosted runner after each job execution. However, this approach might not be as effective as intended, as there is no way to guarantee that a self-hosted runner only runs one job. Some jobs will use secrets as command-line arguments which can be seen by another job running on the same runner, such as `ps x -w`. This can lead to secret leakages. ## Auditing {% data variables.product.prodname_actions %} events