Orange Business: Prevention-First Secrets Security Transformation

The soft hum of the development server was usually a comforting backdrop to Maya’s late-night coding sessions.

Tonight, however, it felt like a low thrum of anxiety.

She had just pushed a batch of critical updates for a new service, a tight deadline looming.

But a few hours later, a notification blinked on her screen – an automated alert, not from her unit’s usual security checks, but from a new enterprise system.

It flagged a string of characters in her recent commit.

Her heart sank.

It was an API key, mistakenly embedded in a configuration file, now sitting in the Git repository.

The problem was not just that it was exposed; it was the chilling realization that, once there, truly deleting it from Git’s history was notoriously difficult, if not impossible.

Maya understood the tightrope developers walked between speed and security, but this felt like a chasm.

This scenario, a common nightmare for developers and security teams alike, highlights one of the most persistent and growing challenges in modern software development: managing secrets sprawl.

For organizations operating at immense scale, like Orange Business, the problem amplifies exponentially.

When Grégory Maitrallain, Solution Architect at Orange Business, spoke at Les Assises de la Cybersécurité, he shared a compelling story of transforming this challenge.

It is a story about adopting a prevention-first approach, working with developers rather than against them, to secure thousands of repositories and manage the digital keys to their kingdom.

In short: Orange Business transformed secrets security by implementing a prevention-first strategy with GitGuardian.

This approach achieved developer adoption and significantly reduced exposure risks across its thousands of repositories and developers, offering a scalable model for enterprise cybersecurity.

Why This Matters Now: The Stakes of Digital Transformation

Maya’s accidental leak illustrates a systemic vulnerability faced by nearly every enterprise today.

Industry research indicates that developers inadvertently expose an average of 2-3 secrets per year (Original Article Snippet, n.d.).

For Orange Business, a global telecommunications giant with over 3,000 developers working across hundreds of projects, this translates into potentially thousands of sensitive exposures annually (Original Article Snippet, n.d.).

These are not just minor oversights; exposed secrets—API keys, database credentials, access tokens—are direct gateways for attackers to critical systems, customer data, and intellectual property.

Moreover, the problem is not confined to code.

Secrets are increasingly scattered across various tools and systems: collaboration platforms like Teams and Confluence, project management tools like Jira, and even container registries (Original Article Snippet, n.d.).

This widespread secrets sprawl creates an expanding attack surface that traditional security measures struggle to contain.

Compounding this technical challenge are evolving regulatory requirements.

The NIS 2 Directive, for instance, has introduced clear mandates for secrets to be managed and encrypted (Original Article Snippet, n.d.).

This dual pressure—from escalating technical risk and tightening compliance—makes a robust, scalable secrets security solution not just a best practice, but a business imperative for maintaining trust and operational integrity.

The Scale of Vulnerability: Secrets Sprawl in Modern Development

The challenge of secrets security at enterprise scale is vast.

Orange Business’s initial efforts to gain visibility revealed the depth of the problem.

As Grégory Maitrallain explained, We needed to understand the scope of the problem first.

We had Vault solutions in place for projects, but we didn’t know what was happening when projects weren’t using it.

We needed visibility (Original Article Snippet, n.d.).

This lack of comprehensive insight meant blind spots were inherent, leaving critical vulnerabilities undetected.

The counterintuitive insight here is that the very tools meant to foster collaboration and agility—like shared documentation and communication platforms—can inadvertently become vectors for secrets sprawl.

Developers, in the haste of troubleshooting or documenting, might include credentials in support tickets or application logs.

This makes the security perimeter far wider and more complex than just code repositories.

While 70 percent of secrets are found in code repositories, the remaining 30 percent lurking in other systems present equally critical risks (Original Article Snippet, n.d.).

A Painful Lesson: The Open-Source Experiment

Like many organizations, Orange Business initially explored open-source solutions.

They started with GitLeaks, a popular secrets scanner.

While promising in theory, scaling GitLeaks across their diverse projects quickly exposed its limitations.

