What has been one of the most impressive and breakthrough developments of the 2000s in the IT world? No doubt, Git! This version control system was presented by Linus Torvalds in 2005. It became so popular due to a number of things. First, its performance, then flexibility and wide acceptance. And finally, git made it possible for DevOps to commit, share, and solicit feedback on the changes in the code fast and easily. All of that in a bulk confirms the creator’s words that “git is a very powerful set of tools.”
Though, git hosting services, like GitHub made it easier for developers to work with git. Both of them, git and GitHub, go hand in hand yet have some set of security and compliance regulations that companies need to deal with.
GitHub as any other service provider follows the Shared Responsibility Model. Why do we mention it here? Because this model differentiates the obligations of both sides, as provider’s as user’s.
In this article we would like to reveal some GitHub compliance regulations that any CTO, Security leader or VP of R&D should keep in mind. So what is compliance and why do we value it so much?
GitHub Compliance
GitHub is proud to put security at the core of everything they do, inspiring and enabling the community to secure the open source software (and not only) users depend on. As a leading player in the world, it not only follows, but also sets security trends. Now, let’s take a look at the most important security standards GitHub has already passed and widely-implemented:
- First of all – Data Privacy – GitHub applied stringent individual privacy protections to all GitHub users worldwide.
- GDPR – obviously, GitHub is compliant with GDPR regulations and provides its customers with the ability to access and control the information it collects and processes about them.
- SOC 1 and SOC 2 – there is no doubt that GitHub Enterprise Cloud meets SOC 1 Type 2 and SOC 2 Type 2 Compliance reports with IAASB International Standards on Assurance Engagements, ISAE 2000, and ISAE 3402 Certification.
- FedRAMP LI-Saas Authorization to Operate (ATO) – GitHub complies with the low impact software-as-a-service baseline of security criteria, which ensures that government users can safely keep their projects on GitHub Enterprise Cloud.
- Cloud Security Alliance – GitHub is a Trusted Cloud Provider with the Cloud Security Alliance.
- And finally, ISO/IEC 27001:2013 – GitHub’s Information Security Management System (ISMS) has passed ISO/IEC 27001:2013, which means that the service provider meets all the necessary international security requirements within this certification, including Confidentiality, Integrity, and Availability.
All organization owners of GitHub Enterprise Cloud can access GitHub Compliance reports easily. All they need to do is to go to their organization settings, choose the “Security” section and click on the “Compliance”. Then they can simply download or view GitHub’s reports – easy and transparent as you see!
What are your Compliance and Certifications Requirements?
If you’re reading this article, probably you want to do a double check – your organization is in the certification process, and you use GitHub to host the source code (the most valuable IP in your company), so you need to ensure both GitHub and all third-party apps meet your requirements and have the security standards in place on their own.
Though, if you consider security certification and are about to get ready or just want to comply with the Shared Responsibility Model, in all the mentioned cases, let’s take a look at the most common standards as well as security aspects you should take into account when using GitHub and GitHub-related third-party apps.
When it comes to compliance with security standards, we should clearly understand that depending on the target industry all those standards will vary. If we speak about the IT sector the compliance requirements here come down to the assurance that all the business processes and the sensitive data, including customer’s data, are secure and won’t be accessed by any unauthorized party.
In a nutshell: the majority of compliance standards focus on such areas as:
- categorization of data
- access control
- permissions
- the integrity of the source code
- auditing and access review
- backup and recovery
And let’s take a closer look at some of the Compliance Audits and Certifications before we get into explaining all those standards in detail:
SOC 2
All SaaS solution providers try to achieve compliance with SOC 2 Standard as it means that the service they provide is compliant with a chosen number of five major grounds of AICPA (the American Institute of Certified Accounts). It proves that the SaaS organization has built their service following such international requirements as Security, Availability, Processing Integrity, Confidentiality, and Privacy.
Though, it’s worth mentioning that there are two types of SOC 2 Certification – SOC 2 Type 1 and SOC 2 Type 2.
SOC 2 Type 1
First, what it’s worth mentioning about the SOC 2 Type 1 report is the fact that it deals with the specifics of a system within some particular point in time. It means that the explanation of the controls and examination of the supporting documentation will serve as the foundation for the auditor’s report. The compliance with SOC 2 Type 1 report gives proof that a SaaS company is compliant with the AICPA auditing process and has best security practices in place to deal with critical data protection.
If you want to learn more about SOC 2 Type 1, you can read GitProtect.io’s experience in passing this security Audit.
SOC 2 Type 2
SOC 2 Type 2 report covers the same principles that SOC 2 Type 1 report and applies the best practices on data security and control systems. Though, there is a difference. Unlike SOC 2 Type 1 Audit, which covers the design effectiveness of internal controls as of some specific point in time, SOC 2 Type 2 covers a much longer period of time (which actually can range from 6 months to 12 months). And it deals with the thorough examination of internal controls and their performance over time to meet predetermined objectives. Thus, it delves further into standards of data protection and is more desirable to obtain by the companies dealing with data.
ISO 27001
This standard is mostly focused on information security management systems (ISMS). If the company has passed ISO 27001 Certification, it means that the organization follows international standards for Confidentiality, Integrity, and Availability and can guarantee its own and its customers’ data safety.
GDPR
The General Data Protection Regulation stands as a regulation in EU law. It protects the security and privacy of data which belong to EU citizens and residents.
HIPAA
Health Insurance Portability and Accountability Act refers to a set of regulatory standards and defines the lawful use and disclosure of the protected health information.
DCID
Compliance with the Director of Central Intelligence Directive refers to the security practices the organization uses to protect and secure highly classified intelligence information systems.
What are the Compliance Requirements?
We have already mentioned that compliance requirements refer to the rules and regulations that the company has to follow to meet legal, industry, or other standards. So, let’s go through all of them one by one.
Data Location As a First Concern
“Where to keep the data?” – this question is probably the first that comes to mind when we speak about incorporating GitHub into our organization. Let’s remember that compliance with security standards requires the data to be accessible anytime. So, the question of using GitHub on SaaS or on-premise Enterprise is an open one.
Yeap… your decision may be influenced by many factors connected to your area of expertise and compliance requirements of this field. For example, the regulations for the financial sector will drastically vary from those that the medical field has.
However, sometimes it is prohibited to use GitHub’s hosted options under the compliance regulations. Let’s say some critical data, like source code, infrastructure documentation, or configuration data need special treatment and security. Thus, to prevent data loss your industry may require to keep the copy of your data in a few places. For example, it can be both on-premise and Cloud, or data replication to a few different clouds.
Access and Identity Control
When it comes to data security, one of the main compliance concerns the organization has is how to protect your GitHub account from unauthorized access. As it is you who should control and monitor access to your GitHub repositories, how this access is managed, and how to cancel that access permissions.
Here are two options depending on what GitHub plan the organization has. Let’s first look at the GitHub Enterprise Cloud. This solution usually induces the enterprise owners to use SAML single sign-on (SSO). This way of authentication helps the organization to secure and control access to its GitHub ecosystem, including repositories, issues, and pull requests. With this kind of authentication the organization decides who can access its GitHub repos and metadata by inviting (also the personal) accounts on GitHub to join its organization, and allowing them to contribute to their organization.
For those who manage directly in GitHub, the service provider advises to use 2-factor authentication (2FA) to access their repositories. Using this feature, users can prevent unauthorized access as they need to use two different devices or pieces of information – usual password, and approval via the telephone – is the most popular one.
Access Permissions and Role-Based Access Control
The organizations that use GitHub Enterprise can grant different access permissions to their employees as not all of them need to have the equal permissions. It helps to avoid not only authentication problems, when every member of the team has the same access rights and can share it by mistake or, even worse… intentionally.
Thus, enterprises can use Role-based access control (RBAC) and customize a set of permissions for teams and users when adding them to repositories, specifying their role.
Third-Party Access – Control Over Data Sharing
Following the GitHub Compliance requirements, the organization should pay a lot of attention to what access they grant to third-party GitHub apps, OAuth integrations, API integrations, and other related applications.
Why shouldn’t the organization grant exceptional access to any third-party tool? If you decide to use any third-party tool (even if you find it on GitHub Marketplace), GitHub doesn’t take any responsibility for that, as those third-party tools are neither owned or maintained by GitHub. And under the Shared Responsibility Model, you are the only one who is responsible for your company’s data security. Thus, as soon as you decide to integrate any third-party GitHub application, make sure that your team controls, monitors, and audits it on a regular basis.
Monitoring And Reporting
Your source code is your intellectual property and the most critical data you have. So, it is natural to look for the best ways to protect it. We have mentioned access controls, permissions and roles, third-party roles in your building process, yet we haven’t mentioned monitoring as a part of security.
You can monitor activity in your GitHub Enterprise using audit logs, which GitHub Enterprise Cloud provides to support internal and external compliance.
Ransomware Protection
Ransomware and malware is a crucial topic when it comes to data protection. Just let’s remember the latest high-severity vulnerabilities, data breaches and stolen credentials – Okta’s source code breach, Dropbox, Tayota, Slack. Here comes the already-mentioned Shared Responsibility Model according to which the organization takes care of all its data in GitHub repositories.
The organization should build a ransomware-proof strategy and use third-party tools to detect vulnerabilities and suspicious activity in its GitHub environment. Moreover, it implies organizations have a backup plan in place.
Backup As a Data Loss Prevention Measure
GitHub as a service provider performs backup of its entire system and all the data users have on the platform. So, if there is a massive GitHub outage, the git service provider can restore all the data up to the moment before the failure happened. They even developed a programme to keep the open source data for future generations.
However, when we speak about GitHub Compliance, we shouldn’t look at backup on infrastructure-level. To stay compliant and pass international security audits, the organization should have an account-level backup of their data in place – for all repositories and metadata. Thanks to such a solution, the organization can mitigate negative effects of ransomware attacks, human errors and keep on working even during serious outages.
Moreover, it’s nice to organize backups following GFS, or 3-2-1 backup rule – three backup copies to two different storage instances, one of which is offsite. All of that will help to perform fast recovery in case of system failure, emergency or security situation.
Disaster Recovery As an Incident Response Measure
Data accessibility is one of the main requirements of Compliance. We have already mentioned that GitHub makes backups of the entire service. Thus, it may perform a recovery of the entire service. When it comes to recoverability of some separate repositories and metadata, it is on the shoulders of the company.
Thus, the organization should be sure that it has a response to any disaster scenario – the entire GitHub service outage or the organization’s GitHub environment failure. In the ideal world, the company should have a possibility to perform granular recovery, cross-over recovery to another git hosting service provider (e.g. from GitHub to GitLab or Bitbucket), and restore to the on-premise device – of all repositories and metadata.
Takeaway – Corporate Security Policy
Summing up all the mentioned above, every organization which uses GitHub should organize its source code security along with strict GitHub Compliance requirements. It can seem burdensome and complex if the company decides to arrange everything by itself. It can lead to DevOps team productivity decrease, as they will need to think not only about their core duties, but also about compliance needs, and bring extra costs in the long-term.
Though, the organization can decrease the GitHub Compliance responsibilities by adopting right strategies and practices to boost their GitHub repositories and metadata security. GitHub Backup plays one of the leading roles, and is one of the main requirements for GitHub Compliance.
✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights
🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial
📅 Let’s discuss your needs and see a live product tour
Top comments (0)