TechPrufer
Get started
GitLab
GitLab logoGitLab · Feature trail

Security Control Framework

73 posts · Oct 2018 – Oct 2026

What this trail covers

GitLab's DevSecOps platform offers multiple container scanning approaches to detect vulnerabilities throughout the application lifecycle. Pipeline-based scanning uses Trivy to analyze images during CI/CD, with options for preconfigured merge requests or manual configuration. Container Scanning for Registry automatically scans 'latest' tagged images pushed to the registry. Multi-Container Scanning enables parallel scanning of multiple images within a single pipeline. Continuous Vulnerability Scan. The organization security dashboard provides a consolidated view of risk across all top-level groups and scanners, calculating a risk score based on vulnerability severity, age, KEV, and EPSS. It includes charts for vulnerabilities over time, by age, severity, and CWE, and supports third-party SARIF reports. The feature is in beta for GitLab.com Ultimate users and requires Organizations (Beta) to be enabled, Owner role access, active Advanced Search and Vulnerability Management, and completed security scans.

All GitLab trails
  1. Track organization-wide security risk in one dashboardIntroduces an organization-level security dashboard that consolidates vulnerability data from all top-level groups and scanners, providing a unified risk score and detailed risk analysis charts. This feature aims to reduce manual reporting efforts and provide a current, defensible view of organizational security posture. It supports third-party SARIF reports and is available in beta for GitLab.com Ultimate users.
  2. Dependency Firewall: Block risky packages before the buildIntroduces GitLab Dependency Firewall, a new capability that blocks packages based on defined policies (malicious status, vulnerability severity, license type, package age) before they are installed in a build. It offers warn/block modes, hierarchical policy inheritance, and pre-pull checks via CLI. The feature aims to prevent malicious, vulnerable, or non-compliant packages from entering the software supply chain, reducing risk and manual remediation efforts.
  3. Two front doors: Module-level access in a Django GRC appIntroduces a pattern for module-level access control in Django applications using group membership enforcement. This involves creating a reusable `GroupRequiredMixin` in a core app that modules inherit from, and a `user_in_group` template filter for UI guards. The core app has zero knowledge of module-specific data, ensuring clean separation. This pattern is applied to a GRC tool serving Security Compliance and Internal Audit teams.
  4. How GitLab tracks vulnerabilities through refactors and reformattingIntroduced a 'normalized scope+offset' vulnerability fingerprinting method that ignores non-functional code (comments, blank lines) when calculating the fingerprint. This method was evaluated on a benchmark of 439 files and 2,247 commits, resulting in zero duplicate fingerprints and a 43% reduction in unique fingerprints compared to the previous method. The normalized method is implemented as the `scope_offset_compressed` tracking algorithm in GitLab SAST, supporting multiple languages and reusing existing parse trees without affecting scan times.
  5. Shai-Hulud copycat campaign targets Python developers through PyPI typosquattingThis post details the discovery and technical analysis of a coordinated supply chain attack on PyPI targeting Python developers. The attack uses typosquatting and weaponizes a legitimate package (`mflux-streamlit`) to distribute a Shai-Hulud malware variant. Key technical details include the use of Python `.pth` files for execution, a multi-layered obfuscated JavaScript payload (ROT-N cipher, AES-128-GCM encryption), and the harvesting of credentials from GitHub Actions, AWS, Azure, GCP, HashiCorp Vault, npm/JFrog, PyPI, RubyGems, SSH, Kubernetes, Sigstore, and various databases. The worm self-propagates by committing malicious code to GitHub repositories, publishing poisoned packages to registries, and attempting privilege escalation on CI runners. Indicators of compromise and remediation steps are provided. GitLab's Dependency Scanning and Advisory Database are highlighted as tools to detect these packages.
  7. 5 ways to fix misleading vulnerability severities with policyThis post introduces vulnerability management policies that allow for automated severity overrides based on defined rules. It details how to configure these policies to downgrade low-risk CVEs in internal services, upgrade injection vulnerabilities in production code, normalize severity across scanners, align severity with exploitation intelligence (e.g., CISA KEV catalog), and apply org-wide risk models at the group level. It provides concrete YAML configurations for these use cases and explains the criteria types, override operations, severity levels, and limits for policy creation. The post also clarifies the difference between auto-dismiss and severity override and confirms that manual overrides take precedence.
  8. A leaked personal access token shouldn't expose every project its owner can reach. Fine-grained PATs scope each token’s permissions to the job.Introduces fine-grained personal access tokens (PATs) as a beta feature. PATs can now be scoped by 'where it can reach' (personal projects, all projects/groups, or selected projects/groups) and 'what it can do there' (per-resource permissions like Create, Read, Update, Delete for Issues, Merge Requests, Repositories, Container Registry, etc.). This aims to reduce the blast radius of leaked tokens by issuing one PAT per job with only necessary privileges. The tokens table is updated for audibility, showing exact scopes and permissions. Future roadmap includes expanding REST API and GraphQL coverage. Advises against production use until general availability.
  9. Manage vulnerability noise at scale with auto-dismiss policiesThis post introduces auto-dismiss vulnerability policies, a new capability within GitLab's security control framework. It details how these policies can be configured using YAML to automatically dismiss vulnerabilities based on criteria such as file path, directory, or identifier (CVE, CWE). The post provides specific use cases and ready-to-use configurations for dismissing vulnerabilities in test code, vendored code, known false positives, generated code, infrastructure-mitigated vulnerabilities, and CVE families. It also outlines the process for creating and enabling these policies, the limits on criteria and rules, and the affected vulnerability statuses.
  10. A complete guide to GitLab Container ScanningThis post details the five types of container scanning offered by GitLab: pipeline-based scanning (using Trivy), container scanning for the registry, multi-container scanning (beta), and continuous vulnerability scanning. It explains what each does, its best use cases, tier availability, and how to enable them. It also covers common configurations for pipeline-based scanning, viewing vulnerabilities in merge requests and the vulnerability report, and viewing the dependency list (SBOM).
  11. How GitLab built a security control framework from scratchThis post details the creation of a custom security control framework (GCF) at GitLab to address the limitations of existing industry frameworks (like NIST SP 800-53) for their multi-product, cloud-native environment. It outlines a five-step process: analyzing needs, learning from industry frameworks, creating custom control domains (18 in total, e.g., IAM, SDL, SRM), adding context and data through a control hierarchy (Level 1 framework, Level 2 product-specific implementation), and iterating for new certifications and regulations. The GCF's superpower is its extensive metadata tracking (owner, environment, assets, frequency, nature, classification, testing details), transforming it into an operationalized control inventory.
  12. Strengthening GitLab.com security: Mandatory MFAGitLab is implementing mandatory multi-factor authentication (MFA) for all users and API endpoints on GitLab.com that authenticate using a username and password. This is a phased rollout over the coming months, with users being notified via email and in-product reminders. Users are encouraged to proactively set up MFA methods like passkeys, authenticator apps, WebAuthn devices, or email verification. For API authentication, users are recommended to switch to personal access tokens (PATs). The change aims to defend against credential stuffing and account takeover attacks.
  13. OWASP Top 10 2025: What's changed and why it mattersThis post details the OWASP Top 10 2025 list, highlighting two new categories: A03: Software Supply Chain Failures and A10: Mishandling of Exceptional Conditions. It explains how GitLab Ultimate's security scanning features (SAST, IaC scanning, Secret Detection, Dependency Scanning, DAST, API Security Testing, Web API Fuzz Testing) address these and other OWASP categories. It also mentions the integration of AI agents like the Security Analyst Agent for vulnerability triage.
  14. GitLab discovers widespread npm supply chain attackThis post details the discovery and technical analysis of a widespread npm supply chain attack. It describes the malware's multi-stage loading process via `setup_bun.js`, credential harvesting techniques (GitHub, npm, AWS, GCP, Azure), data exfiltration network using attacker-controlled GitHub repositories, and supply chain propagation by injecting malicious code into other packages. Crucially, it details the 'dead man's switch' mechanism that triggers data destruction if access to exfiltration and propagation channels is lost. Indicators of compromise and how GitLab's Dependency Scanning can help detect this campaign are also provided.
  15. Fine-grained permissions for job tokens is now GAThis post announces the General Availability (GA) of fine-grained permissions for CI/CD job tokens. Previously, job tokens inherited overprivileged permissions from user accounts, posing security risks. This new feature allows maintainers to explicitly grant granular permissions to job tokens for specific API resources, including Repositories, Deployments, Environments, Jobs, Packages, Pipelines, Releases, Secure Files, and Terraform State. This adheres to the principle of least privilege, reduces the attack surface, and lays the groundwork for true machine-based identity.
  16. Custom admin roles are now GAIntroduces custom admin roles for GitLab Self-Managed and GitLab Dedicated instances, allowing for granular permissions to control access to the Admin area. This feature enables the creation of purpose-built administrative roles (e.g., Platform Team, Support Team, Leadership Team) instead of granting full administrator access. Key features include granular permissions, instance-level management, LDAP integration for role mapping, and integration with existing Admin mode and audit events. This is positioned as a critical step in improving software supply chain security, building upon existing custom roles for groups and projects and granular permissions for CI/CD job tokens.
  17. GitLab uncovers Bittensor theft campaign via PyPIThis post details the discovery and analysis of a cryptocurrency theft campaign that leveraged typosquatted Python packages on PyPI. The campaign targeted the Bittensor ecosystem by hijacking the `stake_extrinsic` function within malicious packages to silently divert all funds to an attacker-controlled wallet. The post outlines the attack vector, the rationale behind targeting staking functionality, the money laundering network used, and the typosquatting strategy employed. It also highlights GitLab's automated detection system and its role in identifying and reporting these malicious packages to PyPI. Indicators of compromise and a timeline of events are provided.
  18. Automating role-based access control (RBAC) at scaleThis post details a hands-on implementation example of GitLab + Keycloak + OIDC for automating role-based access control (RBAC) at scale. It covers setting up the environment in Docker, generating SSL certificates for secure communication between GitLab and Keycloak, configuring GitLab's OIDC integration with Keycloak, and demonstrating how realm roles and group memberships in Keycloak can be mapped to GitLab roles and group hierarchies. The post emphasizes the benefits of automated user provisioning, least-privilege policies, and a scalable access model for enterprise-grade software development.
  19. Last year we signed the Secure by Design pledge - here's our progressThis post details GitLab's progress on the CISA Secure by Design Pledge over the past year. Key updates include: a phased rollout of MFA by Default, reducing default passwords by using randomly generated ones and deleting password files post-restart for some install methods, improving SAST rule coverage to address broader vulnerability classes, detailing the maintenance policy and upgrade guidance for security patches, maintaining a bug bounty program and security.txt, publishing CVEs with CWE and CPE fields, and open-sourcing GUARD and TLDR threat detection frameworks. It also mentions the introduction of compromised password detection for GitLab.com native authentication.
  20. Introducing compromised password detection for GitLab.comIntroduces compromised password detection for GitLab.com users during sign-in. This feature compares the entered password against a database of known compromised credentials. If a match is found, users receive an alert banner and email notification, prompting them to change their password. This applies only to native username/password logins, not SSO. The post also reiterates existing security recommendations: using strong, unique passwords, setting up two-factor authentication, maintaining access to primary email and recovery codes, and registering with services like haveibeenpwned.com.
  21. How GitLab measures Red Team impact: The adoption rate metricThis post details the implementation of a Red Team impact metric focused on 'adoption rate'. It describes using GitLab issues with specific labels (e.g., 'RTRec::Detection', 'RecOutcome::Adopted') to track recommendations from creation to implementation. It highlights the use of GitLab Query Language (GLQL) to create dynamic dashboards for monitoring recommendation status and trends. Lessons learned include the importance of starting with metrics early and avoiding operational silos, advocating for collaboration across security teams. The post also outlines the next steps for measuring 'threat resilience'.
  22. Introducing GitLab’s Open Source Security CenterThis 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.
  23. The ultimate guide to token management at GitLabThis post details the evolution of GitLab's token management capabilities, introducing a credentials inventory for administrators to monitor and manage tokens. It covers token types, discovery methods (UI, API, audit events), management through UI and API, and best practices for rotation and expiration. New features include retaining records of inactive tokens for 30 days post-expiration and the introduction of a credentials inventory API endpoint. The post also highlights the importance of token rotation and provides guidance on API-based rotation.
  24. How to scan a full commit history to detect sensitive secretsThis post introduces the capability to perform historical scans with GitLab Secret Detection by setting the `SECRET_DETECTION_HISTORIC_SCAN` variable to `true`. This allows the scanner to inspect all branches and commits within a repository, including deleted files and secrets that were present in past commits but have since been removed from the default branch. The results are displayed directly in the GitLab UI, with options to triage vulnerabilities by creating issues or Jira tickets. The post also reiterates the existence of other secret detection features like push protection, pipeline scanning, client-side scanning, and automatic response to leaked secrets.
  25. Tutorial: Security scanning in air-gapped environmentsThis post details the process of running GitLab security scanners (SAST, DAST, Secret Detection, Container Scanning, Dependency Scanning, API Fuzzing, License Scanning) in air-gapped environments. It explains how to download, package, transfer, and load container images for these scanners into an offline GitLab instance's container registry. It also outlines the prerequisites for offline scanning, including an Ultimate subscription and offline cloud license, and demonstrates the process using Secret Detection.
  26. Streamline the path to CMMC Level 2 compliance with GitLabThis post details how GitLab's features, including RBAC, custom roles, audit events, session duration limits, IP address restrictions, AWS PrivateLink, SAML SSO, SCIM, and MFA, can be leveraged to meet CMMC Level 2 compliance requirements. It maps specific CMMC/NIST controls to GitLab functionalities like SAST, IaC scanning, DAST, container scanning, dependency scanning, and vulnerability reporting. It also highlights the integration of GitLab Duo with Amazon Q for security scanning within merge requests.
  27. 3 signs your team is ready to uplevel security controls in GitLabThis post details how teams can mature their security practices by leveraging advanced access controls, robust review processes, and compliance adherence features. It highlights the use of organizational hierarchies for advanced permissions management, Protected Branches, and restricted push/merge access. It also discusses features like Multiple Approvers and push rules to enhance the review process, and Audit Events and Code Quality Reports to strengthen compliance adherence.
  28. Unveiling the GUARD framework to automate security detections at GitLabIntroduces the GUARD framework (GitLab Universal Automated Detection and Response) for automating security detections, maintenance, alert routing, metrics collection, and incident escalation. Highlights GUARD's design principles: standardization, reduction of alert fatigue, metrics generation, and GitLab-centricity. Details GUARD components: Detection as Code (DaC), User Attestation Module (UAM), Enrichments, Alert Triage and Response, and Metrics Generation. Explains how GitLab features (projects, MRs, issues, labels, CI/CD) are used within GUARD. Discusses metrics generation for Time to Respond, Time to Resolve, and alert fidelity.
  29. Best practices to keep secrets out of GitLab repositoriesThis post details best practices for preventing secrets from being leaked into GitLab repositories, including limiting public visibility of groups and projects, securing CI secrets using secret managers (GCP Secret Manager, AWS KMS, HashiCorp Vault), and leveraging GitLab's built-in secret detection methods: secret push protection, pipeline secret detection, and client-side secret detection. It also provides guidance on what to do if credentials are accidentally leaked, such as resetting credentials and reviewing access logs.
  30. New CIS GitLab Benchmark scanner boosts security and complianceThis post introduces the open-source `gitlabcis` scanner, a Python CLI tool that audits GitLab projects against the CIS GitLab Benchmark. It details the installation process via pip, command-line usage for generating JSON reports, and the internal structure of the scanner including YAML recommendations and dedicated control functions. It highlights limitations of the current project-level scanning and outlines future roadmap items for instance/group-level scanning and integration into the GitLab product's Compliance Adherence Report. It also mentions two features contributed back to the product: 'Show crosslinked/related issues in merge requests via the API' and 'Groups API: Add Restrict group access by Domain'.
  31. Tutorial: Integrate GitLab Merge Request approvals with external systemsThis post details the implementation of GitLab's External Status Check feature to integrate merge request approvals with external systems. It provides a tutorial on deploying a sample application that receives status check requests from GitLab, stores them in a database, and allows external users to approve/reject them via a web interface. The application communicates back to GitLab using a Personal Access Token. The post also outlines how to configure these status checks within GitLab projects and provides debugging tips for the deployed application.
  32. How GitLab supports the FedRAMP authorization journeyThis post details how GitLab's self-managed offerings can support organizations pursuing FedRAMP authorization. It outlines key FedRAMP requirements (Low, Moderate, High impact levels, NIST 800-53 controls) and the certification process (preparation, authorization package submission, post-authorization monitoring). It then maps specific GitLab features to these requirements, including CI/CD for security testing and policy enforcement, access control and authentication (identity providers, native configurations), audit event logging, incident response tools, configuration management via MRs, FIPS compliance support, and a NIST 800-53 R5 project template for control management. The post emphasizes the importance of integrating FedRAMP-authorized identity providers and leveraging GitLab's security hardening documentation.
  33. FAQ: The RegreSSHion vulnerability and GitLabThis post details the RegreSSHion vulnerability (CVE-2024-6387), a remote unauthenticated code execution flaw in OpenSSH server. It clarifies that GitLab.com and GitLab Dedicated are not impacted due to the use of gitlab-sshd. Self-managed customers are advised to patch their environments or use gitlab-sshd. Mitigation strategies include regular patching, strong passwords, MFA, and hardening recommendations. The post emphasizes that the exploit's success rate in real-world scenarios is extremely remote.
  34. Prevent secret leaks in source code with GitLab Secret Push ProtectionIntroduces Secret Push Protection, a new feature that blocks high-confidence secrets from being pushed to GitLab repositories. This feature operates by checking the content of each commit before it's pushed, providing a "shift-left" approach to secret management. It supports exclusions for specific paths and rules, and logs audit events for various actions related to its configuration and usage. The post emphasizes its use as a layered approach alongside Pipeline Secret Detection.
  35. Secure by Design principles meet DevSecOps innovation in GitLab 17GitLab 17 strengthens its commitment to Secure by Design principles by enhancing secure coding practices with improved SAST analyzer coverage, API Security Testing updates, advanced vulnerability tracking for Secret Detection, and Dependency Scanning support for Android. It also improves vulnerability management at scale with enhanced Vulnerability Report filtering and provides AI-accelerated assistance for memory-safe language conversions and securing AI-generated code through GitLab Duo. Furthermore, it aligns with the principle of least privilege through enhanced governance controls via permissions customizations for custom roles.
  36. Migration guide: GitHub Advanced Security to GitLab UltimateThis post details the migration of GitHub Advanced Security features (SAST, secret scanning, dependency scanning) to GitLab Ultimate. It provides a feature-by-feature comparison, migration steps for repositories, and configuration examples for enabling SAST and Secret Detection in GitLab CI/CD pipelines. It also discusses customizing SAST scanners and rulesets, and highlights GitLab's native security features like DAST, container scanning, and granular security guardrails.
  37. GitLab introduces new CIS Benchmark for improved securityThis post announces the creation and publication of the CIS GitLab Benchmark, a collaboration between GitLab and CIS. It details the objectives of the benchmark, which include addressing access control, authentication, data encryption, secure code development, vulnerability management, and secure configuration for DevSecOps workflows. The post outlines the steps for implementing the benchmark, which involves assessing current configurations against the guidelines and planning for gap remediation.
  38. Important information regarding xz-utils (CVE-2024-3094)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.
  39. How to tailor GitLab access with custom rolesThis post details the evolution of GitLab's customizable roles feature. It introduces the concept of a consistent CRUD model for permissions (Manage, Write, View, Delete) and provides examples for registry permissions. It also outlines the plan to remove default role dependency, allowing users to build roles from scratch, and discusses grouping resources into themes for role creation. The post also includes a survey for user feedback on permission groupings and a feedback issue for submitting ideas.
  40. How GitLab's Red Team automates C2 testingThis 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.
  41. Stealth operations: The evolution of GitLab's Red TeamThis 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.
  42. Why GitLab access tokens now have lifetime limitsThis post details the decision to remove support for non-expiring access tokens, enforcing a maximum 365-day expiration for new tokens and applying a one-year expiration to existing non-expiring tokens. It outlines the impact on automation, the rationale behind the change (security best practices), and provides guidance on auditing tokens, using the token rotation API with reuse detection, manually setting expiration dates, and leveraging service accounts for automation. Email notifications for expiring tokens have also been implemented.
  43. Streamline security with keyless signing and verification in GitLabThis post introduces the integration of Sigstore's Cosign for keyless signing and verification within GitLab CI/CD. It details the challenges of traditional key management and the benefits of keyless signing, such as enhanced security, simplified management, and audit trails. The technical implementation involves adding a few lines to the `.gitlab-ci.yml` file to leverage OIDC tokens for ephemeral key generation and signing artifacts, with verification data recorded on the Rektor log.
  44. The backstory on GitLab's security hardening documentationThis 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.
  45. Security features now free with expanded Registration ProgramThis 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.
  46. How to harden your self-managed GitLab instanceThis post provides a practical guide for hardening self-managed GitLab instances, focusing on seven key areas: enabling multi-factor authentication, enforcing additional sign-up checks (email confirmation, password complexity, allowed domains), limiting public visibility of groups and projects, hardening SSH settings (protocols, key types), reviewing account and limit settings (attachments, pushes, session duration, token lifetime), securing CI secrets with encrypted containers (recommending HashiCorp Vault and TLS 1.2+), and protecting pipelines for all branches (including protected environments). It emphasizes layered security and reducing the attack surface, aligning with GitLab's transparency and open-source principles.
  47. The feature you wanted - Expanded Guest capabilities in GitLab UltimateIntroduced 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.
  48. Secret Detection update: Leaked Personal Access Tokens will soon be revokedThis post introduces the automatic revocation of leaked Personal Access Tokens (PATs) found in public repositories by GitLab Secret Detection. It details the conditions under which revocation occurs (public projects, default branch, `glpat-` prefix), the user notification process, and the impact on security reporting. It also outlines the rollout plan for GitLab.com and Self-Managed instances and provides guidance on how users can get protected by enabling Secret Detection and enforcing scan execution. The post also mentions future enhancements to Secret Detection.
  49. Why 2022 was a record-breaking year in bug bounty awardsThis post details the significant increase in bug bounty awards in 2022, exceeding $1 million USD across 221 valid reports. It highlights top researchers, notable reports (including RCE and local git vulnerabilities), and changes made to the bug bounty program in 2022, such as adopting the Gold Standard Safe Harbor statement, introducing a capture the flag bonus, and creating a dedicated space for AppSec team communication. It also references existing security initiatives like Secret Detection and the broader security control framework.
  50. How we boosted WebAuthn adoption from 20 percent to 93 percent in two daysThis post details the successful mandate of WebAuthn/FIDO2 devices for all team members, achieving 93% adoption in two days, significantly enhancing phishing resistance by replacing less secure MFA methods like Okta Verify push notifications and TOTP codes. The implementation leveraged built-in device capabilities (Touch ID on Macs), facilitated YubiKey distribution for Linux users and others, and crucially, enabled self-service enrollment of new devices via QR code scanning, minimizing IT support load.
  51. How GitLab is fighting credential stuffing and platform abuseThis post details the implementation of Arkose Protect into the user login flow to combat credential stuffing attacks. It describes the risk assessment process using IP address, user activity, and failed login attempts, and the use of an enhanced CAPTCHA for higher-risk sessions. The post also mentions future plans for a holistic user scoring engine.
  52. Why DevOps and zero trust go togetherThis post discusses how zero trust principles align with modern DevOps practices and how GitLab's platform supports these principles. It highlights the importance of authenticating and authorizing both human and machine identities, continuous validation, and secure channels for data access. It specifically mentions the need to account for automated requestors in DevOps and suggests solutions like mutual TLS and OpenID Connect. The post also details how GitLab's platform can enforce granular access, authenticate users and machines, monitor security status, classify data, and audit access in real-time, contributing to a zero trust framework.
  53. Top 5 compliance features to leverage in GitLabThis post details the implementation and compliance relevance of several security features within GitLab, including Multi-Factor Authentication (MFA), privileged access review, protected branches, merge request approval settings, and audit events. It provides specific technical configurations and links to documentation for each feature, and maps them to relevant compliance standards and GitLab controls. The post emphasizes the importance of proactive security design and adherence to the principle of least privilege.
  54. GitLab Security in 2021: protect, enhance, certify and strengthenThis post details GitLab's security efforts in 2021, highlighting improvements in enterprise SaaS security, supply chain security, and APT threat protection. It covers the expansion of security certifications (SOC 2 Type 2/SOC 3, ISO/IEC 27001:2013), the adoption of the Secure Control Framework (SCF) and ZenGRC for continuous control monitoring, and the deployment of GitLab's Trust Center and Customer Assurance Package. It also discusses security automation for incident response, Red Team activities including supply chain security research, and product security enhancements like Spamcheck and Package Hunter. Specific technical details include the use of BPF and perf for Redis latency diagnosis, and the migration from Unicorn to Puma for application servers.
  55. Five key actions to take based on OWASP Top 10 2021 updatesThis post discusses the OWASP Top 10 2021 updates and maps them to GitLab's security features. It highlights how SAST, DAST, Dependency Scanning, Container Scanning, Secret Detection, and fuzz testing can help address specific OWASP categories. It also emphasizes the importance of security-first design, threat modeling, and penetration testing. The post includes a table showing GitLab's coverage of the OWASP risks.
  56. Action needed by self-managed customers in response to CVE-2021-22205This post details a critical vulnerability (CVE-2021-22205) in a third-party Exif-Tool parser used by GitLab, which allows for remote command execution. It affects specific self-managed versions (11.9.x - 13.8.7, 13.9.0 - 13.9.5, 13.10.0 - 13.10.2) and has been confirmed to be exploited. Customers are urged to upgrade to patched versions (13.10.3, 13.9.6, 13.8.8 or later) or apply a hotpatch. GitLab.com users are not affected. It also provides guidance on how to determine if an instance has been compromised and directs users to security alerts.
  57. Notice for GitKraken users with GitLabThis post details a vulnerability in GitKraken's key generation package that could lead to weak or duplicate SSH keys, potentially allowing unauthorized access to GitLab accounts. It outlines the affected GitKraken versions and the fix in version 8.0.1. GitLab has taken action by emailing affected users, blocking known weak keys on GitLab.com, and providing instructions for self-managed customers to revoke and regenerate their SSH keys and update GitKraken.
  58. Why are developers so vulnerable to drive-by attacks?This post details a specific drive-by attack vector targeting developer workstations by chaining vulnerabilities in the GitLab Development Kit (GDK). It explains how malicious JavaScript can exploit relaxed security in development environments, particularly focusing on cross-origin requests, CORS preflight requests, and simple requests. The example demonstrates how vulnerabilities in 'Better Errors' and 'webpack-dev-server' within the GDK could lead to remote code execution (RCE) by exfiltrating error codes from logs and instructing 'Better Errors' to evaluate arbitrary Ruby code. The post emphasizes that these specific vulnerabilities were patched.
  59. How to secure your software build pipeline using code signingThis post introduces code signing as a critical security measure for software build pipelines, inspired by recent supply chain attacks. It explains the principles of digital signatures and code signing, emphasizing the 'sign early, sign often' strategy. The post highlights the complexities of managing PKI and code signing certificates, and the need for integration with developer workflows like GitLab. It announces a partnership between Venafi and GitLab to simplify code signing within the GitLab environment, enabling developers to sign artifacts without deep PKI knowledge. The Venafi CodeSign Protect solution is presented as a way to 'shift left' security controls.
  60. How a new integration helps GitLab customers secure their codeThis 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.
  61. Package Hunter: Detect malicious code in dependenciesGitLab releases Package Hunter, a new open-source tool to detect malicious code in program dependencies. Package Hunter installs dependencies in a sandbox environment and monitors system calls using Falco to identify suspicious behavior. It currently supports NodeJS modules and Ruby Gems and integrates with GitLab CI.
  62. A brief look at Gitpod, two bugs, and a quick fixThis post details the discovery and exploitation of two vulnerabilities in Gitpod: a cross-origin WebSocket access vulnerability that allowed an attacker to obtain user OAuth tokens, and a login vulnerability that allowed an attacker to log in as any account on a self-managed GitLab instance by spoofing email addresses. Both vulnerabilities were reported to Gitpod and fixed promptly.
  63. How to protect your source code with GitLab and JscramblerThis 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.
  64. Ask a hacker: ajxchapmanThis post features an interview with a bug bounty hunter who discusses their motivations, preferred hunting methods (white/grey box), and positive experiences with GitLab's Bug Bounty Program due to its open nature and reward table. They highlight the value of source code access for finding complex bugs and suggest companies improve their vulnerability reporting policies. The hunter also expresses concern about supply chain attacks and suggests areas for further research. They also provide feedback on improving GitLab's Markdown editing experience.
  65. Masked variable vulnerability in Runner version 13.9.0-rc1This post details a vulnerability in GitLab Runner version 13.9.0-rc1 where masked CI variables could be exposed in build logs. It outlines the affected versions and timeframes on GitLab.com and for self-managed instances, provides examples of how variables could be exposed, and instructs users on remediation steps (reviewing jobs, rotating secrets, upgrading/downgrading runner). It also explains the release candidate process and actions taken by GitLab to mitigate the issue.
  66. How GitLab uses Third Party Security Rating to Build Customer ConfidenceThis post details how GitLab partnered with BitSight to improve its third-party security rating. It describes the challenges of inaccurate ratings due to segmented environments and dynamic infrastructure, and the steps taken to address these issues, including validating the digital footprint, creating environment tags, and implementing a process for identifying, managing, and remediating findings. The post also outlines the criteria used to select a suitable third-party rating platform.
  67. Android App Security Testing with SASTThis 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.
  68. How we made GitLab more secure in 2020This post details the implementation of functionality to identify AWS instance keys accidentally disclosed in public repositories on GitLab.com. This functionality alerts AWS and displays findings in the security dashboard. It also discusses the improvement of vulnerability management across application security, infrastructure security, and bug bounty programs, including the adoption of a GRC tool. The post also introduces a next-generation SIEM (Panther Labs) for improved visibility, detection, and response, and the creation of a public 'Red Team Tech Notes' project for sharing technical challenges and solutions.
  69. Why (Continuous) FuzzingThis 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.
  70. Tired of afterthought security? Take a fresh look at GitLab UltimateThis post highlights GitLab's comprehensive application security testing capabilities, including SAST, dependency scanning, container scanning, API scanning, and fuzz testing. It emphasizes the integration of these scans into the developer workflow via MR pipelines and the availability of security dashboards for security professionals. The post also mentions the acquisition of Peach Tech and Fuzzit, expanding fuzz testing capabilities. It positions GitLab Ultimate/Gold as a complete security solution rather than just an add-on.
  71. How to secure your Kubernetes pods using GitLab Container Network SecurityThis post introduces GitLab's Container Network Security feature, which leverages Cilium as a managed application to implement Kubernetes Network Policies. It explains the concepts of Network Policies, their selectors (podSelector, namespaceSelector, ipBlock), and provides an example YAML configuration. It details the installation process of Cilium as a GitLab-managed application and highlights the Threat Monitoring dashboard powered by Hubble for visualizing packet flow metrics and managing Network Policies through an intuitive UI. The post also links to related security resources.
  72. How open source contributions accelerate GitLab SecureThis post details GitLab's strategy for building secure systems in the open, emphasizing "shifting left" by integrating security tools directly into developer workflows. It highlights the suite of GitLab Secure features (SAST, DAST, Container Scanning, Dependency Scanning, License Scanning, Secret Detection, API Fuzzing, Coverage Fuzzing) and the importance of community contributions and integration partners. Specific community contributions mentioned include Mobile SAST support via MobSF, Helm Chart support, performance improvements to Fuzz testing, updates to secret detection and dependency scanning, OS updates for scanners, .NET Framework support, and a full list of community contributions for Secure. It also mentions the integration partner program.
  73. Get the most out of the Checkmarx integration with GitLabThis post details the integration of Checkmarx's application security testing platform with GitLab CI/CD. It introduces CxFlow as the bridge between GitLab and Checkmarx, enabling automated scans of commits and merge requests. The integration allows for customizable scan triggers, feedback loops, and defect tracking, including creating single issues for recurring vulnerabilities and closing them automatically. Results can be consumed via GitLab's security dashboard, issues, or merge requests, or integrated with external tools like Jira, ServiceNow, and Rally. The post outlines the technical steps for setting up global variables and including a separate YAML file for the Checkmarx stage in the CI/CD pipeline.
  74. GitLab's security trends report – our latest look at what's most vulnerableThis post analyzes security vulnerability trends across thousands of projects hosted on GitLab.com, identifying trends and patterns for security practitioners. It provides recommendations for security issue triage, applying security fixes for containers and project dependencies, static and dynamic analysis, secret storage, web application security, and fuzz testing. It also details trends by CWE, including Improper Input Validation (CWE-20), Out of Bounds Write (CWE-787), and Uncontrolled Resource Consumption (CWE-400). Dependency scanner trends show an increase in projects finding issues with dependent libraries, and container scanner trends show a decrease in projects finding issues with containers. Static analysis trends remain mostly unchanged, with specific vulnerabilities like 'Password in URL' and 'Insecure usage of temporary file' highlighted. Secret handling vulnerabilities include PKCS, RSA Key, and AWS API keys. DAST trends show an increase in projects finding vulnerabilities.
  75. Running Security Scans in Limited Connectivity and Offline EnvironmentsThis post details how to configure and run GitLab's security scanners (Container Scanning, SAST, DAST, License Compliance, Dependency Scanning) in offline or limited connectivity environments. It outlines the necessary steps to use locally available resources and provides a video tutorial for setup.
  76. How information security practices help everyoneThis post details the application security stable counterpart role, where security engineers collaborate with development teams throughout the SDLC to assess risk, review code, and drive security-conscious outcomes. It also highlights initiatives to enable GitLab's Secure tooling (SAST, DAST, Container Scanning) in major product repositories and configure container scanning for Docker images. The author provides advice on writing unit tests for unexpected cases to improve application security and emphasizes GitLab's commitment to transparency in security.
  77. Upcoming Breaking Changes to Secure Analyzers in GitLab 13.4This post announces the removal of the `secrets-sast` job from the SAST CI template, the deprecation and upcoming removal of Docker-in-Docker (DinD) for security scanners, the transition of the GitLab Bandit Python Analyzer to an Alpine Linux image, and the deprecation and removal of the TSLint job in favor of ESLint. It provides guidance on how users should update their configurations to maintain secret scanning and other security functionalities.
  78. How GitLab improves cloud native application security and protectionThis post details how GitLab's Secure and Protect features can be used to address a specific cloud-native application security attack scenario. It demonstrates the use of Container Host Security (Falco) for real-time attack detection, Container Network Security (Cilium Network Policies) for blocking unauthorized network traffic, Web Application Firewall (ModSecurity) for blocking attacks at the Ingress level, and Static Application Security Testing (SAST) with Gosec for identifying and fixing code vulnerabilities. The post also mentions a session at GitLab Commit for further insights.
  79. The developer-security divide: frank talk from both sidesThis 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.
  80. How to benchmark security tools: a case study using WebGoatThis post contributes to the understanding of security tool benchmarking by analyzing the limitations of using WebGoat as a target. It details the architectural components of WebGoat and provides a methodology for evaluating SAST and DAST tool findings against specific lessons. The analysis categorizes flaws by type (e.g., SQL Injection), assesses the probability of detection by SAST and DAST tools, and provides reasoning and example attacks. It highlights that WebGoat's synthetic flaws may not fully exercise advanced SAST capabilities like taint tracking and that DAST tools may struggle with direct SQL query injection.
  81. How to secure your dependencies with GitLab and WhiteSourceThis post details the technical steps for integrating WhiteSource for dependency scanning into a self-managed GitLab instance. It covers creating GitLab service credentials, generating WhiteSource configurations, building and deploying WhiteSource containers on Kubernetes, and configuring CI/CD pipelines to publish security reports. It also explains how to use the generated issues for vulnerability tracking and remediation.
  82. How GitLab protects your IPThis post details how GitLab protects intellectual property (IP) stored in code repositories by explaining user access controls, user organization (roles like Guest, Auditor, Developer, Maintainer, Owner), and specific security features such as protected branches, protected tags, push rules, merge request approvals (including DevSecOps and SAST integration), and code owners. It also covers how to trace access and changes through audit events and provides an example of managing permissions as code.
  83. My experience interning to work with security scanning at GitLabThis 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.
  84. Get better container security with GitLab: 4 real-world examplesThis post details how GitLab's security features (Secret Detection, Dependency Scanning, DAST, WAF, Container Host Security, Network Policies, Pod Security Policies) can be used to prevent and detect specific attack vectors (exposed credentials, supply chain attacks, exploits leading to execution, lateral movement, reverse shells, filesystem modification) in containerized applications. It maps these attack scenarios to MITRE ATT&CK tactics and demonstrates how GitLab's CI/CD pipeline and Kubernetes integrations provide layered security.
  85. DevSecOps basics: 5 steps to standardize (and then scale) securityThis 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.
  86. Automated security testing for DevSecOpsThis 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.
  87. How GitLab's application security dashboard helps AppSec engineersThis post details how GitLab's security scanning capabilities (SAST, DAST, Container Scanning, Dependency Scanning, License Scanning) and the Security Dashboard aid AppSec engineers. It explains how scans populate MRs with vulnerability data, how the dashboard provides a high-level overview and drill-down capabilities for vulnerability management and auditing, and how license management can block MRs with unacceptable licenses. It also mentions integration with third-party scanners and the creation of confidential issues.
  88. GitLab instance: security best practicesThis post details security best practices for hardening a self-managed GitLab instance, focusing on access controls, password policies, SSH key management, sign-up and sign-in restrictions (including MFA), project visibility, rate limiting for users and IPs, and webhook security. It emphasizes the balance between security and agility for internet-facing instances.
  89. Security strengthened by iteration, and transparencyThis post details the work of a senior application security engineer, focusing on identifying and mitigating vulnerabilities in GitLab's codebase. Key initiatives include developing automated testing for permission bugs, reviewing APIs for information leaks, and building expertise in the Verify and Release stages. The engineer also emphasizes the importance of the principle of least privilege and the benefits of transparency in enhancing product security.
  90. How we manage open source security softwareThis post discusses GitLab's approach to open source security, emphasizing the importance of dedicated security personnel, management buy-in, and a culture that avoids shame and punishment for security issues. It highlights GitLab's transparent disclosure of vulnerabilities in both open source and proprietary code, and the integration of security into the DevSecOps workflow. Key actions include having security engineers on staff, ensuring management support, and making security a 'muscle memory' for engineers.
  91. Top 6 security trends in GitLab-hosted projectsThis post introduces GitLab's first security trends report, analyzing vulnerability data from GitLab.com-hosted projects. It identifies six common vulnerability types: components with known vulnerabilities, XSS, lack of secret management, CSP, CSRF, and SQL injection. The report details trends in vulnerability scanning volume and specific vulnerability types, highlighting an increase in scanning activity and detected vulnerabilities. It also provides best practices for mitigating each vulnerability type, leveraging GitLab's security scanning tools (SAST, DAST, dependency scanning, container scanning, secret detection).
  92. Introducing Accessibility Testing in GitLabIntroduced 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.
  93. How to limit access to manual pipeline gates and deployments using GitLabThis post introduces the use of manual jobs in GitLab CI/CD pipelines, combined with protected environments, to control access to deployments and add manual approval steps. It details how to configure manual jobs to deploy to protected environments, restricting execution to authorized users based on their roles. It also explains how to use blocking manual jobs in separate stages to create approval steps before proceeding with subsequent pipeline stages. YAML examples and UI screenshots illustrate the implementation.
  94. We answer your most popular questions about our Zero Trust journeyThis post discusses the challenges of data classification fluidity in a Zero Trust model, where data classification can change rapidly, making static access controls difficult to enforce. It introduces the concept of 'data zones' as a temporary solution and highlights the ongoing search for a more granular and scalable solution. It also details the selection of Okta as an identity management system for its MFA capabilities and flexibility, and discusses the importance of user and device identity, process identity, and audit logging in a Zero Trust implementation.
  95. Google Cloud privilege escalation & post-exploitation tacticsThis 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.
  96. GitLab and WhiteSource: the easy way to secure your open source codeThis 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.
  97. The security tightrope: balancing security with ease-of-useThis post details the security engineer's role in balancing user experience with security friction. It highlights initiatives focused on developing tooling and automation for deeper visibility and proactive security response, leveraging aggregated data for automated response pipelines. Key advice includes using unique passwords with a password manager and enabling 2FA. Emerging trends include integrating security into software development workflows (e.g., SOAR, compliance-as-code) and the need for security teams to scale through automation and actionable data. GitLab's transparency in handling security issues is noted as a strength.
  98. Zero Trust at GitLab: Where do we go from here?This post details GitLab's progress and challenges in implementing a Zero Trust Network (ZTN) approach. It covers the integration of SaaS applications with Okta for authentication and authorization, the rollout of Okta Advanced Server Access (ASA) for SSH access, the use of Camo proxy for encrypted communications, and the importance of robust server and container security with visibility through tools like Tenable and Uptycs. It also discusses the challenges of logging and budget allocation for ZTN initiatives, and provides advice on breaking down needs into simple components and focusing on user and device authentication.
  99. Zero Trust at GitLab: Implementation challenges (and a few solutions)This post details the implementation challenges and some solutions for Zero Trust Networking (ZTN) at GitLab. It discusses immediate challenges in implementing ZTN, including resistance to change, and real problems related to user identity provisioning, device management (especially with BYOD roots and diverse platforms), and sprawling infrastructure (SSH access, multi-cloud, SaaS offerings). Wins include the successful implementation of Okta for user identity management, which streamlined provisioning and met compliance needs. The post explores leveraging Okta's Advanced Server Access (ASA) to integrate SSH accounts and enforce multi-factor authentication for server access, acknowledging potential performance impacts and client software distribution challenges. It also highlights the ongoing challenge of device management despite Okta integration, noting the need for better control over company-issued laptops and mobile devices.
  100. Zero Trust at GitLab: Data zones & authentication scoringThis post introduces the concepts of 'data zones' and an 'authentication scoring system' as part of GitLab's Zero Trust initiative. Data zones group data based on access controls when granular control is not possible, with four zones (RED, ORANGE, YELLOW, GREEN) mirroring data classification. The authentication scoring system assigns points for basic authentication, U2F, managed devices, device health, and geolocation to determine access levels to these zones. The goal is to achieve more granular control over data access, automate processes, and simplify onboarding/offboarding.
  101. Zero Trust at GitLab: The data classification and infrastructure challengeThis post details the challenges of implementing Zero Trust (ZTN) at GitLab, focusing on data classification and infrastructure. It outlines the data classification policy (RED, ORANGE, YELLOW, GREEN) and the anticipated challenges with ZTN, including the changing state of data, tracking metadata, time limits on data, data capability, and data movement. It also discusses infrastructure challenges related to multi-cloud environments, unclear administrative access, and enforcing SaaS application privileges. The post sets the stage for future installments discussing specific design solutions.
  102. Zero Trust at GitLab: Problems, goals, and coming challengesThis 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.
  103. Adobe CCF becomes GitLab's open source control frameworkThis 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.
  104. Ask GitLab Security: Alexander DietrichThis 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.
  105. Ask GitLab Security: Roger OstranderThis 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.
  106. When technology outpaces security complianceThis 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.
  107. Group Runner Registration Token VulnerabilityThis post details a security vulnerability where Group Runner Registration Tokens were exposed. A patch was deployed to GitLab.com, and Group Runner Registration Tokens were reset. Critical security releases (EE 11.9.7, 11.8.7, 11.7.11) were issued for self-managed instances. No evidence of unauthorized project access was found. Self-managed Community Edition instances are unaffected.
  108. The evolution of Zero TrustThis 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.
  109. Project runner registration token security updateThis post details a security vulnerability in quick actions for issues that exposed project runner registration tokens to unauthorized users. A patch was applied to GitLab.com on March 17, 2019, and a critical security fix was expedited for self-managed customers. Runner registration tokens for all projects on GitLab.com were reset on March 24, 2019. Users with automation relying on these tokens were instructed to update their scripts. An investigation found no evidence of security compromise, but the company is improving detection methods.
  110. This is what happens if you lose access to your 2FA GitLab.com accountThis 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.