{"id":67019,"date":"2023-03-30T12:40:32","date_gmt":"2023-03-30T11:40:32","guid":{"rendered":"https:\/\/www.microsoft.com\/en-gb\/industry\/blog\/?p=67019"},"modified":"2023-04-05T22:23:52","modified_gmt":"2023-04-05T21:23:52","slug":"securing-the-code-to-cloud-pipeline-with-github-and-azure","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-gb\/industry\/blog\/technetuk\/2023\/03\/30\/securing-the-code-to-cloud-pipeline-with-github-and-azure\/","title":{"rendered":"\u200b\u200b\u200bSecuring the Code to Cloud Pipeline with GitHub and Azure\u200b"},"content":{"rendered":"
\"A<\/figure>\n\n\n\n

DevOps is a modern application development and delivery approach that helps organisations to release quality software more quickly into production with less defects! Though DevOps itself is not a product, implementing its practices requires services and tools. Microsoft offers two widely used platforms for implementing DevOps practices \u2013 the Azure DevOps platform and the GitHub platform.\u202f <\/p>\n\n\n\n

Adopting a DevOps approach does not yield benefits in isolation, but rather in conjunction with other concepts such as Agile planning and Cloud computing. By utilising platforms such as GitHub for implementing DevOps practices and Azure for cloud services, organisations can achieve a continuous “Code to Cloud” process. This process emphasizes the use of modern CICD platforms to streamline software development for applications running on cloud-based infrastructure and services, including cloud-managed container orchestration platforms and serverless computing services, instead of relying on traditional on-premises servers and infrastructure. <\/p>\n\n\n\n

\"A
Figure 1<\/figcaption><\/figure>\n\n\n\n

Supply chain attacks <\/h3>\n\n\n\n

As organisations embrace this approach, security teams are faced with new challenges due to the increased velocity, automation, and decentralisation of the development process. Attackers are increasingly targeting organisations through their software development processes. This is where software supply chain security becomes crucial! The software supply chain encompasses everything necessary to create and deliver software, including IDEs, source control systems, build systems, deployment systems, CICD platforms, runtime environments, and various artifacts such as application code, open-source dependencies, infrastructure code, and deployment artifacts. <\/p>\n\n\n\n

Securing the software supply chain is not an easy task and requires a comprehensive and thorough approach. Figure 1 divides the GitHub to Azure code-to-cloud pipeline into five stages.  <\/p>\n\n\n\n

NOTE: <\/strong>GitHub offers multiple product options<\/a>, but this article will centre on GitHub Enterprise<\/a> which offers some capabilities that are not available in the other options. Specifically, I will emphasize security areas that I consider crucial but may be overlooked. <\/p>\n\n\n\n

Securing the DEVELOPMENT stage<\/strong> <\/h3>\n\n\n\n

The development stage is where the code is created, and the first step towards securing this stage is to ensure that developers are using a secure environment for development. A significant concern is the possibility of a compromised development environment resulting from the use of unpatched IDEs or the installation of vulnerable or malicious extensions. IDEs, like any other application, can contain vulnerabilities and require regular updates to ensure their security. A recent example is CVE-2022-41034, a critical vulnerability disclosed for Visual Studio Code that allows for remote code execution on any system with the IDE installed.  <\/p>\n\n\n\n

Using a managed development environment like GitHub Codespaces<\/a><\/em><\/strong> provides the advantage of quickly applying necessary patches to ensure the environment’s security. In addition to this, each Codespaces environment runs on its own freshly built isolated virtual machine and network with a firewall used to block incoming connections from the internet and internal networks.  <\/p>\n\n\n\n

Codespaces also  <\/p>\n\n\n\n

Securing the SOURCE CONTROL stage<\/strong> <\/h3>\n\n\n\n

The source control stage is where the code is stored, discussed, and managed, and it is essential to ensure that the source code repository is secure. This starts with access controls and permissions. Only authorised individuals should have access to our repositories.  <\/p>\n\n\n\n

To access GitHub enterprise services and resources, users need to be authenticated. There are three methods for adding users to our GitHub Enterprise organisation for access (Figure 2).  <\/p>\n\n\n\n

\"A
Figure 2<\/figcaption><\/figure>\n\n\n\n

The first option is to invite users with their personal GitHub account<\/em><\/strong> which enables them to authenticate through GitHub.com and access our organisation resources. With this option, the user maintains control of their identity (since it is their personal account), and can continue to contribute to other enterprises, organisations, and repositories outside of our organisation. <\/p>\n\n\n\n

The second option is to use <\/em><\/strong>an external identity provider<\/em><\/strong> that supports SAML single sign-on<\/em><\/strong><\/a>. With this option, users authenticate with an identity in the external SAML provider that is linked to a personal GitHub identity. This means that while users are still utilising a GitHub identity to access our organisation’s resources, the actual authentication takes place through the external identity provider. The identity can be used for contributions to other enterprises, organisations, and repositories outside of our organisation. <\/p>\n\n\n\n

The third option is to use <\/em><\/strong>“Enterprise Managed Users\u201c – EMU<\/em><\/strong><\/a> which is similar to other single sign-on solutions. With EMU, users will access GitHub organisation resources using a single identity created and managed in the external identity provider. They do not need to have a personal GitHub identity. This gives the most control for enterprise users. <\/p>\n\n\n\n

The recommendation, if you are an enterprise, is to use either the second option or the third option.<\/strong> <\/p>\n\n\n\n

To perform any actions on GitHub, such as creating a pull request in a repository, a person must have sufficient access to the relevant resource. This access is controlled by permissions. A permission is the ability to perform a specific action. For example, the ability to delete an issue is a permission. A role is a set of permissions you can assign to individuals or teams. <\/p>\n\n\n\n

GitHub supports roles at different levels depending on what we are looking to achieve: <\/p>\n\n\n\n