Developers worldwide host their projects on GitHub with the majority using GitHub public repositories for their open source work. While being a great way to contribute to the community, it does come with things to keep in mind. Particularly around managing credentials and other things.
Azure secrets include authentication credentials that should not be made publicly available i.e. passwords, database connection strings, private keys, and storage account keys which the Azure tenants manage.
In Azure, security is something that is taken very seriously. Considering the fact that Azure secrets are sensitive, they should never be made available to the public. A secret when exposed has the capacity to lead to the compromise of the whole Azure subscription, the cloud and on-premises assets and data consequently having all applications and services put at a major risk.
CredScan – the GitHub commits monitor
Azure now runs Credential Scanner aka CredScan in order to provide protection to their customers. CredScan allows monitoring of all incoming commits on GitHub and checks for any Azure tenant secrets such as Azure subscription management certificates and Azure SQL connection strings.
Azure is planning to release support for more types of secrets to GitHub scanning. The GitHub scanning and identification of exposed secrets is an automatic process conducted by Microsoft. While developers have nothing to do to opt in to Microsoft scanning of GitHub for exposed Azure secrets, one must always be careful and avoid exposing secrets.
Here is an automated GitHub scanning process with CredScan:
After an exposed secret is detected, a notification from Microsoft’s Cyber Defense Operation Center (CDOC) is sent to the Azure subscription owner via email. The email notifies users which commits are facing an issue, along with subscriptions which have been affected, assets, secret type and a detailed guide on how to get the exposure fixed.
The scanner focuses primarily on the incoming commits. If you receive a notification, there is a chance of the presence of more credentials in your source code, so make sure to take a close look, and have past commits and commit history reviewed. Remove all such secrets from your code and have them stored in a safe place such as Azure Key Vault.
[su_note note_color=”#eeeeee” text_color=”#151212″]Suggested Reading: 5 Azure performance metrics every administrator should keep in mind[/su_note]
An important thing to keep in mind is that having a published secret removed in no way addresses the risk of exposure. The secret may have been exposed in git history or compromised in some other way. This is why the secret must be rotated and/or removed as soon as possible to avoid all sorts of security risks.
Following are some of the recommended steps to mitigate the possible risk:
- Rotate the published credential as soon as possible. (e.g. if a leaked certificate is detected such certificate must be reissued, and the leaked certificate removed and/or revoked).
- Update configs/apps to use the new secret as necessary.
- Store the new secret in Azure Key Vault and out of GitHub.
- Do not publicly share or expose the new secret.
- Remove the published secret.
Timely detection of hard-coded secrets and the mitigation of risks is helpful but an even better option is to keep secrets from getting checked in altogether. To make this possible, Microsoft has released CredScan Code Analyzer as part of Microsoft DevLabs extension for Visual Studio. It provides developers with an inline experience for detecting potential secrets in their code and also gives them an opportunity to have issues fixed in a very short period of time.