Security Control Framework

3/4/2026

This post details the creation of the GitLab Control Framework (GCF) from scratch. It outlines the process of analyzing requirements, learning from industry frameworks (NIST SP 800-53, CSF, SCF, CCF), creating 18 custom control domains (e.g., AAM, AIM, ASM, BCA, CHM, CSR, DPM, EPM, GPM, IAM, INC, ISM, PAS, PSM, SDL, SRM, TPR, TVM), and implementing a two-level hierarchy (Level 1 framework, Level 2 product-specific implementation) to manage controls across different GitLab offerings. It also highlights the extensive metadata captured for each control to operationalize the framework.

1/7/2026

This post details the OWASP Top 10 2025 list, highlighting new categories like 'Software Supply Chain Failures' and 'Mishandling of Exceptional Conditions', and explains how GitLab Ultimate's security scanning features (SAST, IaC scanning, Dependency Scanning, DAST, API Security Testing, Web API Fuzz Testing) map to these risks, enabling detection and management of vulnerabilities within the CI/CD pipeline and vulnerability reports.

11/24/2025

This post details the discovery and technical analysis of a widespread npm supply chain attack involving a destructive malware variant. It outlines the malware's multi-stage infection vector, credential harvesting techniques (GitHub, npm, cloud), data exfiltration methods using attacker-controlled GitHub repositories, and its worm-like propagation mechanism within the npm ecosystem. A critical component is the 'dead man's switch' payload that triggers data destruction if the malware loses access to its infrastructure. The post also provides indicators of compromise and explains how GitLab's Dependency Scanning can help detect this campaign.

8/6/2025

This post details the discovery and analysis of a sophisticated cryptocurrency theft campaign targeting the Bittensor ecosystem through typosquatted Python packages on PyPI. The investigation involved automated package monitoring, identification of malicious packages mimicking legitimate Bittensor packages, and detailed technical analysis of the attack vector. The attackers modified legitimate staking functionality to steal funds by inserting malicious code that silently diverts all funds to their wallet. The analysis also traced the cryptocurrency flows through a money laundering network and detailed the typosquatting strategy employed by the attackers.

5/22/2025

Introduced compromised password detection for GitLab.com users, comparing login passwords against a database of known compromised credentials during authentication. This feature alerts users and requires password changes if a match is found, enhancing account security.

3/4/2025

This post announces the launch of GitLab's Open Source Security Center, a new initiative to open-source security tools developed internally. It highlights three specific projects: StORM templates for risk management, the GUARD Framework for automated security detections, and a GitLab CIS Benchmark Scanner. The post emphasizes the importance of community collaboration in security and GitLab's commitment to open source principles.

2/5/2025

This post details the process of running GitLab's security scanners (SAST, DAST, Secret Detection, Container Scanning, Dependency Scanning, API Fuzzing, License Scanning) in air-gapped environments. It outlines the prerequisites (Ultimate subscription, offline cloud license, Self-Managed cluster) and the three-step process: downloading and packaging container images from a public internet environment, transferring these images to the offline environment, and loading them into the offline container registry. The tutorial specifically demonstrates the Secret Detection scanner, showing how to pull the image using Podman, save it as a tarball, and then transfer it via SCP to an air-gapped VM. It also covers verifying that the image is not cached and the steps to load the image into the offline registry.

12/18/2024

This post details how teams can mature their security practices by leveraging advanced access controls (organizational hierarchies, protected branches), robust review processes (multiple approvers, push rules), and compliance adherence tools (Audit Events, Code Quality Reports) within GitLab Premium, building upon the existing security control framework.

11/26/2024

This post introduces the GitLab Universal Automated Detection and Response (GUARD) framework, a collaboration between the Security Incident Response Team (SIRT) and the Signals Engineering Team. GUARD standardizes the detection and alerting pipeline, aims to reduce alert fatigue through consolidation and risk scoring, collects metrics for response efficiency, and uses GitLab as a single source of truth for detection definitions. Key components include Detection as Code (DaC) deployed via GitLab CI/CD, a User Attestation Module, enrichments for alert context, standard alert triage and response, and metrics generation. GitLab projects store detection rules in JSON, MRs are used for changes with approval rules, issues track engineering efforts, labels standardize documentation, and CI/CD automates deployment to the SIEM.