Grégory recalled the inherent challenge: The problem we had with GitLeaks was that we had to get the projects to use it, and we can’t do it for them.

It requires communication, ensuring they do it, which is quite complicated (Original Article Snippet, n.d.).

The true breaking point came with the results.

For Project Alpha, a large codebase with less GitLeaks expertise, the scanner detected an overwhelming 17,000 secrets.

The reaction from the development team was immediate and telling: They just said, We’re not doing this.

It was too overwhelming (Original Article Snippet, n.d.).

The core issue was not just the sheer volume but the high rate of false positives.

Teams required deep expertise to configure GitLeaks for each project context, and even then, there was no lifecycle management, no prioritization, and no clear path to remediation (Original Article Snippet, n.d.).

This experience underscored a crucial lesson: developer experience determines adoption.

Tools that generate excessive noise quickly become ignored, rendering them ineffective.

What the Evidence Reveals: The Power of Accuracy and Prevention

Orange Business’s journey highlights three critical insights for effective secrets security:

• High false positive rates directly lead to developer rejection of security tools.

  Grégory Maitrallain emphasized, If a developer gets an alert when they commit or push, and 80% of the time it’s a false positive, it immediately becomes something they’ll ignore.

  It becomes a nuisance and noise.

  And that’s unacceptable (Original Article Snippet, n.d.).

  The implication is that to ensure adoption and effectiveness, secrets security solutions must maintain a false positive rate under a critical threshold, ideally under 5 percent, thereby fostering developer trust (Original Article Snippet, n.d.).

  This is the bedrock of developer security.

• Prevention is far more effective than remediation for secret leaks in Git.

  A profound realization for Orange Business was the permanence of secrets in Git history.

  Once a secret is pushed to Git, you cannot truly remove it.

  Even if you modify or delete it from the repository, references persist in the database, discoverable later (Grégory Maitrallain, Original Article Snippet, n.d.).

  This makes prevention exponentially more valuable.

  As Grégory aptly put it, The prevention part is the game changer on this problem of secret leaks, because a secret that is not exposed is a secret that poses no security risk for you, and it’s also a secret that requires no remediation effort behind it.

  That’s really where it’s decided (Original Article Snippet, n.d.).

  The implication is that organizations should prioritize shifting left in security, catching secrets before they are committed, as full remediation after a commit is technically challenging and costly.

• Traditional open-source tools often struggle with scalability and accuracy at enterprise levels.

  The stark contrast seen in Project Alpha, where GitLeaks found 17,000 secrets but GitGuardian detected just 1 valid one in the same codebase (Original Article Snippet, n.d.), illustrates this point vividly.

  The implication is that large organizations require enterprise-grade solutions that offer high accuracy, comprehensive lifecycle management, and centralized governance to handle thousands of developers and projects effectively.

  This enables true enterprise secrets management.

A Three-Layered Defense: Your Playbook for Developer-Centric Security

Armed with these insights, Orange Business designed a robust, three-layered defense strategy with GitGuardian that balances security effectiveness with developer experience, a hallmark of modern DevSecOps.

Layer 1: Developer’s Workstation (Optional but Recommended)

This layer enables GitGuardian to scan code directly on the developer’s machine before it is even committed.

This represents the earliest possible intervention point, embodying true shift-left security.

As Grégory explained, The advantage is that it doesn’t leave their workstation.

It’s really the earliest point.

We’re truly doing shift-left (Original Article Snippet, n.d.).

Despite being optional and having limited initial communication, Orange Business observed encouraging adoption, with projects taking ownership and implementing it locally (Original Article Snippet, n.d.).

Layer 2: GitLab Pre-Receive Hook (Mandatory Enforcement)

This is the critical enforcement layer.

When developers push code to GitLab, GitGuardian scans it and blocks commits containing secrets.

Orange Business implemented this with a nuanced approach, conducting a two-month phased rollout.

This allowed them to gather feedback and identify integration issues, reinforcing their philosophy of working with developers, not against them (Grégory Maitrallain, Original Article Snippet, n.d.).

