Update securely-signing-software.md

Adding SSH Key information as requested in ticket TBT-29 on Assembla.

Author: nrios14

user/securely-signing-software.md

@@ -20,7 +20,7 @@ Before getting started, make sure you have:
 
 A passwordless private PEM key can be generated by the account holder or organization admin and uploaded to Travis CI.
 Upload the Key to a [personal account](https://app.travis-ci.com/account/preferences )
-or an Organizational account(e.g.: https://app.travis-ci.com/organizations/[org_name]/preferences). The key name can contain only alphanumeric characters and the underscore character (_). Make sure to note down the name of the key. The key name must be unique within the scope of personal account or organization.
+or an Organizational account(e.g.: https://app.travis-ci.com/organizations/[org_name]/preferences). The key name can contain only alphanumeric characters and the underscore character (_). Make sure to note down the name of the key. The key name must be unique within the scope of a personal account or organization.
 
 The key provided will be available for all builds run under this account (either personal or organizational). Please pay attention to individual Repository Settings, particularly the [Security Settings -> Share SSH key with forks](user/web-ui#share-ssh-keys-with-forks) setting. If enabled, the signing key may be also made available when a forked repository files a Pull Request against the original (base repository). 
 
@@ -81,21 +81,30 @@ script:
 
 Whenever in doubt, please consult the [Cosign KMS Support documentation page](https://docs.sigstore.dev/cosign/kms_support)
 
+### Add SSH Key
+
+Add a new SSH key, a private key in PEM format only.
+
+Complete the following fields to add a new SSH key:
+- **Identifier**: field to add an identifier name.
+- **Description**: field to add a short description.
+- **SSH Key**: field to add your SSH key code. 
+
 ## Security considerations
 
 As much as the feature is meant to help you prove the source of the file or image via signature, please at all times consider following aspects of ensuring security of the key used for signing the files or images during the CI/CD process.
 
 The key used for signing uploaded to Travis CI under a personal account or organization account can be used under every repository owned by this entity (assuming proper tag and key identifier are present in the respective repository `.travis.yml`). The key downloaded from Hashicorp Vault to a specific build job or build can be used, respectively, within a specific build job or every build job of a build.
 
-Therefore please carefully review repository settings in Travis CI for repositories belonging to the account and assess the risk of the key used for signing being exposed, e.g. via malicious pull request from a fork or accidental debug message. We’d recommend paying attention whether the repository is public (which makes the job logs public by default), if the pull requests from forks are allowed, are the repository SSH keys shared and who may access the job logs. Please mind that job logs, especially public, can be used to expose the secret via a malicious or accidental debug message in the pull request or commit that triggers a build in Travis CI. 
+Therefore, please carefully review repository settings in Travis CI for repositories belonging to the account and assess the risk of the key used for signing being exposed, e.g., via malicious pull request from a fork or accidental debug message. We’d recommend paying attention whether the repository is public (which makes the job logs public by default), if the pull requests from forks are allowed, are the repository SSH keys shared and who may access the job logs. Please mind that job logs, especially public, can be used to expose the secret via a malicious or accidental debug message in the pull request or commit that triggers a build in Travis CI. 
 
-We recommend considering following security measures:
- * using separate key just for purpose of file/image signing
- * using private repository to trigger builds, during which the files are signed, if possible
- * reviewing who has push/write access to such repository
- * reviewing Repository Settings, particularly the [Security Settings -> Share SSH key with forks](user/web-ui#share-ssh-keys-with-forks) setting
- * excluding a build, which signs the release to a separate account/organization (if possible and viable) with limited list of collaborators
- * [limiting access to repository job logs](/user/disable-job-logs/) in individual repository settings
- * if using Hashicorp Vault KMS as a source of the key used for signing: always encrypt secrets needed to connect to Vault in the respective Repository Settings or the .travis.yml file
+We recommend considering the following security measures:
+ * using separate key just for the purpose of file/image signing.
+ * using a private repository to trigger builds, during which the files are signed, if possible.
+ * reviewing who has push/write access to such repository.
+ * reviewing Repository Settings, particularly the [Security Settings -> Share SSH key with forks](user/web-ui#share-ssh-keys-with-forks) setting.
+ * excluding a build, which signs the release to a separate account/organization (if possible and viable) with a limited list of collaborators.
+ * [limiting access to repository job logs](/user/disable-job-logs/) in individual repository settings.
+ * if using Hashicorp Vault KMS as a source of the key used for signing: always encrypt secrets needed to connect to Vault in the respective Repository Settings or the .travis.yml file.
 
 Travis CI will attempt to obfuscate secrets in the job logs, yet since there are many ways to print them in the output there’s no guarantee all vulnerable data will be spotted and masked. Since Travis is a cloud CI/CD system, please be wary of associated risks and ways to minimize these. Please read also [Best Practices in Securing Your Data](/user/best-practices-security).