10/29/2024

Introduced an open-source Python CLI tool, `gitlabcis`, to audit GitLab projects against the CIS GitLab Benchmark. The tool provides recommendations as code in YAML format and supports project-level configuration checks. The roadmap includes expanding input to instances and groups, and integrating this functionality into the GitLab product itself via the Compliance Adherence Report.

4/17/2024

This post details the creation and objectives of the CIS GitLab Benchmark, a collaboration between GitLab and CIS. It outlines the benchmark's purpose in hardening GitLab installations with over 125 configuration guidelines, covering areas like access control, authentication, data encryption, secure code development, vulnerability management, and DevSecOps workflow security. It also provides a four-step implementation guide for users.

3/30/2024

This post details GitLab's response to CVE-2024-3094, a critical vulnerability in xz-utils. It confirms that GitLab's core services are unaffected and provides guidance to self-hosted customers on how to check for and mitigate the vulnerability by downgrading or replacing affected versions of xz-utils. It also notes GitHub's action to disable the affected repository.

11/28/2023

This post details the automation of C2 testing for GitLab's Red Team using the Mythic framework and GitLab CI/CD. It introduces a public project containing pytest integration tests for Mythic server and agents, utilizes git submodules for agent source code management, and outlines the configuration of GitLab CI/CD pipelines for automated testing on merge requests and tagged commits. Prerequisites and project structure are explained, along with implementation details for pytest files, the GlMythic class, and agent interaction. The CI/CD configuration includes setting up runners, environment variables (MYTHIC_ADMIN_PASSWORD, AGENT_TYPE), and defining pipeline stages for installation and testing.

11/20/2023

This post details the evolution of GitLab's Red Team from opportunistic, visible operations to stealth-based exercises. It outlines the development of a maturity model, the implementation of Purple Teaming for collaborative testing with the Blue Team, and the subsequent shift to stealth operations. Key technical contributions include the creation of public Red Team issue templates, handbook pages on remote operations and stealth methodologies, and the development of infrastructure for "Attacker VMs" on corporate laptops and dedicated AWS accounts for Command and Control (C2) frameworks. The post also mentions research into C2 frameworks, agents, redirectors, and automation for deploying these environments.

9/13/2023

This post introduces the integration of Sigstore's Cosign for keyless signing and verification within GitLab CI/CD pipelines. It details the challenges of traditional key management and the benefits of keyless signing, such as enhanced security, simplified management, and audit trails. The integration allows users to add a few lines to their `.gitlab-ci.yml` file to leverage Cosign, which requests short-lived key pairs, records signing events on a certificate transparency log (Rektor), and discards the keys. This eliminates the need for manual key setup, rotation, and distribution, significantly improving security and operational efficiency.

8/1/2023

This post details the origins and development of GitLab's security hardening documentation, including field research, attack scenarios, and guidance on when and how to apply hardening measures to self-managed instances. It emphasizes the importance of threat modeling and adapting recommendations to specific environments.

5/24/2023

This post announces the expansion of the Registration Features Program to include five new security-related features: Password complexity requirements, Track description changes in issues, Configurable issue boards, Coverage-guided fuzz testing, and Maintenance Mode. It also lists previously available features like Email from GitLab, Repository size limit, and Restrict access by IP address. The post explains how users can participate by enabling Service Ping.

5/23/2023

This post details specific steps for hardening a self-managed GitLab instance, including enabling multi-factor authentication, enforcing additional sign-up checks, limiting public visibility, hardening SSH settings, reviewing account and limit settings, securing CI secrets with encrypted container technology, and protecting pipelines for all branches. It emphasizes layered security, reducing the attack surface, and avoiding security through obscurity, providing actionable guidance and linking to detailed documentation.

3/8/2023

Introduced customizable roles for GitLab Ultimate customers, starting with an MVC that allows Guest users to view code in private projects. This involved technical discovery and performance testing to ensure a scalable backend implementation for role creation and usage. The custom role is created via API and can be assigned to users, effectively creating a 'Guest+1' role. This addresses a customer pain point regarding Guest user limitations in private projects.

