TL;DR: GitGuardian is hosting an OWASP France meetup in Paris on October 5, bringing local application security practitioners together for talks, discussion, and networking, with the event framed around secrets security and the reality that stolen credentials still open too many doors. For AppSec and identity teams, the value is in treating exposed secrets as an operational governance issue, not just a cleanup task.
At a glance
What this is: GitGuardian is hosting an OWASP France meetup in Paris on October 5, focused on AppSec community discussion and the persistent problem of exposed secrets.
Why it matters: It matters because secrets exposure remains a practical access-control problem for application security, IAM, and NHI governance teams, not just a developer hygiene issue.
👉 Read GitGuardian's OWASP France meetup details for Paris on October 5
Context
OWASP France meetups bring together application security practitioners for technical talks, discussion, and networking. In this case, the event is in Paris on October 5 and is hosted at GitGuardian's Paris headquarters, which makes the security theme especially concrete because the discussion centres on secrets security and the practical realities of exposed credentials.
For identity and access teams, the underlying governance issue is familiar: stolen secrets behave like valid identities until they are found, revoked, or replaced. That makes the boundary between AppSec, IAM, and NHI management operational rather than academic, especially when service credentials, tokens, and other non-human access paths are part of the software supply chain.
Key questions
Q: How should security teams reduce risk from exposed API secrets?
A: Start by assuming any exposed API secret will be copied, shared, and reused. The most effective response is immediate revocation, reissuance, and workload scoping, followed by short-lived credentials and replay detection. Detection without automated kill-switches only tells you that the secret was found, not that the risk has been removed.
Q: Why do leaked secrets create such a large security impact?
A: A leaked secret often carries more privilege than the task actually needs, so one exposed credential can open storage, code, or operational systems at scale. The impact depends on scope, not just on exposure. That is why least privilege, limited audience, and revocation discipline matter together.
Q: What do teams get wrong about short-lived machine credentials?
A: Teams often assume that short-lived tokens eliminate machine identity risk. They do reduce active access time, but they do not remove the need to secure the client secret, standardise validation, or monitor where tokens are accepted. If those controls are weak, the lifecycle improvement does not translate into real governance.
Q: How do IAM and AppSec teams handle exposed secrets in code?
A: Treat them as credential incidents, not just code defects. Exposed secrets should trigger immediate ownership validation, revocation, and rotation, because they often function as service accounts, API keys, or tokens with real privileges. That response belongs in both AppSec and identity governance workflows.
Background and context
Why secrets security and AppSec are converging
Secrets security is the discipline of finding, controlling, and revoking credentials such as API keys, tokens, certificates, and other authentication material. In modern delivery pipelines, those secrets are often embedded in code, CI/CD variables, build systems, and runtime environments, which means application security cannot stop at code scanning alone. The real issue is identity persistence: a leaked secret is not a file problem, it is a live access path. Once it exists, any system that trusts it is exposed until the secret is rotated or invalidated.
Practical implication: treat secret discovery and revocation as part of application security operations, not a separate cleanup exercise.
How non-human identities expand the attack surface
Non-human identities include the service accounts, tokens, and keys that applications and automation use to talk to systems. They are often overused because they are easier to provision than human accounts and harder to track across teams. That creates governance blind spots when a secret appears in logs, repositories, or shared environments. The challenge is not merely exposure, but unmanaged lifecycle: ownership, rotation, scope, and offboarding are frequently weaker for machine identities than for employees.
Practical implication: map every secret to an owning workload, enforce lifecycle ownership, and remove any credential that cannot be tied to a specific runtime use.
Why community events still matter for security programmes
Security programmes often fail when they become too internal and too abstract. Practitioner meetups create a feedback loop that exposes what teams are actually seeing in production, which patterns keep repeating, and where control assumptions break down. For AppSec and IAM leads, that matters because secrets abuse is rarely solved by one team alone. The discussion has to connect detection, development workflows, access governance, and incident response across the organisation.
Practical implication: use community input to pressure-test whether your secret handling controls reflect how engineers actually build and deploy software.
NHI Mgmt Group analysis
Secrets security is now identity governance in practice: once a credential is leaked, the question is no longer whether code was scanned, but whether the organisation can locate, scope, and revoke the access path behind it. That is why secrets handling belongs in the same governance conversation as IAM and PAM. For practitioners, the control objective is to reduce the lifetime of every machine credential that can authenticate on its own.
AppSec events matter when they surface operational failure patterns: meetups are not just networking, they are a mechanism for sharing the controls that are breaking under real delivery pressure. Exposed secrets, weak ownership, and inconsistent rotation are recurring symptoms of a broader lifecycle gap. Practitioners should treat that feedback as input into programme design, not as anecdote.
Machine identity sprawl remains the hidden governance problem: application teams can create more authenticators than they can consistently govern, especially when CI/CD, cloud, and third-party integrations multiply. The result is a trust layer that outgrows manual oversight. For identity teams, the practical conclusion is that inventory and lifecycle ownership must be designed for scale, not assumed.
Community-led security discussion accelerates control alignment: when developers, AppSec leads, and identity practitioners compare notes in the same room, they expose where policy language and operational reality diverge. That gap is where secrets leakage persists. The right response is to align governance with how credentials are actually issued, used, and retired.
GitGuardian's Paris meetup highlights a named concept we see across AppSec programmes: secrets trust debt. That is the accumulation of credentials, tokens, and keys that remain trusted longer than their original use case. Once that debt builds, breach containment becomes harder because old access paths stay valid. Practitioners should aim to reduce the age and ambiguity of every secret in circulation.
What this signals
Secrets trust debt: the longer a credential survives beyond its intended use, the more it behaves like unmanaged access rather than a controlled asset. That is why teams should think about secret age, ownership, and revocation as governance signals, not just technical hygiene.
AppSec communities remain useful because they reveal how delivery teams actually handle tokens, keys, and service accounts under pressure. The most practical takeaway for readers is that secrets security must be enforced across code, pipelines, and runtime, or the same exposure patterns will keep recurring.
For practitioners
- Map every application secret to an owner Create a live inventory of API keys, tokens, certificates, and service accounts, then assign each one to a specific workload or team that can revoke it without delay.
- Set rotation and revocation triggers Define triggers for immediate secret replacement after repository exposure, staff turnover, pipeline compromise, or suspicious authentication activity.
- Bind secrets to runtime context Use short-lived credentials where possible and constrain each secret to the smallest practical environment, repository, or deployment path.
- Review logging and scanning coverage Check whether repositories, build logs, chat tools, and artifact stores are all covered by secret detection so exposed credentials are found before attackers use them.
- Use community sessions to test assumptions Bring AppSec, IAM, and platform teams together after the meetup to compare how secrets are actually created, shared, and retired in your environment.
Key takeaways
- The meetup centres on a live security problem, not a social event alone: exposed secrets still create immediate access risk when ownership and revocation are unclear.
- Application secrets behave like identities, so governance has to cover their issuance, scope, rotation, and offboarding, not just detection.
- Practitioners should treat community discussion as an input to control design, especially where AppSec and IAM responsibilities overlap.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The event theme centres on exposed secrets and stolen credentials. |
| NHI-07 — Long-Lived Secrets | The article stresses the governance problem created by credentials that outlive their intended use. | |
| Recommendation — Track secret leakage across code and pipelines, then revoke any exposed credential immediately. Replace long-lived secrets with short-lived credentials wherever the workload allows. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle control is central to the article's secrets-security focus. |
| Recommendation — Apply IA-5 to enforce rotation, replacement, and revocation for application authenticators. | ||
| CIS Controls v8 | CIS-5 — Account Management | The piece is about managing non-human access paths and their lifecycle. |
| Recommendation — Use CIS-5 to inventory and govern service accounts and other non-human access paths. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Stolen secrets are a direct credential-access threat path. |
| Recommendation — Map exposed secrets to TA0006 and prioritise detection where credentials can be harvested. | ||
Key terms
- Secrets Security: Secrets security is the discipline of discovering, protecting, rotating, and revoking credentials that grant access to systems and data. It combines inventory, policy, monitoring, and response so that exposed or overprivileged credentials do not become persistent entry points for attackers.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Authenticator Lifecycle Management: Authenticator lifecycle management is the governance of a credential from issuance to renewal, replacement, and retirement. For human identity programmes, it ensures that keys, smart cards, and certificates stay tied to the right user and are removed when the user, role, or device is no longer trusted.
What to expect at the briefing
GitGuardian's full event page covers the practical registration and logistics details this post intentionally leaves out:
- Event timing, venue details, and registration flow for the Paris meetup
- The meetup framing around secrets security and application security community discussion
- Confirmation that the session is an in-person OWASP France gathering at GitGuardian's Paris headquarters
👉 GitGuardian's full event page covers the meetup logistics and registration details.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity control to operational security decisions.
Published by the NHIMG editorial team on September 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org