Developers retain the ability to bypass blocks when necessary (for test values or false positives), but every bypassed secret generates an incident on the GitGuardian dashboard, ensuring full visibility and accountability.

This careful balance maintains workflow velocity while enforcing Git security.

Layer 3: Post-Commit Scanning (Continuous Monitoring)

The third layer provides continuous monitoring across repositories, acting as a crucial safety net.

It catches anything that might slip through the earlier layers due to bypasses or unforeseen edge cases.

Grégory approvingly noted its reliability, saying, It detects what it says and says what it does.

That’s a good thing (Original Article Snippet, n.d.).

This continuous oversight is vital for a comprehensive prevention-first security posture.

Beyond these layers, Orange Business’s journey offers valuable lessons for other enterprises.

• Prevention is your best investment.

  Given that secrets cannot truly be removed from Git history, catching them before commit is exponentially more valuable than costly and often incomplete remediation efforts.

• Developer experience determines adoption.

  Tools with high false positive rates will inevitably be ignored.

  A false positive rate under 5 percent is critical for maintaining developer trust and engagement.

• Phased rollouts build confidence.

  Gradually activating mandatory controls allows for feedback, process refinement, and demonstrates collaboration with developers.

• Enterprise features matter.

  At scale, comprehensive solutions require centralized visibility, distributed remediation, audit trails, and compliance reporting, not just basic detection.

• Accuracy enables scale.

  When alerts are accurate and actionable, security teams can focus on genuine risks rather than wasting time investigating noise.

Navigating the Trade-offs: Risks, Compliance, and Developer Trust

While Orange Business’s prevention-first security strategy has proven highly effective, deploying such comprehensive systems in large enterprises is not without its challenges, risks, and ethical considerations.

One primary risk is the inherent organizational complexity of coordinating security initiatives across multiple business units.

Aligning diverse teams and ensuring consistent adoption requires significant effort.

There’s also the trade-off between maximizing security and maintaining developer autonomy.

While pre-receive hooks enforce security, the ability for developers to bypass checks, even with oversight, highlights a constant tension between strict control and enabling developer workflow.

Ethical considerations are paramount, particularly regarding developer trust.

The success of Orange Business’s approach hinges on treating developers as partners, not as security risks.

Grégory Maitrallain’s philosophy—We work with developers, not against them.

It’s important to have their feedback (Original Article Snippet, n.d.)—underscores this.

Without trust, developers will find ways around burdensome security tools, rendering them ineffective.

Furthermore, adhering to cybersecurity compliance regulations like NIS 2 Directive, which mandates secrets management and encryption, adds a layer of non-negotiable responsibility.

The ethical imperative is to build systems that are both secure and respectful of the human element in software development.

Building Sustained Impact: Tools, Metrics, and Cadence for Secrets Management

Implementing a successful secrets security strategy for application security requires a deliberate approach to tools, metrics, and review cadence.

For tools, organizations should prioritize enterprise secrets management platforms that offer high accuracy and robust lifecycle capabilities, such as those that can scan across various data sources beyond Git repositories including Teams, Confluence, Jira, container registries, and drive storage.

Key Performance Indicators (KPIs) to track progress should include:

• the false positive rate, aiming for consistently below 5 percent to maintain developer trust (Original Article Snippet, n.d.);

• the ratio of secrets detected versus secrets prevented, measuring shift-left effectiveness;

• the average remediation time to resolve detected incidents;

• the developer code correction rate, tracking how often developers proactively fix issues, indicating positive behavior change (Original Article Snippet, n.d.);

• and the ease and accuracy of generating compliance reports for regulations like NIS 2.

A consistent review cadence is essential for continuous improvement and adaptation.

This includes:

• daily automated scanning and immediate alerts for new secrets, with rapid triage by security teams.

• Weekly reviews of incident dashboards, analysis of trends in secrets exposure, and feedback collection from development teams are also crucial.