1/4/2023

This post introduces the automatic revocation of Personal Access Tokens (PATs) when GitLab Secret Detection finds them in public repositories. This feature protects public projects that use Secret Detection and have PATs committed to the default branch. Tokens with the `glpat-` prefix are specifically targeted. The user whose PAT is leaked receives an email notification, and the leaked token is reported in the security widget and Vulnerability Report if merged to the default branch. Users are advised to create new PATs if theirs are revoked. The rollout is phased, with GitLab.com enabling it on or after Jan. 23, 2023, and Self-Managed by default in GitLab 15.9. The feature flag can be used for early opt-in or opt-out before it becomes always active.

8/19/2022

This post details the implementation of Arkose Protect into the user login flow to combat credential stuffing attacks, spam, and crypto mining abuse. It describes the risk assessment process involving IP address, user activity, and failed login attempts, and the use of enhanced CAPTCHAs for higher-risk sessions. The post also mentions future plans for a holistic user scoring engine.

8/17/2022

This post explains the alignment between DevOps and zero trust principles, highlighting how zero trust requires authentication, authorization, and continuous validation for all users and machines. It details the three core components of zero trust (data protection, specific identity, secure channel) and discusses the challenges of applying these to automated processes in DevOps. The post also outlines how GitLab's platform supports zero trust by enabling granular role-based access, authentication, continuous validation, monitoring, data classification, and auditing.

12/17/2021

This post details GitLab's security efforts in 2021, focusing on improving assurance through expanded compliance certifications (SOC 2 Type 2/SOC 3, ISO/IEC 27001:2013), continuous control monitoring with the adoption of the Secure Control Framework (SCF) and ZenGRC, and enhanced customer assurance services via the Trust Center and Customer Assurance Package. It also highlights security operations improvements like endpoint detection and response (EDR) platform testing, incident response automation for phishing and access attestation, and Red Team activities including supply chain security research. For product security, it introduces Spamcheck for anti-spam and Package Hunter for detecting malicious dependencies.

11/15/2021

This post details how GitLab's security tools (SAST, DAST, Dependency Scanning, Coverage Fuzzing, Secret Detection, Container Scanning) can help address the OWASP Top 10 2021 risks. It highlights the importance of security-first design, threat modeling, and penetration testing, and provides a coverage legend for how GitLab Secure & Protect, Penetration Testing, Bug Bounties, Security Training, and Security-First Design map to the OWASP categories.

11/4/2021

This post addresses a critical security vulnerability (CVE-2021-22205) in self-managed GitLab instances caused by a third-party file parser (Exif-Tool). It details the affected versions, provides guidance on how to determine if an instance has been impacted, and strongly recommends upgrading to patched versions (13.10.3, 13.9.6, 13.8.8) or applying a hotpatch. It also directs users to forums and support channels for assistance and encourages subscription to security alerts.

8/20/2021

This post introduces the integration of GrammaTech's CodeSonar SAST solution into GitLab Ultimate. It details how CodeSonar analyzes code using a unified data flow and symbolic execution engine to discover defects, and how these findings are presented within the GitLab UI, including vulnerability reports and detailed warning views with annotated source code. Prerequisites for using the integration are also outlined.

7/8/2021

This post details the discovery and reporting of two critical vulnerabilities in Gitpod: 1. Cross-origin WebSocket access, allowing an attacker to potentially steal OAuth tokens by serving malicious JavaScript on an exposed Gitpod workspace port. 2. The ability to log in as any account by leveraging custom integrations with self-managed GitLab instances and spoofing email addresses. Both issues were reported to Gitpod and fixed within hours.

6/9/2021

This post introduces an integration with Jscrambler to provide runtime code protection for JavaScript-based applications. It details the importance of protecting client-side code from tampering and reverse engineering, and provides a step-by-step guide on configuring Jscrambler with GitLab CI. This includes setting up Jscrambler's JSON configuration file, storing API keys as GitLab environment variables, and defining a new 'protect' stage in the `.gitlab-ci.yml` file to run Jscrambler before deployment. The post also demonstrates how to check the protection result by inspecting the obfuscated source code.

12/18/2020

