
In the world of software development, the ultimate testament to a platform's capability is often whether its own creators rely on it for their most critical tasks. For GitLab, the comprehensive DevSecOps platform, this isn't just a talking point—it's a fundamental operational reality. GitLab runs its entire company, develops its vast software, manages its complex infrastructure (including GitLab.com), and fosters its all-remote culture using its own single application. This profound commitment to "eating your own dogfood," or as they often put it, "GitLab on GitLab," is not just a practice; it's a core tenet that shapes the product, drives innovation, and ensures a deep empathy with its global user base.

### The Entire Company Runs on GitLab: A Single Source of Truth

GitLab's vision, as often articulated by CEO Sid Sijbrandij and reflected in their extensive [public handbook](https://handbook.gitlab.com/handbook/), is to provide a single application for the entire software development lifecycle. This vision is most powerfully validated by their own internal adoption. From idea to production, GitLab uses GitLab for:

* **Source Code Management:** The millions of lines of code that constitute GitLab itself are managed in GitLab repositories. Every merge request, every code review, and every version iteration happens within their own platform.
* **Continuous Integration/Continuous Deployment (CI/CD):** GitLab's robust CI/CD capabilities are the engine behind their own development velocity. They use GitLab CI/CD to automatically build, test, package, and deploy GitLab.com and its various components multiple times a day. The [GitLab Handbook page on "Dogfooding CI/CD"](https://handbook.gitlab.com/handbook/engineering/infrastructure/library/ci-cd/) provides a glimpse into how seriously they take this internal proving ground.
* **Plan and Project Management:** All work, from strategic initiatives and new feature development (organized via Epics, Issues, and Iterations) to marketing campaigns and HR projects, is planned, tracked, and managed using GitLab's own planning tools. This ensures that these features are robust and genuinely useful for diverse team workflows.
* **Security (DevSecOps):** GitLab champions a "Shift Left" security approach, and they apply this to their own development by integrating their suite of security scanning tools (SAST, DAST, Dependency Scanning, Secret Detection, etc.) directly into their CI/CD pipelines. This internal use is critical for refining these DevSecOps capabilities.
* **Collaboration and Communication:** As a pioneering all-remote company with team members in over 65 countries, asynchronous communication and transparent collaboration are vital. GitLab (the product) serves as the central hub. Merge requests are key collaboration points, issues track discussions, and the entire company handbook—a sprawling, living document of over 2,000 pages detailing how they operate—is a GitLab project, open to contributions and iterations from all team members. This transparency, a core GitLab value, is enabled by their own platform.
* **Operating GitLab.com:** The SRE (Site Reliability Engineering) and infrastructure teams responsible for the massive GitLab.com SaaS offering use GitLab's monitoring, deployment, and incident management capabilities to keep the service running. This is arguably the most demanding "dogfooding" environment, pushing the platform to its limits in terms of scale and reliability.

### How "GitLab on GitLab" Drives Product Evolution

This deep immersion in their own platform provides a continuous, high-fidelity feedback loop that directly shapes the product:

