It is human nature to start thinking about a problem after it has already occurred – we don\u2019t like to learn from somebody’s mistakes, though it is a good idea. But what if we consider a situation when the GitHub online code repository stops working for a while? Well, such things happen sometimes, though GitHub is a highly reliable vendor with numerous compliance certificates and standards, like ISO\/IEC 27001:2013, GDPR, FedRAM LI-SaaS ATO, SOC 1, and SOC 2, and it is a Trusted Cloud Provider with CSA.<\/p>\n\n\n\n\n\n\n\n
Still, starting to use GitHub as a git repository service, it is great to know from the beginning what your responsibilities, as a user, are and what GitHub can guarantee. So, let\u2019s figure out what both parties are responsible for and how it works because usually customers don\u2019t even think about this mentioned Shared Responsibility Model. <\/p>\n\n\n\n\n\n
To understand how the Shared Responsibility Model really works, we should, first, define what it is. And to see what is the GitHub Shared Responsibility Model, we should know that every Software-as-a-Service (SaaS) provider operates due to those rules so GitHub, being a SaaS provider, has the same bunch of responsibilities. So, it is essential that they work according to data security measures, otherwise, nobody would use the service they provide. But what does this security policy include? <\/p>\n\n\n\n
The following model defines the security behavior and duties which should be done by a service provider and the ones which belong to the organization as a customer. Thus, it takes care of operating systems, network controls, applications, physical hosts, network and data centers, and partly for the identity and directory infrastructure. So, to explain it simply, the Shared Responsibility Model includes the protection of the entire environment, but not the separate account domain. <\/p>\n\n\n\n