This post details GitLab's partnership with BitSight to improve its third-party security rating. It outlines the challenges of inaccurate ratings due to non-production environments and dynamic infrastructure, and the steps taken to address these. These steps included validating the digital footprint, identifying and removing unused IPs, and creating custom environment tags (Production, Pre-Production, User Managed IPs) to segment findings. The post also describes the implementation of a continuous process for identifying new findings, managing the score, and tracking remediation through regular auditing and monitoring. The goal was to improve GitLab's security posture and build customer confidence.

12/16/2020

This post introduces the integration of Mobile Static Application Security Testing (SAST) for Android applications into GitLab. It explains how SAST works, the role of the Mobile Security Framework (MobSF) and its rules (using regex) for vulnerability detection in Java and Kotlin code. It also highlights the extensibility of GitLab to add custom scanners and encourages contributions to open-source security tools.

12/16/2020

This post details the implementation of a next-generation SIEM (Panther Labs) for improved visibility, detection, and response for GitLab.com and the GitLab organization. It also highlights the creation of a public 'Red Team Tech Notes' project to share technical challenges and solutions, and mentions ongoing work in purple-teaming, table-top exercises, and tooling improvements for the SIRT team. Additionally, it covers the achievement of SOC 2 Type 1 compliance, the establishment of a Security Operational Risk Management program (StORM), and the deployment of the Customer Assurance Package (CAP) for self-serve security information. Finally, it describes the development of functionality to identify accidentally disclosed AWS instance keys and the creation of 'Package Hunter' for enhanced dependency scanning to detect malicious packages.

12/10/2020

This post details the challenges and solutions for integrating continuous fuzzing into CI/CD pipelines. It outlines the need for asynchronous jobs to handle long-running fuzzing tasks, strategies for selecting which versions to fuzz (master + stable branches), and the implementation of regression fuzz tests for merge requests to catch bugs early. It also mentions GitLab's Security Dashboard for reporting vulnerabilities found by fuzzers.

10/22/2020

This post details GitLab's approach to building security features in the open, leveraging open-source projects and community contributions. It highlights the integration of various security scanning tools (SAST, DAST, Container Scanning, Dependency Scanning, License Scanning, Secret Detection, API Fuzzing, Coverage Fuzzing) directly into the DevOps lifecycle to 'shift left'. It also introduces an open integration framework for third-party tools and showcases community contributions in areas like Mobile SAST, Helm Chart support, fuzzing performance, secret detection, dependency scanning, OS updates, and .NET Framework support.

10/12/2020

This post details the integration of Checkmarx's SAST solution with GitLab CI/CD using CxFlow. It explains how CxFlow initiates scans on commits or merge requests, processes results, and provides feedback through GitLab's security dashboard, issues, or merge requests. It also covers automatic issue creation for vulnerabilities, deduplication of similar issues, and customization of defect filtering. The technical implementation involves editing CI/CD pipelines to include a security scan stage and setting up global variables for Checkmarx server access.

10/6/2020

This post analyzes security vulnerability trends across thousands of projects hosted on GitLab.com, identifying trends in CWEs like Improper Input Validation, Out of Bounds Write, and Uncontrolled Resource Consumption. It highlights the increasing prevalence of vulnerabilities in dependent libraries and the persistent use of vulnerable container components. Recommendations are provided for security practitioners, including regular security issue triage, applying security fixes for containers and project dependencies, implementing static and dynamic analysis, secure secret storage, and web application security evaluations. The post also details trends observed in dependency scanning, container scanning, and static analysis, emphasizing the importance of tuning SAST scanners and securely handling secrets.

10/1/2020

This post details the configuration steps and supported security scanners (Container Scanning, SAST, DAST, License Compliance, Dependency Scanning) for running GitLab security scans in offline or limited connectivity environments. It highlights the need to use local network resources for updates and provides a video tutorial.

9/14/2020

This post details the application security engineer's role in collaborating with Growth and Enablement teams, assessing risk, reviewing code, and driving security-conscious outcomes. It highlights the initiative to enable GitLab's secure tooling (Container Scanning, SAST, DAST, License Compliance, Dependency Scanning) in major product repositories by configuring CI/CD pipelines. The post also emphasizes the importance of writing unit tests for unexpected cases to improve application security and prevent vulnerabilities.

