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 }, { "ControlID": "ADO_VariableGroup_AuthZ_Enable_Branch_Control", "Description": "Allow variable groups to be accessed only by select branches.", "Id": "VariableGroup180", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckBranchControlOnVariableGroup", "Rationale": "Once a variable group is made accessible to a YAML pipeline, malicious users with 'create branch' permissions on the repository will be able to access the variable group by queueing the pipeline from the branch they select even if they do not have access to the variable group. To prevent this ensure that the variable group can be accessed only from select branches (eg. 'main').", "Recommendation": "1. Navigate to the variable group --> 2. Click on 'Approvals and Checks' --> Create a branch control --> Provide the branches from which you would like the variable group to be accessed from. For additional protection, enable 'Verify branch protection'.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ" ], "Enabled": true }, { "ControlID": "ADO_VariableGroup_DP_Review_Inactive_VariableGroup", "Description": "Inactive variable groups must be removed if no more required.", "Id": "VariableGroup190", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckInactiveVarGrp", "Rationale": "Variable groups may contain sensitive information such as secret variables or secrets from a key vault. Thus each inactive variable group can increase the exposure of such important information to a malicious user. To minimize this risk ensure that inactive variable groups are proactively deleted.", "Recommendation": "1. Navigate to library --> 2. In the variable groups tab identify the inactive variable group --> 3. Click on the three dots --> 4. Select 'Delete'", "Tags": [ "SDL", "TCP", "Automated", "DP", "AutomatedFromCloudmine" ], "Enabled": true }, { "ControlID": "ADO_VariableGroup_DP_Use_Template_From_Protected_Branch", "Description": "Allow variable groups to be accessed by templates only from protected branches.", "Id": "VariableGroup200", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckTemplateBranchForVarGrp", "Rationale": "If malicious users have 'contribute' permissions to the repository containing the template required to access the variable group, they can tamper the template itself and misuse the variable group. To prevent this, enable branch protection policies on the branch which contains the template required to access this resource.", "Recommendation": "1. Navigate to project settings --> 2. Select 'Repositories' under 'Repos' --> 3. Select the repository which has YAML template --> 4. From the 'Policies' tab select the branch used in the template check from 'Branch Policies' --> 5. Enable any branch policy suitable according to your use case.", "Tags": [ "SDL", "TCP", "Automated", "DP" ], "Enabled": true }, { "ControlID": "ADO_VariableGroup_Dont_Grant_Broader_Group_Access_As_Approvers", "Description": "Broader groups (contributors, project valid users, etc.) should not be added as approvers on variable group.", "Id": "VariableGroup210", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckBroaderGroupApproversOnVarGrp", "Rationale": " Any user/ group can be added as an approver to the variableGroup, which gives users the permission to approve any run of pipelines accessing the resource even if they do not have access to the variableGroup. To prevent illegitimate consumption and approval of the resource, ensure that broader groups are not added as approvers.", "Recommendation": "1. Navigate to the variableGroup --> 2. Click on 'Approvals and Checks' --> Remove Broader groups from Approvals. Refer to detailed scan log (VariableGroup.LOG) for broader group list.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ" ], "Enabled": true } ] } |