- You are here:
- Security
Security of GitLab by Being an Open-Source Product
GitLab CE is open source and has over 700 contributors. This means there have been over 700 pairs of eyes looking at the GitLab CE source code. GitLab EE is open-core, which means the source code is also open for inspection to our customers.
GitLab Development Guidelines
- Guidelines for shell commands in the GitLab codebase
- For community contributions, we enforce style guides
- In addition, both for community contributions and for internal development, we use brakeman and RuboCop run by GitLab CI.
- We engage security experts to do white box testing such as fault injection (manual), penetration testing (manual) and vulnerabilities testing (both automatic, and manual)
GitLab also has a responsible disclosure program.
Governance
- Do you maintain a quality management system (QMS) approved by management? In lieu of a formal and static QMS, GitLab has a dynamic and responsive approach to quality management. Does your quality management system (QMS) include coverage for software application security principles?
- Is quality management system (QMS) content published and communicated to all relevant employees?
- Is quality management system (QMS) content reviewed and updated (if appropriate) at least once per year?
- It is considered a constant Work In Progress; and updated almost daily in small increments.
- Is there defined management oversight who is responsible for application quality and security reporting & signoff?
- YES. See our team page (search for "Merge request endboss"). Also see code review guidelines which mentions the endbosses, and stresses team-wide code review.
- Is access to and maintenance of applications, systems, network components (including routers, databases, firewalls, voice communications servers, voice recording servers, etc), operating systems, virtualization components, hypervisors, or other information objects restricted to authorized personnel only?
- Is access to and maintenance of applications, systems, network components (including routers, firewalls, voice communications servers, voice recording servers, voice response units (VRU) etc), operating systems, virtualization components, hypervisors, or other information objects granted based upon need-to-know job function?
- For all IT systems including but not limited to servers, routers, switches, firewalls, databases, and external social spaces, is management approval required prior to creating all user and privileged accounts (e.g., system or security administrator)?
- For all IT systems including but not limited to servers, routers, switches, firewalls, databases are privileged accounts (e.g., system or security administrator) logged at all times and reviewed on at least a quarterly basis?
- Are all user accounts (including, but not limited to, standard user, system administrator, security administrator, internal social spaces, etc) assigned to an individual employee and not shared?
- Are all user accounts disabled after no more than ten unsuccessful logon attempts?
- For all IT systems (including but not limited to servers, routers, database, switches, firewalls, external social spaces), are inactive user and privileged accounts (e.g., system administrator or security administrator) disabled after 90 days or more?
- Is a user's identity verified before communicating an initial/temporary password or initiating a password reset by an automated or manual process?
- Do application, system, and device passwords (including routers, firewalls, databases, and external social spaces) require passwords to have the following characteristics: 1. minimum length of 8 characters, 2. chosen from any acceptable character sets available on the target system, 3. includes at least one alphabetic and one numeric character.)
- Are passwords prevented from being displayed in clear text during user authentication or in electronic/printed reports?
- Are passwords/PINs sent to users utilizing a secure method (e.g. secure e-mail) and sent separately from other authentication information such as the user account?
- For all IT systems (including but not limited to servers, routers, databases, switches, firewalls), are user and privileged account (e.g., system or security administrator) passwords changed at least every 90 days?
- Are users required to authenticate prior to changing their password?
- Are all system, application and device password files encrypted using an industry standard encryption algorithm where technically feasible?
- In instances where a software token is used to access an application or system, is a password or PIN required?
- In instances where a software token is used to access an application or system, are stored keys and software token files encrypted using an industry standard algorithm and smartcards compliant to FIPS level 2 or above?
- For externally hosted environment, is there separation of administrative access between the hosting infrastructure/platform and the hosted platform and data?
- If user accounts are assigned to non-permanent personnel (e.g., contractors, consultants) for troubleshooting purposes, are the accounts disabled or removed after each use?
- Is the retirement or replacement of encryption keys included in key management procedures when the integrity of the key has been weakened (such as departure of an employee with key knowledge) or keys are suspected of being compromised?
- If you use cloud services, do you ensure that confidential data or an aggregation of proprietary information that can reveal confidential information is encrypted to ensure confidentiality at rest and in transit?
- If you use cloud services, do you have key management procedures to manage and maintain encryption keys?
Software Development Life Cycle (SDLC)
- Are there documented processes, procedures, standards and templates used in your SDLC process?
- Do the materials above include references to application security best-practices and principles being followed?
- Are design and code reviews performed as part of your SDLC processes?
- Are security considerations (checklists, standards and policies) referenced in the design and code review?
- Is app security threat modeling performed when deemed appropriate (i.e. new or changed architectures and approaches)?
- Is application code managed in a secure configuration management system with access controls?
- Is there a configuration management plan and are release artifacts maintained in a configuration management system?
- Are test plans and records kept that reflects the tests performed and results observed for each release?
- Is security testing defined and included in the test plan for each release?
- Is a release criteria defined, measured and reported on to confirm targeted release quality is achieved?
- YES. We do manual QA testing for each monthly release and deploy all new versions on GitLab.com to be our own test subjects.
- Are specific application security characteristics and measures part of the defined release criteria?
- Do you work with third parties that may have access to your IP and sensitive data?
- N/A w.r.t. code, as our code is all open-source (community edition) or open-core (enterprise edition).
- If so, is access to data controlled by terms of Non-Disclosure Agreements?
Training
- Is Internal company training available & performed commensurate with personnel roles and responsibilities?
- YES; peer-to-peer training is commonplace.
- Does training include security awareness?
- YES; as applicable for the role.
- Does training include education on policies, standards, procedures and updates when needed?
- Are personnel training plans and records kept for internal company compliance purposes?
- Tasks and training completed during onboarding are recorded.
Validation
- Are results from the execution of test plans reported and used to track and justify release readiness?
- YES. We require all automated tests to pass before any official release (monthly and patch versions), and perform manual QA testing for each monthly release.
- Does the quality assurance organization have authority to delay shipment of releases due to non-conformance reasons?
- Is some form of static code scanning performed as part of the release acceptance? What tools are used?
- YES. For example, brakeman and bundler-audit are part of our test suite to be alerted to any security issues in our dependent Ruby libraries.
- Is some form of dynamic code scanning performed as part of the release acceptance? What tools are used?
- YES. We use GitLab CI for this purpose.
Security Response
- Do you have a documented company security incident response process?
- Do your maintenance releases include fixes for both quality and security related issues?
- Do you provide dedicated security patches for software versions that are released and supported in the field? How?
- YES, for the latest release and the three prior monthly releases, when applicable.
- Is there proactive notification provided to customers and software partners (PTC)? How?
- YES. Notifications in the "version check" image, blog posts, tweets, and a mailing list just for security fixes.
- Do you have a formal risk severity classification assessment approach?
- Is there a specified response policy that includes the timeframe issues are to be addressed?
Business Continuity Plan
GitLab, by it's remote-only nature, is not easily affected by typical causes of business disruption, such as local failures of equipment, power supplies, telecommunications, social unrest, terrorist attacks, fire, or natural disasters. Even so, threats considered in the context of business continuity are categorized by impact of the disruption.
P1: Outage would have immediate impact on GitLab customer / user operations
- Disruption of service of Azure, specifically the region in which GitLab.com and dev.gitlab.org are hosted.
- Effect: a loss of the Azure service means that GitLab.com is not available. This affects anyone who uses GitLab.com to host their repositories. GitLab.com is also the primary server where GitLab CE and EE source code and packages are hosted.
- Solution(s): There are many other servers across the globe where GitLab CE is readily available.
- Effect: Security releases are developed and staged on dev.gitlab.org before being brought to production on GitLab.com; these may be lost or unavailable for the duration of the disruption.
- Solution(s): Depending on the duration and nature of the disruption, the solution is to wait for service to be restored (minimal duration), or build a new staging server. Using VM snapshots, recovery from backup is relatively quick.
- Unavailability of support staff in case of customer emergency.
- Effect: emergency response times are greater than intended.
- Solution(s): The team is distributed geographically (except during team get-togethers). Customer emergencies are handled by any person who is in the on-call rotation. The on-call load is distributed at many levels, service engineers, production engineers, and even developers can be summoned when we have an outage or a customer incident. Emergencies also trigger automatic notifications on our internal chat system, alerting the entire company. There is also an ongoing effort to publish our runbooks, explaining how we manage our infrastructure and how we deal with outage cases.
- Disruption of service of ZenDesk.
- Effect: support workflows are disrupted. New tickets cannot be created, existing tickets cannot be responded to.
- Solution(s): For the duration of the outage (if more than e.g. 4 hours) temporarily re-route incoming support requests to individual email accounts of members of the support team. Customers with premium support also have access to a direct chat channel.
P2: Outage would have immediate impact on GitLab ability to continue business
- Malicious Software (Viruses, Worms, Trojan horses) attack.
- Effect: depends on attack.
- Solution(s): All the hosts in our fleet are running rkhunter every day to check for known rootkits. We get notifications whenever we detect a change in any of our hosted systems. Each case is handled manually for now.
- Hacking or other Internet attacks.
- Effect: depends on attack.
- Solution(s): We log and track any access that happens on any server in the fleet using logstash/kibana at log.gitlap.com.
P3: Outage greater than 72 hours would have impact on GitLab ability to continue to do business
Disruption of service from Salesforce.com, Zuora - No failover plan currently.
P4: Outage greater than 10 business days would have impact on GitLab ability to continue business
Disruption of service from TriNet, NetSuite, Google (gmail) - No failover plan currently.
P5: Non critical system
Disruption of service from Egencia, or internal chat tool. - No failover plan currently.