8/19/2020

This post announces upcoming breaking changes in GitLab 13.4 for secure analyzers. Key changes include the removal of the Secret Detection job from the SAST CI template, the deprecation and removal of Docker-in-Docker (DinD) for security scanners, the transition of the Bandit Python Analyzer to Alpine Linux, and the deprecation and removal of the TSLint job in favor of ESLint. It provides guidance on how users can update their configurations to maintain scanning capabilities.

8/18/2020

This post details how GitLab Secure and Protect can be used to secure cloud-native applications. It introduces Container Host Security (powered by Falco), Container Network Security (powered by Cilium), Web Application Firewall (powered by ModSecurity and OWASP CRS), and Static Application Security Testing (SAST) using the Golang Security Checker. The post uses a real-world example of a command injection attack on a Golang application running in Kubernetes to demonstrate how these features detect, permit, and help fix vulnerabilities.

8/13/2020

This post discusses the challenges developers face in adopting security testing tools like SAST and DAST due to high setup barriers and noisy results. It highlights GitLab's approach of integrating security findings into merge requests, allowing developers to validate and address issues early. The security team's role in tuning tools, assessing trends, and providing context is also emphasized. The conversation underscores the need for a shared culture of security and collaboration between development and security teams to effectively find and fix bugs earlier in the development lifecycle.

8/11/2020

This post details the challenges and considerations when using WebGoat as a benchmarking target for SAST and DAST tools, highlighting that WebGoat's synthetic flaws and simplified architecture may not fully exercise the capabilities of advanced security analysis tools. It emphasizes the importance of using real-world applications and considering factors like tool applicability, consistency, and actionability of results when benchmarking.

8/4/2020

This post details an internship experience where the author integrated GitLab's SAST scanner into an open-source project. The contribution involved setting up a testing environment, running scans, analyzing results (including identifying a false negative), and submitting a merge request to implement the scans. The post also highlights the value of the internship in building knowledge of GitLab's security offerings and providing feedback for product improvement.

7/28/2020

This post details how GitLab's security features, including Secret Detection, Dependency Scanning, Dynamic Application Security Testing (DAST), and Web Application Firewall (WAF), can be used to prevent and detect attacks against containerized applications. It also introduces Container Host Security features for detecting and preventing execution and lateral movement within Kubernetes clusters, leveraging system call logging, Network Policies, and Pod Security Policies.

7/20/2020

This post outlines five steps to standardize security in DevOps: Educate, Coordinate, Authenticate, Integrate, and Automate. It emphasizes embedding security tools within the development pipeline (SAST, DAST, IAST, fuzzing, license compliance, container scanning, dependency scanning) and automating security practices for consistency, traceability, and repeatability. It also highlights the need for continuous re-evaluation of security standards.

7/8/2020

This post details how to automate security testing in software development, specifically focusing on SAST and DAST scans. It outlines four ways to integrate automated security testing: running SAST scans for every code change, automatically initiating work tickets or stopping builds based on scan results, applying policies automatically upon code commit, and analyzing running web applications with DAST scans. It also discusses the benefits of automated security, the difference between automation and orchestration, and common types of security automation tools.

7/7/2020

This post details how GitLab's application security dashboard helps AppSec engineers by outlining four key capabilities: finding vulnerabilities with security scans (SAST, DAST, Container Scanning, Dependency Scanning, License Scanning), managing vulnerabilities with the Security Dashboard (group and project level views, integration with third-party scanners), auditing vulnerabilities (tracking dismissed issues, reasons, and creating confidential issues/branches), and managing software licenses (setting policies and blocking MRs with unacceptable licenses). It highlights the integration of security scans into CI/CD pipelines and merge requests.

6/24/2020

This post details GitLab's pursuit of and attainment of SOC 2 Type 2 attestation, the CSA CAIQ, and the internal GitLab Control Framework (GCF) to demonstrate its security posture and maturity to customers. It also outlines PCI compliance efforts and future security and compliance priorities.

5/18/2020

This post details the application security team's focus on automated testing for permission bugs, identifying information leaks in APIs, and developing expertise in specific product stages (Verify and Release) to provide more insightful security reviews. It also highlights the importance of the principle of least privilege and the benefits of transparency in improving software security.