* **Real-World Problem Solving:** When GitLab's own engineers encounter a bottleneck in their CI/CD pipelines, a missing feature in issue tracking, or a cumbersome aspect of code review, they are experiencing the same pain points their users might. This creates a powerful internal impetus to build solutions that address these real-world needs.
* **User-Centric Design for Developers:** Because GitLab's primary internal users are developers, DevOps engineers, and product managers, the platform naturally evolves to meet the sophisticated demands of technical users who value efficiency, automation, and a comprehensive toolset.
* **Rapid Iteration:** With a monthly release cycle ("every month on the 22nd," as highlighted by [Sid Sijbrandij in an InfoQ interview](https://www.infoq.com/articles/gitlab-sid-interview-sw-development/)), the ability to quickly test and validate new features internally is crucial. "GitLab on GitLab" allows for rapid iteration based on immediate internal feedback.
* **Feature Prioritization:** The features that solve the most significant internal pain points or unlock substantial productivity gains for GitLab's own teams are often strong candidates for broader development and release.
* **AI Integration (GitLab Duo):** As GitLab integrates AI capabilities across the DevSecOps lifecycle with GitLab Duo (e.g., AI-assisted code suggestions, vulnerability explanations, value stream forecasts), its own teams are among the first to utilize and refine these tools in their daily workflows, shaping the future of AI-powered software development from within.

### The All-Remote Context: Shaping a Platform for Distributed Teams

GitLab's all-remote culture is not just a work style; it's a product shaper. Because the entire company collaborates and builds software without a central physical office, the GitLab platform has been inherently designed and optimized for asynchronous workflows, clear communication trails (via issues and merge requests), and transparency. This makes it an exceptionally strong platform for other distributed teams and organizations embracing remote or hybrid work models. Their [All-Remote guide](https://about.gitlab.com/company/all-remote/) is a testament to their expertise, and the platform reflects these ingrained practices.

### Benefits of a Transparent, Dogfooding Culture

The "GitLab on GitLab" approach, coupled with their commitment to transparency (much of their handbook and roadmap are public), yields significant benefits:

* **Authenticity and Trust:** Users and customers can see that GitLab believes in its own product enough to run its entire business on it.
* **High-Quality, Battle-Tested Features:** Features are rigorously tested in a demanding, real-world environment before reaching the wider community.
* **Deep Understanding of User Needs:** GitLab developers have an intrinsic understanding of the challenges and desires of other software development teams.
* **Strong Community Alignment:** By being open about their processes and using their own product, they foster a strong connection with their open-source community.

While the primary users within GitLab are highly technical, the company also focuses on making the platform accessible. However, the depth and breadth of features, as noted in some external analyses like a [SentinelOne article on GitLab CI/CD Security](https://www.sentinelone.com/cybersecurity-101/cloud-security/gitlab-ci-cd-security/), can sometimes present a learning curve for new users—a common challenge for comprehensive platforms that GitLab likely continuously addresses through documentation and UI refinements based on broad feedback.

### Conclusion: The Ultimate DevOps Proving Ground

GitLab's commitment to using its own platform for every facet of its operations is a powerful demonstration of confidence and a critical driver of its innovation. By making its own teams the first and most demanding users, GitLab ensures that its DevSecOps platform is not just a collection of features but a deeply integrated, battle-tested solution designed to meet the real-world challenges of modern software development. The "GitLab on GitLab" philosophy means that when users choose GitLab, they're adopting a platform that is continuously shaped and validated by a global team of experts who don't just build the future of DevOps—they live it every day.

GitLab on GitLab: How the DevOps Platform Builds Itself and a Culture of Iteration


In the fast-paced world of software development, particularly in critical sectors like cybersecurity, the mantra "practice what you preach" holds significant weight. For companies building complex solutions, becoming the first and most demanding user of their own technology can be a powerful catalyst for growth, refinement, and genuine understanding of customer needs. Wiz, a prominent player in the cloud security space, exemplifies this approach by deeply integrating its own Cloud Native Application Protection Platform (CNAPP) into its daily operations. This isn't just about testing; it's about living and breathing the solution they offer to the world.

Wiz has rapidly ascended in the cybersecurity landscape by providing a platform designed to give organizations comprehensive visibility and control over their cloud environments. Their agentless solution scans entire cloud estates, including IaaS, PaaS, and Kubernetes, to identify risks, vulnerabilities, and misconfigurations. But how does a company dedicated to securing complex cloud infrastructures ensure its own offerings are robust, user-friendly, and truly effective? By becoming "customer zero."

**Building with and for the Cloud: The Wiz Approach**

From its inception, Wiz was built in the cloud, for the cloud. This cloud-native DNA naturally lends itself to leveraging its own security platform. The engineers and security teams at Wiz are not just building a product; they are active users, relying on the same dashboards, alerts, and remediation guidance that their customers do. This daily interaction provides an invaluable, continuous feedback loop.

Imagine a Wiz developer pushing new code or a DevOps engineer spinning up new cloud resources. The Wiz platform itself is there, scanning these changes in near real-time. If a new potential vulnerability is introduced or a misconfiguration occurs within Wiz's own development or production environments, their internal teams are often the first to know, experiencing firsthand the detection capabilities and the user experience of their product.

This internal utilization fosters several key benefits:

1.  **Accelerated Product Refinement:** Bugs, usability issues, or gaps in coverage are identified and addressed more rapidly when your own teams are on the front line. There's a heightened sense of urgency and a deeper understanding of the impact of these issues when they affect your colleagues and your company's own security posture. As [Ami Luttwak, Co-founder and CTO of Wiz, has often emphasized the importance of speed and customer obsession](https://www.wiz.io/blog/authors/ami-luttwak), this internal usage directly fuels that velocity by shortening the feedback cycle.
2.  **Deep Empathy for the Customer Experience:** By navigating the complexities of cloud security using their own tools, Wiz employees gain profound insights into the challenges their customers face. They understand the alert fatigue that can come from less sophisticated tools, the need for clear prioritization of risks, and the importance of actionable remediation guidance. This empathy translates directly into product design and feature development.
3.  **Realistic Testing Environment:** What better way to test a cloud security platform than in a dynamic, real-world cloud environment? Wiz's own infrastructure, with its evolving services and applications, serves as a demanding proving ground. This goes beyond staged testing scenarios, offering a more authentic measure of the platform's effectiveness.
4.  **Driving Innovation from Necessity:** When Wiz's internal teams encounter a new type of cloud risk or a gap in their existing visibility, it often becomes a direct input into the product roadmap. They are not just responding to market demands but are also anticipating future needs based on their own advanced use cases and security challenges. This proactive approach can lead to pioneering features and capabilities. For instance, as new cloud services are adopted internally, the imperative to secure them with their own platform drives the expansion of Wiz's coverage and analytical capabilities.

**The Technology and Patterns at Play**

Wiz's platform itself is a testament to modern cloud architecture, and its internal use reflects this. Key technological aspects and patterns include:

* **Agentless Scanning:** Internally, Wiz benefits from its own agentless approach, meaning they don't need to deploy and manage cumbersome agents across their cloud resources to gain visibility. This reduces friction and operational overhead for their own teams, just as it does for their customers.
* **Graph-Based Analysis:** Wiz's Security Graph, which contextualizes disparate cloud risks, is undoubtedly a critical tool for their internal security teams. By visualizing attack paths and understanding the blast radius of potential vulnerabilities within their own environment, they can prioritize efforts effectively.
* **Comprehensive Coverage:** As Wiz expands its own cloud footprint, whether through new AWS, Azure, GCP, or Kubernetes deployments, the internal mandate to secure these resources with their platform ensures that Wiz's product development keeps pace with the ever-expanding cloud ecosystem.
* **DevSecOps Integration:** While specific details of their internal CI/CD pipelines are proprietary, it's highly probable that Wiz integrates its security scanning capabilities early in its own development lifecycle. This "shift-left" approach, a core tenet of DevSecOps, means that security is considered from the outset, rather than as an afterthought, likely using their own tools to achieve this.

**Potential Pitfalls? The "Not Invented Here" Syndrome Inverted**

While the benefits of a company intensely using its own products are numerous, it's also worth considering potential, albeit often subtle, downsides. One theoretical risk is developing a form of "tunnel vision." If a company exclusively uses its own solutions, it might become less attuned to alternative approaches or novel challenges that its product doesn't currently address, simply because those issues don't arise prominently within its own specific operational context.

For a company like Wiz, which operates in the diverse and rapidly evolving cloud security market, maintaining a broad perspective is crucial. They mitigate this risk through extensive customer interaction, feedback from the wider security community, and by actively researching emerging threats and cloud technologies. However, the intense focus on one's own solution always requires a conscious effort to look externally.

Another consideration is the "echo chamber" effect. If the internal teams become too accustomed to the product's current state, they might inadvertently overlook usability issues that a fresh pair of eyes – a new customer – would immediately spot. Again, robust customer feedback mechanisms and a diverse user base are key antidotes here. Wiz appears to actively engage with its customers, as highlighted in many of their [customer success stories and case studies on their website](https://www.wiz.io/customers), which would provide this external perspective.

**The Broader Impact: A Model for Customer-Centricity**

Wiz's commitment to leveraging its own platform internally is more than just a smart development strategy; it's a powerful statement about their confidence in their product and their dedication to understanding the real-world challenges of cloud security. It fosters a culture where every employee, from engineering to sales, can have a tangible connection to the value they deliver.

This practice of being "customer zero" ensures that the product is not developed in a vacuum. Instead, it is continuously shaped by the practical needs and experiences of its first and most critical user: Wiz itself. This approach allows them to innovate faster, build more resilient and user-friendly solutions, and ultimately, better serve the thousands of organizations that rely on Wiz to secure their journey to the cloud.

For other software companies, especially in rapidly evolving tech sectors, Wiz's model offers valuable lessons. By embedding your own solutions into the fabric of your operations, you don't just build a product; you cultivate a deeper understanding, foster genuine empathy, and ultimately, create more impactful technology.

Securing the Cloud from Within: How Wiz Leverages Its Own Platform for Innovation

For decades, security has often been treated as a final, fortified gate in the software development lifecycle—a checkpoint managed by a specialized team before code ships to production. But in an era of high-velocity CI/CD pipelines and complex cloud-native architectures, that model is fundamentally broken. The modern approach, DevSecOps, calls for security to be a shared responsibility, woven into every stage of development. For a company like New Relic, whose very business is providing deep insight into complex systems, this isn't just a philosophy they sell; it's a principle they must live by.

To build a credible security product in today's landscape, a company must first look inward. It needs to confront the same challenges its customers face: tool sprawl, alert fatigue, and the constant tension between speed and safety. New Relic's journey into security observability is a prime example of this, where the development of its own tools is intrinsically linked to the needs of its own engineering teams.

### **The Internal Problem: A Flood of Signals, A Puddle of Context**

Imagine being an engineer at New Relic. You operate a planet-scale platform that ingests over 120 petabytes of data every month, running on thousands of nodes across dozens of Kubernetes clusters. The performance and reliability of this system are paramount. But so is its security.

In such an environment, security signals come from everywhere: static code analysis tools, dependency scanners, cloud configuration monitors, and runtime threat detectors. The result is often a deluge of alerts, each siloed within its own tool. This creates a cascade of problems that New Relic's own teams would inevitably face:

* **Alert Fatigue:** When developers are bombarded with low-context security warnings, they quickly become noise. Legitimate threats can get lost in the flood.  
* **Lack of Prioritization:** Is a 'critical' vulnerability in a non-production, internal-only service more important than a 'medium' vulnerability in a core production library? Without context from an observability platform, it's nearly impossible to know.  
* **Developer Friction:** Tossing a security report "over the wall" to a developer without actionable context forces them to stop coding, switch tools, and begin a time-consuming investigation.

Solving this for their customers meant first solving it for themselves. This necessity appears to be the driving force behind **New Relic Vulnerability Management**.

### **Building the Solution: From APM to IAST**

New Relic's history is rooted in Application Performance Monitoring (APM). Their agents already live deep within an application's runtime, observing performance metrics and tracing requests. This existing footprint provided a unique advantage. Why couldn't that same agent also watch for security vulnerabilities?

This logical extension led to the development of their own security offerings. A key move was the acquisition of K2 Cyber Security, which brought powerful **Interactive Application Security Testing (IAST)** technology into the fold. As detailed in a [DevOps.com article](https://devops.com/new-relics-bolsters-observability-platform/), IAST allows New Relic to use its agents to detect and validate vulnerabilities *as the application runs*, without requiring separate, disruptive scans.

In their blog post, ["Streamlined security: Integrating IAST into your DevSecOps strategy,"](https://newrelic.com/blog/best-practices/iast-devsecops) New Relic champions a vision where security is not a separate step but an integrated part of the workflow. The post states, "IAST operates live, immediately spotlighting vulnerabilities," and emphasizes "fewer false alarms." This isn't just marketing copy; it's a direct solution to the internal pain points of alert fatigue and developer friction. By building these capabilities into the platform their own engineers use daily, New Relic could refine a system that provides:

* **Unified Visibility:** Bringing native vulnerability detection alongside third-party security signals into the same platform where performance data lives.  
* **Context-Rich Prioritization:** Correlating a vulnerability with the specific application entity, its environment (production, staging), and its performance impact.  
* **A "Single Pane of Glass":** Allowing developers, SREs, and security teams to look at the same data, breaking down the silos that create so many issues.

### **The Risk of a Unified Vision**

Did this strategy lead them astray? There's no evidence of a major misstep, but it does introduce a new, more nuanced set of challenges. By championing a platform that unifies observability and security, New Relic is also championing a significant cultural shift. The tool is designed to empower developers to take on more security responsibility.

The potential pitfall here is not in the technology itself, but in the implementation of the culture it requires. For an organization—whether it's New Relic internally or one of their customers—that isn't ready for this "shift-left" mindset, a unified tool can feel complex. It asks developers and operations engineers to engage with a domain that has traditionally been someone else's problem. If the organizational structure and training aren't in place to support this shift, the tool's power can become a source of complexity rather than a solution.

The case study of their customer, Dustin, as detailed on the [New Relic blog](https://newrelic.com/blog/how-to-relic/monitoring-solution-merger-dustin), highlights the goal: to use a unified tool to "make sure that when we did get an alert, it was accurate and valuable." The unstated challenge is the organizational work required to get to that point.

### **Conclusion: Charting a Secure Path Forward**

New Relic's foray into security is a natural evolution of its core mission. They are applying the principles of observability to one of the most complex and critical domains in modern software. By building the security tools they need internally, they've created a powerful feedback loop. The daily challenges faced by their own engineers in securing a massive, dynamic platform directly inform the features and philosophy of their Vulnerability Management product.

This approach of "securing thyself" is more than just a development strategy. It’s a testament to the belief that in the world of DevSecOps, you can't effectively solve a problem for your customers until you've first solved it for yourself. The result is a platform that doesn't just find vulnerabilities, but provides the context needed to fix them, aiming to make security an integral, observable, and manageable part of everyone's workflow.

Articles tagged with "Devsecops"

GitLab on GitLab: How the DevOps Platform Builds Itself and a Culture of Iteration

Securing the Cloud from Within: How Wiz Leverages Its Own Platform for Innovation

Secure Thyself: Inside New Relic's DevSecOps Feedback Loop