Framework/Configurations/SVT/ADO/ADO.Build.json
|
{
"FeatureName": "Build", "Reference": "aka.ms/azsktcp/Build", "IsMaintenanceMode": false, "Controls": [ { "ControlID": "ADO_Build_DP_No_PlainText_Secrets_In_Definition", "Description": "Secrets and keys must not be stored as plain text in build variables/task parameters.", "Id": "Build120", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckCredInBuildVariables", "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_Build_Config_Add_Static_Code_Analyzer", "Description": "Consider adding static code analysis step in your pipelines.", "Id": "Build130", "ControlSeverity": "High", "Automated": "No", "MethodName": "", "Rationale": "Static code analyzers ensure that many kinds of security vulnerabilities are detected in early stages of software/service development.", "Recommendation": "Refer: https://docs.microsoft.com/en-us/azure/devops/articles/security-validation-cicd-pipeline?view=vsts#ci-continuous-integration", "Tags": [ "SDL", "TCP", "Manual", "Config" ], "Enabled": true }, { "ControlID": "ADO_Build_DP_Store_SecretFiles_in_Secure_Library", "Description": "Secure Files library must be used to store secret files such as signing certificates, Apple Provisioning Profiles, Android KeyStore files, and SSH keys", "Id": "Build140", "ControlSeverity": "Medium", "Automated": "No", "MethodName": "", "Rationale": "The contents of the secure files are encrypted and can only be used during the build or release pipeline by referencing them from a task.", "Recommendation": "Refer https://docs.microsoft.com/en-us/azure/devops/pipelines/library/secure-files?view=vsts", "Tags": [ "SDL", "TCP", "Manual", "DP" ], "Enabled": true }, { "ControlID": "ADO_Build_DP_Review_Inactive_Build", "Description": "Inactive build pipelines must be removed if no more required.", "Id": "Build150", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckForInactiveBuilds", "Rationale": "Each additional build having access to repositories increases the attack surface. To minimize this risk ensure that only active and legitimate build pipelines are present in your environment.", "Recommendation": "To remove inactive build pipelines follow the steps given here: 1.Navigate to the build pipeline. 2. Select a build pipeline. 3. Select three dots (present at right top). 4. Click on Delete. (https://www.azuredevopslabs.com/labs/devopsserver/build/)", "Tags": [ "SDL", "Best Practice", "Automated", "DP" ], "Enabled": true }, { "ControlID": "ADO_Build_AuthZ_Disable_Inherited_Permissions", "Description": "Do not allow inherited permission on build definitions.", "Id": "Build160", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckInheritedPermissions", "Rationale": "Disabling inherited permissions lets you finely control access to various operations at the build 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 build pipeline. 2. Select three dots (present at right top). 3. Click Manage Security 4. Add the service lead & service owner as Users with Allow permissions for each permission line item. 5. Disable Inheritance. 6. Add users/groups to your build definition and provide only required access. As best practice, All teams/groups must be granted minimum required permissions on build definition.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ" ], "Enabled": true }, { "ControlID": "ADO_Build_SI_Review_Variables_Settable_At_Queue_Time", "Description": "Pipeline variables marked settable at queue time should be carefully reviewed.", "Id": "Build170", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckSettableAtQueueTime", "Rationale": "Pipeline variables that are marked settable at queue time can be changed by anyone who can queue a build. Such variables can be misused for code injection/data theft attacks from pipelines.", "Recommendation": "1. Navigate to the build pipeline. 2. Click on Edit. 3. Select variables. 4. Uncheck 'settable at queue time' for such variables. 5. Save the build pipeline.", "Tags": [ "SDL", "TCP", "Automated", "SI" ], "Enabled": true }, { "ControlID": "ADO_Build_SI_Review_URL_Variables_Settable_At_Queue_Time", "Description": "Pipeline variables marked settable at queue time and containing URLs should be avoided.", "Id": "Build180", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckSettableAtQueueTimeForURL", "Rationale": "Pipeline variables that are marked settable at queue time can be changed by anyone who can queue a build. If these variables contain a URL then someone can change the URL to a server that they control and can intercept any secrets used to interact with the intended server by queueing a build.", "Recommendation": "1. Navigate to the build pipeline. 2. Click on Edit. 3. Select variables. 4. Uncheck 'settable at queue time' for such variables. 5. Save the build pipeline.", "Tags": [ "SDL", "TCP", "Automated", "SI" ], "Enabled": true }, { "ControlID": "ADO_Build_SI_Review_External_Sources", "Description": "Review external source code repositories before adding them to your pipeline.", "Id": "Build190", "ControlSeverity": "High", "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 the external source code repository used in the pipeline definition for vulnerabilities.", "Tags": [ "SDL", "TCP", "Automated", "SI" ], "Enabled": true }, { "ControlID": "ADO_Build_SI_Limit_Task_Group_Edit_Permission", "Description": "Do not use task groups that are editable by a broad pool of users.", "Id": "Build200", "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 build 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 Contributors 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_Build_SI_Restrict_Variable_Group_Edit_Permission", "Description": "Do not use variable groups that are editable by a broad group of users.", "Id": "Build210", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckVariableGroupEditPermission", "Rationale": "If a broad group 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 build 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", "MSW" ], "Enabled": true }, { "ControlID": "ADO_Build_AuthZ_Limit_Pipeline_Access", "Description": "Limit scope of access for build pipeline to the current project.", "Id": "Build220", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckBuildAuthZScope", "Rationale": "If pipelines use project collection level tokens, a vulnerability in components used by one project can be leveraged by an attacker to attack all other projects. This is also in keeping with the principle of least privilege.", "Recommendation": "1. Navigate to the build pipeline. 2. Click on Options. 3. Set 'Build job authorization scope' to 'Current Project'.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ", "SkipYAML" ], "Enabled": true }, { "ControlID": "ADO_Build_AuthZ_Restrict_Broader_Group_Access", "Description": "Do not allow build pipeline to have excessive permissions by a broad group of users.", "Id": "Build230", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckBroaderGroupAccess", "Rationale": "If a broad group of users (e.g., Contributors) have excessive permissions on a pipeline, a malicious user can abuse these permissions to compromise security of the pipeline.", "Recommendation": "1. Navigate to the build pipeline. --> 2. Click on Security. --> 3. Ensure 'Excessive' permissions of broader groups is not set to 'Allow'. Refer to detailed scan log (Build.LOG) for broader groups and excessive permissions list. --> 4. Repeat this for any other groups that should not have excessive permissions.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ", "MSW" ], "Enabled": true }, { "ControlID": "ADO_Build_DP_Dont_Make_Secrets_Available_To_Forked_Builds", "Description": "Do not make secrets available to builds for fork of public repository.", "Id": "Build240", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckForkedBuildTrigger", "Rationale": "For GitHub public repositories, it is possible that people from outside the organization can create forks and run builds on the forked repo. In such a case, if this setting is wrongly left enabled, outsiders can get access to build pipeline secrets that were meant to be internal.", "Recommendation": "1. Navigate to the build pipeline using resource link --> 2. Triggers --> 3. Pull request validation --> 4. Forks --> 5. Uncheck 'Make secrets available to builds of forks'.", "Tags": [ "SDL", "TCP", "Automated", "DP", "MSW" ], "Enabled": true }, { "ControlID": "ADO_Build_DP_Do_Not_Use_Forked_Repo_With_Self_Hosted_Agent", "Description": "Do not allow build pipeline to build code from forked repository on self-hosted agent.", "Id": "Build250", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckForkedRepoOnSHAgent", "Rationale": "If you use GitHub open-source projects, anyone with a GitHub account can fork your repository and propose contributions back. Since pipelines are associated with a repository and not with specific branches, you must assume the code and YAML files are untrusted. (https://docs.microsoft.com/en-us/azure/devops/pipelines/security/repos?view=azure-devops)", "Recommendation": "1. Navigate to build pipeline definition --> 2. Ensure the pipeline does not build code from a forked repository. --> 3. Ensure the pipeline doesn't build code on a self-hosted agent.", "Tags": [ "SDL", "TCP", "Automated", "DP" ], "Enabled": true }, { "ControlID": "ADO_Build_DP_Disable_CI_On_External_Sources", "Description": "Do not run continuous integration or scheduled builds on untrusted code from external or public GitHub repositories.", "Id": "Build260", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckCIScheduledBuildTrigger", "Rationale": "Build agents posess a token scoped to either current project or project collection. This token is available to builds triggered via the Continuous Integration and Scheduled Build mechanisms. If an adversary pushed a malicious commit to the upstream public GitHub repo, they can exfiltrate the token and use it to move laterally throughout the ADO organization (or Project).", "Recommendation": "1. Navigate to the build pipeline. -> 2. Triggers -> 3. Disable 'Continuous integration' and 'Scheduled' build.", "Tags": [ "SDL", "TCP", "Automated", "DP" ], "Enabled": true } ] } |