Framework/Configurations/SVT/ADO/ADO.Release.json
|
{
"FeatureName": "Release", "Reference": "aka.ms/azsktcp/Release", "IsMaintenanceMode": false, "Controls": [ { "ControlID": "ADO_Release_AuthZ_Grant_Min_RBAC_Access", "Description": "All teams/groups must be granted minimum required permissions on release definition.", "Id": "Release110", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckRBACAccess", "Rationale": "Granting minimum access by leveraging RBAC feature ensures that users are granted just enough permissions to perform their tasks. This minimizes exposure of the resources in case of user/service account compromise.", "Recommendation": "Refer: https://docs.microsoft.com/en-us/azure/devops/pipelines/policies/permissions?view=vsts and https://microsoftit.visualstudio.com/OneITVSO/_wiki/wikis/OneITVSO.wiki?wikiVersion=GBwikiMaster&pagePath=%2FEngineering%20Guide%2FOneITVSO%2FDevelopment%2FRelease%2FHow%20To%20Secure%20Your%20Release%20Definition&pageId=2419&anchor=desired-state", "Tags": [ "SDL", "TCP", "Automated", "AuthZ", "RBAC" ], "Enabled": true }, { "ControlID": "ADO_Release_DP_No_PlainText_Secrets_In_Definition", "Description": "Secrets and keys must not be stored as plain text in release variables/task parameters.", "Id": "Release120", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckCredInReleaseVariables", "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": "Refer: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=vsts&tabs=yaml%2Cbatch#secret-variables", "Tags": [ "SDL", "TCP", "Automated", "DP" ], "Enabled": true }, { "ControlID": "ADO_Release_DP_Review_Inactive_Release", "Description": "Inactive release pipelines must be removed if no more required.", "Id": "Release130", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckForInactiveReleases", "Rationale": "Each additional release having access to repositories/other artifacts increases the attack surface. To minimize this risk ensure that only active and legitimate release pipelines are present in your environment.", "Recommendation": "To remove inactive release pipeline follow these steps: 1.Navigate to the release pipeline. 2. Select a release pipeline. 3. Select three dots (present in right top). 4. Click on Delete.", "Tags": [ "SDL", "Best Practice", "Automated", "DP" ], "Enabled": true }, { "ControlID": "ADO_Release_AuthZ_Disable_Inherited_Permissions", "Description": "Do not allow inherited permission on release definitions", "Id": "Release140", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckInheritedPermissions", "Rationale": "Disabling inherited permissions lets you finely control access to various operations at the release 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 permission inheritance within a release pipeline follow these steps: 1.Navigate to the release pipeline. 2. Open up the Security dialog for the release. 3. Add the service lead & service owner as Users with Allow permissions for each permission line item. 4. Select Off under Inheritance. 5. Add users/groups to your release definition and provide only required access. As best practice, All teams/groups must be granted minimum required permissions on release definition.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ" ], "Enabled": true }, { "ControlID": "ADO_Release_AuthZ_Enable_PreDeployment_Approvals", "Description": "Releases pipeline for production deployments must have pre-deployment approval enabled.", "Id": "Release150", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckPreDeploymentApproval", "Rationale": "Pre-deployment approvals give you an additional layer of defense against inadvertent (or possibly malicious) changes to your production environment.", "Recommendation": "To enable pre-deployment approval within a release pipeline follow the steps mentioned here: https://docs.microsoft.com/en-us/azure/devops/pipelines/release/define-multistage-release-process?view=azure-devops#add-approvals-within-a-release-pipeline.", "Tags": [ "SDL", "TCP", "Best Practice", "Automated", "AuthN" ], "Enabled": true }, { "ControlID": "ADO_Release_AuthZ_Review_PreDeployment_Approvers", "Description": "Only legitimate users should be added as approvers for releases.", "Id": "Release160", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckPreDeploymentApprovers", "Rationale": "Periodic review of approvers list for production releases ensures that only appropriate people are members of such a critical role. As team composition/membership changes, this privilege may need to be revoked from members who are no more in the team.", "Recommendation": "Refer detailed log file to review the list of approvers.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ" ], "Enabled": true }, { "ControlID": "ADO_Release_SI_Use_Good_Branch_Hygiene", "Description": "All releases to production or pre-production stages must be done from one and only one (main) branch.", "Id": "Release170", "ControlSeverity": "Medium", "Automated": "No", "MethodName": "", "Rationale": "You should ensure that production releases are always done from one and only one (main) branch. The main branch should have the tightest access controls and approval standards. Any changes in the source code should be tested first on a development branch before merging in the main branch. The source code in the main branch should correspond to production bits at all times. This helps in maintaining stable source code and helps prevent deployment of breaking changes (and potential security bugs) into the production environment.", "Recommendation": "You can choose a specific branch as the main branch for production releases (most teams use 'master'). When adding the source/artifact for a release configuration for a production release (as in steps at https://docs.microsoft.com/en-us/azure/devops/pipelines/release/artifacts?view=azure-devops#sources, make sure you use the designated branch as the source.", "Tags": [ "SDL", "TCP", "Manual", "SI" ], "Enabled": true }, { "ControlID": "ADO_Release_SI_Review_External_Sources", "Description": "Review external source code repositories before adding them to your pipeline.", "Id": "Release180", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckExternalSources", "Rationale": "Building code from untrusted external sources can allow an attacker to execute arbitrary code in your pipeline. Hence, all repositories added to the pipeline should be carefully reviewed.", "Recommendation": "Validate all the source repos in the release definition.", "Tags": [ "SDL", "TCP", "Automated", "SI" ], "Enabled": true }, { "ControlID": "ADO_Release_SI_Review_Variables_Settable_At_Release_Time", "Description": "Pipeline variables marked settable at release time should be carefully reviewed.", "Id": "Release190", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckSettableAtReleaseTime", "Rationale": "Pipeline variables that are marked settable at queue time can be changed by anyone who can create a release. Such variables can be misused for code injection/data theft attacks from pipelines.", "Recommendation": "1. Navigate to the release pipeline. 2. Click on Edit. 3. Select variables. 4. Uncheck 'settable at release time' for such variables. 5. Save the release pipeline.", "Tags": [ "SDL", "TCP", "Automated", "SI" ], "Enabled": true }, { "ControlID": "ADO_Release_SI_Review_URL_Variables_Settable_At_Release_Time", "Description": "Pipeline variables marked settable at release time and containing URLs should be avoided.", "Id": "Release200", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckSettableAtReleaseTimeForURL", "Rationale": "Pipeline variables that are marked settable at queue time can be changed by anyone who can create a release. If these variables contain a URL then someone can change the URL to a server that they control and can intercept any secret used to interact with the intended server by creating a release.", "Recommendation": "1. Navigate to the release pipeline. 2. Click on Edit. 3. Select variables. 4. Uncheck 'settable at release time' for such variables. 5. Save the release pipeline.", "Tags": [ "SDL", "TCP", "Automated", "SI" ], "Enabled": true }, { "ControlID": "ADO_Release_SI_Disable_Task_Group_Edit_Permission", "Description": "Do not use task groups that are editable by a broad pool of users.", "Id": "Release210", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckTaskGroupEditPermission", "Rationale": "If a broad pool of users (e.g., Contributors) have edit permissions on a task group, then integrity of your pipeline can be compromised by a malicious user who edits the task group.", "Recommendation": "1. Navigate to the release pipeline. 2. Click on Tasks. 3. Right click on each task group and select 'Manage task group'. 4. Select 'Security' for the task group. 5. Ensure 'Edit task group' permission of Contributor is not set to 'Allow'. 6. Repeat this for any other groups that should not have edit access.", "Tags": [ "SDL", "TCP", "Automated", "SI" ], "Enabled": true }, { "ControlID": "ADO_Release_SI_Disable_Variable_Group_Edit_Permission", "Description": "Do not use variable groups that are editable by a broad pool of users.", "Id": "Release220", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckVariableGroupEditPermission", "Rationale": "If a broad pool of users (e.g., Contributors) have edit permissions on a variable group, then integrity of your pipeline can be compromised by a malicious user who edits the variable group.", "Recommendation": "1. Navigate to the release pipeline. 2. Click on Variables. 3. Click on each variable groups used in the pipeline. 4. Select 'Security' for the variable group. 5. Ensure Contributors have only reader access to the variable group. 6. Repeat this for any other groups that should not have edit access.", "Tags": [ "SDL", "TCP", "Automated", "SI" ], "Enabled": true } ] } |