4/2/2020

This post details the top 6 security trends observed in GitLab-hosted projects between September 2019 and February 2020. It identifies 'Components with known vulnerabilities' as the most prevalent, followed by XSS, lack of secret management, CSP, CSRF, and SQL injection. The post also highlights a significant increase in the use of GitLab's security scanning tools (SAST, DAST, dependency scanning, container scanning, secret detection) and a substantial rise in CSP vulnerabilities. It provides best practices for mitigating each vulnerability type and notes trends in their prevalence.

3/4/2020

Introduced continuous accessibility testing in GitLab 12.8, integrating an accessibility scanning template into CI/CD pipelines. This allows for automated scanning of Review Apps using WCAG 2.0 standards, generating an HTML report. Future plans include scanning only changed pages, displaying issues in MRs, and full report display within GitLab.

2/19/2020

This post discusses challenges in data classification within a Zero Trust framework, specifically the 'fluidity of data' where classification changes rapidly after initial authentication. It introduces the concept of 'data zones' as a temporary solution and highlights the ongoing search for a more granular access control mechanism. It also details the vendor selection process for an Identity Management System (IMS), focusing on Okta's flexibility in supporting multi-factor authentication (MFA) with choices like U2F (Yubikeys) and push technology via the Okta Verify app. The post emphasizes the importance of user identity and authentication as a cornerstone, but also points to the need for end-user device identity, process identity, and comprehensive auditing and logging capabilities within a Zero Trust implementation.

2/12/2020

This post details the research and tooling developed by GitLab's Red Team to simulate malicious activity in Google Cloud Platform (GCP). It outlines manual post-exploitation tactics for privilege escalation, lateral movement, and data exfiltration starting from a compromised Linux VM. It also introduces several new utilities: gcp_firewall_enum, gcp_enum, and gcp_misc, for attacking GCP environments. The post covers GCP security concepts like resource hierarchy, service accounts, access scopes, and IAM permissions from an attacker's perspective.

1/14/2020

This post details the integration of WhiteSource with GitLab Ultimate to secure open-source code. It highlights how developers can find and fix open-source vulnerabilities within the GitLab UI and CI/CD pipeline. The integration provides insights into vulnerable open-source components and dependencies directly in merge requests and the GitLab Security Dashboard, alongside other scan results. It emphasizes the partnership's goal to enable developers to use open-source components without compromising security, speed, or agility.

11/7/2019

This post introduces Shawn Sichak, a Security Engineer on the Security Operations team, who discusses the challenges of balancing security with user experience. He highlights initiatives focused on developing tooling and automation for deeper visibility and proactive security response, leveraging aggregated data for automated response pipelines. He also emphasizes the importance of unique passwords, 2FA, and the emerging trend of integrating security into broader software development practices.

10/15/2019

This post details the implementation of Zero Trust at GitLab, focusing on the integration of Okta for SaaS application access control (using SAML and MFA), the planned rollout of Okta Advanced Server Access for SSH, the use of Camo proxy to encrypt communications, and the adoption of Tenable and Uptycs for infrastructure security monitoring and visibility. It also touches upon the challenges of logging and budgeting for Zero Trust initiatives.

9/6/2019

This post introduces the concepts of 'data zones' and 'authentication scoring' as part of GitLab's Zero Trust initiative. Data zones are defined based on data classification (RED, ORANGE, YELLOW, GREEN) to group data with similar access control needs, especially when granular control is not possible on the underlying system. Four zones (RED, ORANGE, YELLOW, GREEN) are defined, with rules that a zone can only contain its own or lower classification data and requires authorization for the highest designation within its boundaries. An authentication scoring system is detailed, assigning points for basic authentication (1 point for GREEN ZONE), U2F (2 points for YELLOW ZONE), managed devices (3 points for ORANGE ZONE), healthy managed devices (4 points for RED ZONE), and geolocation (potential additional point for specific RED data). The goal is to achieve more granular, documented, logged, and automated access control.

8/21/2019

