Framework/Configurations/SVT/ADO/ADO.VariableGroup.json
|
{
"FeatureName": "VariableGroup", "Reference": "aka.ms/azsktcp/VariableGroup", "IsMaintenanceMode": false, "Controls": [ { "ControlID": "ADO_VariableGroup_AuthZ_Dont_Grant_All_Pipelines_Access_On_VG_With_Secrets", "Description": "Do not make variable groups with secret variables accessible to all (YAML) pipelines.", "Id": "VariableGroup120", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckPipelineAccess", "Rationale": "If a variable group containing secrets is marked as accessible to all YAML pipelines then an attacker can extract or compromise the assets involving the secret variables by creating a new pipeline. Note that this does not prevent classic pipelines from accessing the variable group as it depends on the permissions granted to pipeline user.", "Recommendation": "1.Navigate to the variable group --> 2. Click on 'Pipeline permissions' --> 3. Click on 'Restrict permission' --> 4. Add the YAML pipeline which needs permission on the variable group. For classic pipeline review user permissions carefully.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ", "MSW", "AutomatedFix" ], "Enabled": true }, { "ControlID": "ADO_VariableGroup_AuthZ_Disable_Inherited_Permissions", "Description": "Do not allow inherited permissions on variable groups.", "Id": "VariableGroup130", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckInheritedPermissions", "Rationale": "Disabling inherited permissions lets you finely control access to various operations at the variable group level for different stakeholders. This ensures that you follow the principle of least privilege and provide access only to the persons that require it.", "Recommendation": "To disable inheritance follow the steps given here: 1.Navigate to the variable group. 2. Select Security. 3. Turn off Inheritance. As best practice, all teams/groups must be granted minimum required permissions on variable group.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ" ], "Enabled": true }, { "ControlID": "ADO_VariableGroup_DP_No_PlainText_Secrets_In_Variables", "Description": "Secrets and keys must not be stored as plain text in variable group variables.", "Id": "VariableGroup140", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckCredInVarGrp", "Rationale": "Keeping secrets such as connection strings, passwords, keys, etc. in plain text can expose the credentials to a wider audience and can lead to credential theft. Marking them as secret protects them from unitended disclosure and/or misuse.", "Recommendation": "1. Navigate to the variable group --> 2. Go to variables --> 3. Lock the variables which contain secret using 'Change variable type to secret' option denoted by lock symbol against each variable.", "Tags": [ "SDL", "TCP", "Automated", "DP", "AutomatedFix" ], "Enabled": true }, { "ControlID": "ADO_VariableGroup_DP_Store_Secrets_In_KeyVault", "Description": "Consider using a linked Azure key vault for secret variables of the variable group.", "Id": "VariableGroup150", "ControlSeverity": "Low", "Automated": "No", "MethodName": "", "Rationale": "Storing secrets in a custom variable group is less secure than storing them in Azure key vault and selectively mapping it to the variable group as Key Vault offers an extra layer of security (identity & management, network access and monitoring).", "Recommendation": "Refer: https://docs.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=azure-devops&tabs=yaml#link-secrets-from-an-azure-key-vault", "Tags": [ "SDL", "TCP", "Manual", "DP" ], "Enabled": true }, { "ControlID": "ADO_VariableGroup_AuthZ_Restrict_Broader_Group_Access", "Description": "Broader groups (contributors, project valid users, etc.) should not have excessive permissions on variable group.", "Id": "VariableGroup160", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckBroaderGroupAccess", "Rationale": "If the broader groups (e.g., Contributors) have excessive permissions (Admin) on variable group, then integrity of your variable group can be compromised by a malicious user. Removing access/privileges that are not required minimizes exposure of the resources in case of user account/variable group compromise.", "Recommendation": "1.Navigate to the variable group. --> 2. Select Security. --> 3. Ensure broader groups have read-only access. Refer to detailed scan log (VariableGroup.LOG) for broader group list.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ", "MSW", "AutomatedFix" ], "Enabled": true }, { "ControlID": "ADO_VariableGroup_AuthZ_Restrict_Broader_Group_Access_On_VG_With_Secrets", "Description": "Broader groups (contributors, project valid users, etc.) should not have user/administrator privileges on variable group which contains secrets.", "Id": "VariableGroup170", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckBroaderGroupAccessForVarGrpWithSecrets", "Rationale": "If a broad group of users (e.g., Contributors) have excessive permissions on variable group, a malicious user can abuse these permissions to compromise security of the variable group as well as the assets involving the secret variables.", "Recommendation": "1. Navigate to the variable group. --> 2. Select Security. --> 3. Ensure broader groups have read-only access. Refer to detailed scan log (VariableGroup.LOG) for broader group list.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ", "MSW", "AutomatedFix" ], "Enabled": true } ] } |