An increasing number of developers across the globe use GitHub to host their projects, and many of them use GitHub public repositories for their open source work. While this is a great way to contribute and leverage the power of the community, it does come with a unique set of responsibilities. Particularly around managing credentials and other secrets.
Examples of Azure secrets are authentication credentials that should not be made public. These include things such as passwords, private keys, database connection strings, and storage account keys that are managed by Azure tenants.
In Azure, we take security very seriously. Azure secrets are considered sensitive and should not be made publicly available. An exposed secret could lead to the compromise of your Azure subscription, your cloud assets, as well as on-premises assets and data; putting your applications or services at significant risk.
Microsoft Credential Scanner preview
To help protect our customers, Azure runs Credential Scanner aka CredScan. CredScan monitors all incoming commits on GitHub and checks for specific Azure tenant secrets such as Azure subscription management certificates and Azure SQL connection strings.
Internally at Microsoft we’ve been developing and leveraging CredScan to protect Azure and our 1st party services and applications. In the future we plan to add and release support for more types of secrets to our GitHub scanning. The GitHub scanning and identification of exposed secrets is done automatically by Microsoft. While developers do not have to do anything to opt in to Microsoft scanning of GitHub for exposed Azure secrets, you should always be vigilant and avoid exposing secrets.
Below is a high-level diagram of our automated GitHub scanning process using CredScan:
Upon detection of an exposed secret, the Azure subscription owner gets notified via email from Microsoft’s Cyber Defense Operation Center (CDOC). The email notifies users on which commits have an issue, along with their affected subscriptions, assets, secret type and guidance on how to fix the exposure.
The scanner focuses on incoming commits. As a rule of thumb, if you receive a notification, there may be more credentials in your source code, so make sure to take a close look, and include a review of past commits and commit history. Rotate and remove all such secrets from your code, storing them in a safe location such as Azure Key Vault.
Thousands of customers have been notified since the detection was put in place resulting in further securing customer applications and Azure assets. We sincerely appreciate customer efforts in working with us and making Azure safer.
Remediation
Keep in mind that removing a published secret does not address the risk of exposure. The secret may have been compromised, with or without your knowledge and is still exposed in Git History. For these reasons, the secret must be rotated and/or revoked immediately to avoid security risks.
Some recommended steps to help mitigate this risk:
- Rotate the published credential immediately (e.g. If it detects a leaked certificate then the 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.
Additional information
While detecting hard coded secrets in a timely manner and mitigating the risks is helpful, it is even better if one could prevent secrets from getting checked in altogether. In this regard, Microsoft has released CredScan Code Analyzer as part of Microsoft DevLabs extension for Visual Studio. While in early preview, it provides developers an inline experience for detecting potential secrets in their code, giving them the opportunity to fix those issues in real-time.
For more information, please see the announced availability early preview of the Credential Scanner Code Analyzer.
Below are few additional resources to help you manage secrets and access sensitive information from within your applications in a secure manner: