rewording regarding secrets

Signed-off-by: Thomas Sjögren <konstruktoid@users.noreply.github.com>

Author: konstruktoid

content/library/application-security/recommendations/actions-security/index.md

@@ -90,7 +90,7 @@ To secure GitHub Actions workflows, consider the following strategies:
 10. **Use `head.sha` instead of `head.ref`**: Where possible, reference by commit SHA instead of a user-provided branch name or tag (ref), especially in sensitive contexts (such as `run` steps). If required, use environment variable to store `head.ref` and reference it to prevent injection attack.
 11. **Use caution with public repositories**: Anyone can suggest changes to public repositories. Review workflow triggers, and never use self-hosted runners with public repositories.
 12. **Restrict allowed actions**: Use the [*Allow enterprise, and select non-enterprise, actions and reusable workflows*](https://docs.github.com/en/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#controlling-access-to-public-actions-and-reusable-workflows) setting  to control which actions can run.
-13. **Segregate runners**: Use runner groups and labels to separate high-privilege runners (with access to secrets, sensitive resources or host access) from low-privilege runners.
+13. **Segregate runners**: Use runner groups and labels to separate high-privilege runners from low-privilege runners, and restrict high-privilege runner groups to selected repositories or workflows to reduce exposure to secrets and sensitive resources.
 
 ## Assumptions and preconditions