This post details the challenges associated with implementing Zero Trust at GitLab, specifically focusing on data classification and infrastructure. It outlines the four data classification levels (RED, ORANGE, YELLOW, GREEN) and discusses the complexities of data state changes, tracking metadata, time limits, data capability, and data movement. It also highlights infrastructure challenges related to multi-cloud environments (GCP, AWS, Azure, DigitalOcean) and the ambiguity of administrative access in SaaS applications. The post emphasizes that GitLab's all-remote nature and lack of a corporate VPN provide a head start in adopting Zero Trust.

8/9/2019

This post details the problems, goals, and expected challenges in implementing Zero Trust at GitLab. It defines the problem as the difficulty in implementing Zero Trust due to differing interpretations and the need for all components to work together. The goals outlined are to protect data based on classification, ensure positive identification of team members and devices in real-time, incorporate geo-location, subject automated processes to the same policies, log all transactions, not weaken existing controls, and make security easier. Expected challenge areas include the company's network (no perimeter, remote team members), applications and data (public cloud offerings, third-party services), customer data protection, scaling, and global team member/customer regulations.

7/10/2019

This post details the implementation of the GitLab Control Framework (GCF) by adapting the Adobe CCF. Key technical steps include converting CCF controls from PDF to CSV, making control statements specific to GitLab's compliance needs while preserving foundational mappings to regulatory requirements (e.g., PCI DSS), prefixing control domains for numbering (e.g., AM.1.01), prioritizing controls mapped to SOC2 (resulting in 63 controls), and building out additional content for each control including context, scope, ownership, implementation guidance, reference links, evidence examples, and framework mapping. The post also outlines the final steps of identifying responsible teams (RACI) and performing gap analyses for each control. Future plans include developing scripts to convert controls into GitLab issues and a CSV-to-JSON tool.

6/26/2019

This post details Alexander Dietrich's role in building automation tools for the security department, focusing on automating tasks to improve speed, consistency, and delight. Key initiatives include building an escalation engine for security issues, automating HackerOne report imports into GitLab issues, and laying the groundwork for GitLab's Zero Trust initiative by enhancing the SSO solution.

6/14/2019

This post introduces Roger Ostrander, a Senior Security Engineer in Abuse Operations, and details his work in developing automated tools to detect and prevent various forms of abuse on GitLab, including snippet spam and malware distribution through group names. It highlights the ongoing 'arms race' nature of abuse prevention and the challenges of maintaining transparency while protecting anti-abuse tactics. The post also mentions an API change that aids in dealing with snippet spam.

6/10/2019

This post discusses the evolving landscape of security compliance frameworks in light of rapid technological advancements such as cloud computing, serverless, containerization, and zero trust architectures. It highlights that traditional frameworks often lag behind current technology. GitLab is actively contributing to this evolution by developing its own compliance controls framework and open-sourcing it to provide a practical, real-world reference for other organizations. The post also touches upon the shift in how and where work is done, particularly with the adoption of all-remote policies, and how this impacts physical security controls.

4/10/2019

This post details a security vulnerability where Group Runner Registration Tokens were exposed. A patch was deployed to GitLab.com, and tokens were reset. Critical security releases were issued for GitLab Enterprise Edition to address this vulnerability. No evidence of unauthorized project access was found. Self-managed customers were advised to upgrade.

4/1/2019

This post introduces the historical context and conceptual evolution of Zero Trust networking. It details three major shifts: the 'death of the perimeter' due to increased internal network access and the limitations of firewalls, the advent of 'the cloud' which further distributed network boundaries and introduced new security challenges, and the rise of 'mobility' driven by remote work and personal devices, necessitating stronger authentication methods like 2FA. The post frames Zero Trust not as a new concept but as a response to these evolving security landscapes, highlighting Operation Aurora and Google's BeyondCorp as key moments in its practical implementation.

10/8/2018

This post details a new, more secure process for verifying user identity when users lose access to their 2FA-enabled GitLab.com accounts. The previous method relied on government-issued IDs, which had drawbacks related to real names and independent verification. The new process involves classifying the risk factor of the data the user would access if 2FA were reset, and then posing a series of authentication challenges that require knowledge of the user's account. A minimum score must be attained based on the account's risk classification to reset 2FA. This process is peer-reviewed and the challenges are not made public.