• Monthly deeper dives into specific projects or teams can address recurring issues and refine configurations.

• Quarterly comprehensive audits of the secrets management program evaluate its effectiveness against evolving threats and compliance requirements.

• Finally, an annual strategic review of the overall cybersecurity compliance posture integrates new technologies and adapts policies to industry best practices in cloud security and supply chain security.

FAQ: Your Questions on Enterprise Secrets Security Answered

• Q: What is secrets sprawl and why is it a challenge for enterprises like Orange Business?

  A: Secrets sprawl refers to the uncontrolled proliferation of sensitive credentials (secrets) across numerous repositories, tools, and systems.

  For Orange Business, with over 3,000 developers, it means thousands of potential exposures annually, making comprehensive security management extremely difficult (Original Article Snippet, n.d.).

• Q: Why did Orange Business’s open-source experiment with GitLeaks fail at scale?

  A: GitLeaks generated too many false positives (e.g., 17,000 for Project Alpha) and required deep expertise for configuration, rendering results unusable for developers.

  It also lacked lifecycle management, prioritization, and clear remediation paths (Original Article Snippet, n.d.).

• Q: How did GitGuardian address the issues Orange Business faced with secrets detection?

  A: GitGuardian dramatically reduced false positives, detecting only 1 valid secret in a codebase where GitLeaks found 17,000.

  It offers 500+ secret type detectors, automated prioritization, and complete lifecycle management, making detection accurate and manageable (Original Article Snippet, n.d.).

• Q: Why is a prevention-first approach crucial for secrets security in Git?

  A: Once a secret is pushed to Git, it cannot truly be removed from the database references, making remediation very costly and often incomplete.

  Prevention, by catching secrets before they are committed, eliminates the security risk and remediation effort entirely (Original Article Snippet, n.d.).

• Q: How does Orange Business ensure developer adoption of security tools?

  A: Orange Business prioritizes developer experience by implementing tools with low false positive rates (under 5%) and using a phased rollout approach for mandatory controls.

  This builds trust, gathers feedback, and ensures developers feel like partners, not antagonists, in the security process (Original Article Snippet, n.d.).

Conclusion: Securing the Digital Supply Chain with Developer Partnership

The late-night hum of the server continues, but now, for Maya, the anxiety has largely dissipated.

Her team’s commits are cleaner, the alerts from the GitGuardian system are rare and always relevant, and the trust between security and development has deepened.

This transformation at Orange Business, spearheaded by Grégory Maitrallain, is not just a technical upgrade; it is a cultural shift.

By making security invisible to developers doing the right thing, and impossible for those who are not, they have set a new standard.

This philosophy of treating developers as partners, combined with tools that respect their workflows while enforcing critical security standards, provides a powerful model for other enterprises.

As regulatory deadlines evolve and secrets sprawl continues to grow, the organizations that succeed in securing their digital supply chain will be those that embrace this prevention-first, human-centric approach.

Let us learn from Orange Business’s compelling journey, fostering an environment where security empowers innovation, rather than hinders it.

Glossary

Secrets Sprawl:

The uncontrolled proliferation of sensitive credentials (API keys, passwords, tokens) across various development tools and systems.

Secrets Management:

The practice of securely storing, distributing, and accessing sensitive information needed by applications and services.

Shift-Left Security:

Moving security practices and testing to earlier stages of the software development lifecycle.

False Positive:

A security alert that incorrectly identifies legitimate code or activity as a threat.

Git Pre-Receive Hook:

A script that runs on a Git server before a commit is accepted, allowing for validation or rejection of pushes.

NIS 2 Directive:

An EU directive aiming to enhance cybersecurity across the European Union, including stricter requirements for secrets management and encryption.

Developer Experience (DX):

The overall experience a developer has with tools, processes, and systems, impacting productivity and adoption.

Remediation:

The process of fixing or resolving a security vulnerability or incident after it has been detected.

References

• Original Article Snippet, How Orange Business Transformed Secrets Security with a Prevention-First Approach, n.d.