52 Non-Human Identity Breaches

A Year of Research, A Wake-Up Call for the Industry

As we celebrate 52 weeks since the formation of the Non-Human Identity Management Group, we’re marking this milestone by publishing the most comprehensive and independent analysis of Non-Human Identity (NHI) breaches ever released. This updated report now includes 52 real-world breaches, up from 40 breaches just a few months ago, demonstrating the rapidly growing threat landscape surrounding NHIs.

This post is not just a retrospective, It’s a wake-up call to every organization.
You are likely sitting on a massive, unmanaged exposure stemming from Non-Human Identities such as Service Accounts, Machine Identities, API Keys, OAuth Tokens, Certificates, and Secrets.

NHIs are now the #1 attack vector leveraged by both external and internal threat actors to infiltrate systems, move laterally, and steal sensitive data. With the accelerated adoption of Cloud and SaaS platforms, organizations are facing an uncontrollable Secrets Sprawl problem, further compounded by 3rd-party and software supply chain risks, as reflected in many of the breaches outlined below.

Whether you’re a CISO, engineer, architect, or developer, this growing NHI breach dataset is a critical resource for understanding:

• How NHIs are being exploited in real-world attacks
• Why traditional IAM and secrets management are falling short
• What practical steps you can take to reduce exposure

Explore all 52 breaches, learn from real-world incidents, and benchmark your own risk posture:

How reviewdog action Exposed Thousands of Secrets?

On March 11, 2025, the reviewdog/action-setup GitHub Action became the focus of a significant supply chain attack. Malicious activity was first detected when researchers observed that the v1 tag of reviewdog/action-setup had been altered between 18:42 and 20:31 UTC, allowing attackers to inject malicious code into the tool. This modification went unnoticed for a short period, but the consequences were immediate and widespread.

How iOS Apps Are Leaking Secrets and Endangering User Privacy

In March 2025, the mobile world is buzzing after recent research uncovered a shocking truth about iOS apps: many are riddled with secret leaks, and the coding practices behind them are far from secure. With over a billion iPhones in use worldwide, these revelations raise serious concerns about the safety of personal data and the standards upheld by developers.

Cisco Data Breach – Leaks Active Directory Credentials

On 10th February 2025, the Kraken ransomware group claimed responsibility for a data breach involving Cisco Systems. They alleged that they had infiltrated Cisco’s internal network and exfiltrated sensitive credentials from the company’s Windows Active Directory (AD) environment. The leaked data included usernames, security identifiers (SIDs), and NTLM password hashes. Cisco has refuted these claims, asserting that the data in question originates from a previously addressed incident in May 2022.

Salt Typhoon Used Cisco Flaw & Stolen Credentials to Hack U.S. Telecoms 

In February 2025, Cisco Talos reported that the advanced persistent threat (APT) group known as Salt Typhoon, believed to be linked to China’s Ministry of State Security (MSS) or Guoanbu, managed to infiltrate several U.S. telecommunications networks. Shockingly, some of these intrusions went unnoticed for more than three years. The attackers took advantage of an old but still unpatched vulnerability in Cisco’s Smart Install feature, known as CVE-2018-0171, while also leveraging stolen credentials to deepen their access. Their approach combined stealth and persistence, making detection incredibly difficult until significant damage had already been done.

OmniGPT Breach

In February 2025, a significant data breach involving OmniGPT, a widely-used AI-powered chatbot platform, was reported. A threat actor known as “Gloomer” claimed responsibility for the breach, alleging the exposure of sensitive user information, including email addresses, phone numbers, API keys, and extensive chat logs. This report delves into the specifics of the breach, examines the potential vulnerabilities exploited, assesses the impact, and offers recommendations to prevent similar incidents in the future.

How ASP.NET Machine Keys Triggered Remote Code Execution Attacks

On February 6, 2025, Microsoft revealed a major security issue involving over 3,000 publicly exposed ASP.NET machine keys. These keys, meant to protect web applications, had been inadvertently shared in public repositories, creating a significant risk of remote code execution (RCE) attacks. Exploiting these exposed machine keys, attackers took advantage of the ASP.NET ViewState mechanism to inject and execute arbitrary code on
vulnerable servers.

Zacks Breach

In February 2025, the cybersecurity world faced yet another wake-up call, this time, the target was Zacks Investment Research, a well-known investment analysis firm. A hacker, going by the alias “Jurak,” claimed responsibility for leaking sensitive data belonging to 12 million Zacks customers. This breach has left millions exposed to serious risks like identity theft, credential stuffing, and financial fraud. But what’s even more alarming is that this isn’t the first time Zacks has fumbled the ball when it comes to data security.

AWS S3 Buckets Under Attack

In January 2025, the ransomware group “Codefinger” has exploited Amazon Web Services (AWS) to launch a sophisticated campaign targeting Simple Storage Service (S3) buckets. Using compromised AWS credentials, the attackers leveraged AWS’s Server-Side Encryption with Customer Provided Keys (SSE-C) to encrypt stored data. This innovative use of legitimate AWS features complicates detection and remediation, underscoring the importance of robust cloud security practices.

DeepSeek Breach

On January 29, 2025, a major security breach involving DeepSeek, a prominent Chinese artificial intelligence (AI) startup, was reported. The breach resulted in the exposure of over one million log lines and highly sensitive secret keys. This exposure has triggered serious concerns about the security of AI systems, the integrity of the data involved, and the broader implications for both organizations and industries relying on AI.

Secrets Exposure Via Azure Key Vault Role

In December 2024, Researchers identified a potential privilege escalation vector in Azure Key Vault. The issue arises from the misconfiguration of the permissions associated with the “Key Vault Contributor” role. While this role is documented to allow management of key vaults without granting data access, it includes the Microsoft.KeyVault/vaults/write permission. This permission enables users to modify access policies, effectively allowing them to grant themselves or others full access to the key vault’s data.

Microsoft Azure OpenAI Service Breach

In December 2024, Microsoft took decisive legal action against a Hacking-as-a-Service (HaaS) platform that exploited vulnerabilities in its Azure OpenAI services. The cybercriminals behind this scheme were using stolen Azure API Keys and custom-developed software to bypass AI safety measures, enabling them to generate harmful content, including illegal materials, at scale. This breach highlights the growing sophistication of cybercriminal activities leveraging AI, as well as the critical need for stronger safeguards in the rapidly evolving landscape of generative AI services.

BeyondTrust Breach 

On December 2, 2024, BeyondTrust, a leading cybersecurity solutions provider specializing in Privileged Access Management (PAM) and Secure Remote Access, identified anomalous activities affecting certain customer instances of its Remote Support Software-as-a-Service (SaaS) platform. Following an in-depth investigation, it was revealed that a compromised API key had been exploited, leading to unauthorized access and the potential for escalated attacks on affected customer environments.

Schneider Electric Breach

In November 2024, Schneider Electric, confirmed a significant cybersecurity incident including unauthorized access to its internal project management system. The attacker exploited exposed credentials to gain access to Schneider Electric’s Jira server to extract a 40GB of sensitive data.

AI LLM Hijack Breach

In October 2024, Permiso Security reported attackers were hijacking LLM models on cloud infrastructure to run rogue chatbot services. Threat actors leveraged AWS access keys to hijack Anthropic models provided by AWS Bedrock, for Dark Roleplaying.

Emerald Whale Breach

In October 2024, a significant cybersecurity incident known as Emerald Whale shocked the DevOps community. This incident revolved around exposed Git configuration files, an apparently simple misconfiguration that resulted in the theft of over 15,000 sensitive data and unauthorized access to over 10,000 private repositories.

The Internet Archive Breach

In October 2024, the Internet Archive fell victim to a major data breach affecting 31 million user accounts. Unsecured authentication tokens in their GitLab repository, which were left accessible for almost two years, were the cause of this incident. Threat actors exploited these tokens to gain access to critical systems, databases, and user data.

Cisco Breach

In October 2024, Cisco experienced a significant cybersecurity breach related to Non-Human Identities (NHIs). The threat actor ‘IntelBroker’ exploited exposed credentials, API tokens, and keys located in DevHub, Cisco’s public development environment.

CI/CD Pipeline Exploitation

In September 2024, a security researcher recently demonstrated how a series of flaws in a CI/CD environment resulted in a full server takeover. The attack started with an exposed .git directory, progressed through mismanaged CI/CD pipeline configurations and ended up with unauthorized server access.

230 Million AWS Cloud Environments Compromised

In August 2024, many organizations fell victim to a recent large scale extortion campaign targeted improperly configured cloud environments. Attackers exploited unsecure environment variable files (.env) in these environments.

Hugging Face Breach

In June 2024, Hugging Face, which is considered as a leading company and AI platform, announced a security breach targeting its Spaces Platform. The incident included unauthorized access to authentication secrets (API keys and tokens), which could lead to the compromise of sensitive data and disrupt workflows.

The New York Times Breach

In June 2024, the New York Times (NYT), a media powerhouse known for its reporting excellence, became the subject of headlines for an entirely different reason: a significant cybersecurity breach.

GitLocker Breach

In June 2024, GitHub users fell victim to an extortion campaign targeting their repositories. The threat actor gained unauthorized access to GitHub accounts using stolen credentials that seemed to be acquired from previous breaches.

Snowflake Breach

In May 2024, Snowflake fell victim to a major cybersecurity breach in May 2024. The breach compromised data from major organizations, including Ticketmaster and Santander Bank, highlighting the weaknesses in cloud environments when it lacks efficient security measures.

Dropbox Sign Breach

In May 2024, Dropbox Sign experienced a significant security breach. Attackers exploited compromised backend service account which granted them the ability to access the customers database which led to the exposure of sensitive user data, including email addresses, usernames, hashed passwords, and account authentication details like API keys and OAuth tokens.

JetBrains Breach

In May 2024, a critical vulnerability (CVE-2024-37051) with a CVSS score of 9.3, was reported in JetBrains’ GitHub plugin for IntelliJ-based IDEs. This vulnerability exposed GitHub access tokens to malicious third parties.

Sisense Breach

In April 2024, Sisense reported a security breach from unauthorized access to Sisense’s self-managed GitLab Instance, which led to the exfiltration of huge amounts of data, including access tokens, API keys, passwords, and certificates.

Google Firebase Breach

In March 2024, security researchers discovered that misconfigurations in Google Firebase instances had exposed over 19.8 million secrets. Google Firebase is a popular Backend-as-a-Service (BaaS) platform used by developers to manage databases, storage, and authentication for their applications.

Microsoft Midnight Blizzard Breach

In January 2024, Microsoft detected a cyberattack planned by the Russian state-sponsored group Midnight Blizzard (also known as Nobelium or APT29). The attacker exploited a legacy, non-production test tenant account without multi-factor authentication (MFA).

SAP Breach

In November 2023, SAP, a global software giant, made headlines after researchers discovered that over 95 million artefacts including sensitive Kubernetes secrets were exposed through public GitHub repositories and misconfigured systems.

PyPI Breach

In November 2023, a significant security incident was uncovered involving the exposure of thousands of hardcoded secrets in packages hosted on the Python Package Index (PyPI). This incident revealed that thousands of PyPI packages contained hardcoded secrets, such as API keys, database credentials, and authentication tokens.

Sumo Logic Breach

In November 2023, Sumo Logic detected unauthorized access to one of its AWS accounts. Investigations revealed that the attackers used compromised credentials to gain access to the AWS account.

Cloudflare Breach

In November 2023, Cloudflare disclosed a significant breach involving their internal Atlassian systems. The intrusion occurred after attackers used credentials stolen during the October 2023 Okta breach.

Okta Breach

In October 2023, Okta, a leader in identity and access management (IAM), suffered a supply chain breach that exploited a compromised service account.

JumpCloud Breach

In July 2023, JumpCloud, a well-known directory-as-a-service provider, made headlines by invalidating all administrator API keys in response to a suspected security breach. This move impacted thousands of organizations globally.

GitHub Dependabot Breach

In July 2023, a sophisticated cyberattack shook the developer community, targeting GitHub repositories at an unprecedented scale. Threat actors exploited stolen GitHub personal access tokens to inject malicious code into hundreds of repositories, masquerading the commits as legitimate contributions by Dependabot, a widely used automated dependency management tool.

Microsoft Azure Key Breach

In June 2023, Microsoft experienced a major security breach that left many businesses and government agencies vulnerable. The breach, dubbed the Azure Key Breach, exposed a key security flaw in how Microsoft managed cryptographic keys used to validate access to its services, including Azure Active Directory (AAD) and Exchange Online.

Microsoft SAS Key Breach

In June 2023, Microsoft AI researchers inadvertently exposed 38TB of sensitive internal data while publishing open-source training materials on GitHub. The data included private keys, passwords, internal Teams messages, and backups of two employee workstations. The breach resulted from a misconfigured Azure Shared Access Signature (SAS) token used to share files.

Poland’s Military Breach

In May 2023, a significant cybersecurity incident exposed sensitive Polish military data through a forgotten, outdated password. The issue began when login credentials to a mapping database (ArcGIS) were shared in a 2020 email.

Twitter Breach

In March 2023, Twitter faced a significant cybersecurity breach when its source code was leaked on GitHub by an unknown user, identified as “FreeSpeechEnthusiast”.

T-Mobile Breach

In January 2023, TT-Mobile reported a data breach affecting 37 million accounts. The breach, caused by a vulnerable Application Programming Interface (API), exposed customer data over nearly six weeks.

CircleCI Breach

In January 2023, CircleCI (CI/CD) platform fell victim to a major security breach. The breach was detected when CircleCI was alerted to suspicious GitHub OAuth activity by one of their customers.

Slack GitHub Breach

In January 2023, Slack a leading collaboration platform, experienced a security breach involving the unauthorized access of private code repositories hosted on GitHub.

GitHub Personal Account Breach

On December 6, 2022, GitHub identified a security breach where an unauthorized actor accessed repositories from GitHub Desktop, Atom, and other deprecated GitHub-owned organizations. The breach occurred due to the compromise of a Personal Access Token (PAT) associated with a machine account.

Toyota Breach

In October 2022, Toyota disclosed a data breach resulting from a misconfigured public GitHub repository that had unknowingly exposed a hardcoded access key for five years.

Microsoft OAuth Breach

In September 2022, Microsoft disabled compromised verified partner accounts exploited by attackers to conduct OAuth phishing campaigns.

Uber Breach

On September 15, 2022, Uber Technologies Inc. faced a significant cybersecurity breach that exposed vulnerabilities within its internal systems, involving lateral movement across multiple systems.

MailChimp Breach

In April 2022, Mailchimp confirmed that attackers gained unauthorized access to an internal customer support and account administration tool. This breach affected approximately 133 customers.

GitHub Repo Breach

In April 2022, attackers exploited stolen OAuth tokens issued by third-party integrators Heroku and Travis CI to gain unauthorized access to GitHub repositories.

Twitch Breach

In October 2021, Twitch, the popular live streaming platform, suffered a significant data breach, that exposed a significant portion of its internal source code. The leak included 200GB of data, which attackers made public, including credentials, secrets, API keys, and even configuration files.

Codecov Breach

In April 2021, a supply chain attack targeted Codecov, a popular tool for measuring code coverage in software projects. The breach exploited a vulnerability in Codecov’s infrastructure, leading to the compromise of its Bash Uploader script.

The Indian Government Breach

In March 2021, the Sakura Samurai, an ethical hacking group, conducted a responsible vulnerability disclosure campaign. They used various reconnaissance and exploitation techniques to expose significant flaws in the cybersecurity defences of several Indian government organizations.

United Nations Breach

In January 2021, The United Nations data breach exposed the shocking reality that even the most high-profile organizations of the world may be blind to some pretty simple but catastrophic cybersecurity oversights.

Are you concerned about NHI Risks within your organisation ?

Our NHI Mgmt Group is the market leading research and advisory firm in the Non-Human Identity space. We provide independent guidance and advice for clients looking to manage the risks around Non-Human Identities

• Our team has been advising, establishing and managing global regulatory IAM / NHI programs for over 25 years at major financial institutions.
• We have the most comprehensive Knowledge Centre on NHIs including foundational Articles on NHIs, Industry White-Papers, Major Breaches, Research Reports, Blogs, Educational Videos, Industry Surveys, Newsletters as well as details of Products that support the risk management of NHIs.
• Our NHI Mgmt Group was founded by an IAM Industry Veteran, who has managed global regulatory NHI programs, author of major White-Papers and Research articles on NHIs, established the thriving NHI LinkedIn Community Group and recognised as the #1 NHI Evangelist / Voice in the industry.

Contact us if you would like to get some independent guidance and advice on how to start tackling Non-Human Identity Risks.

Note – we sourced the initial reporting of these breaches from a number of places including Bleeping Computer, Security Week, Astrix Security, GitGuardian, Oasis Security, Entro Security, Permiso Security, Aembit.

AI Agents And Their Intersection with Non-Human Identities

Introduction

Artificial intelligence (AI) has become an essential part of today’s digital environments, driving advancements in automation, decision-making, and operational efficiency across various industries. One particularly fascinating development is the intersection of Non-Human Identities (NHIs), digital entities used by AI Agents that take on roles traditionally handled by humans. While these AI-driven NHIs unlock remarkable opportunities for innovation, they also introduce distinct security risks and challenges.

In this report, we’ll break down the technical mechanisms of AI agents within NHIs and explore the cybersecurity threats they pose. We’ll also discuss strategies for mitigating these risks, as NHIs continue to become a more integral part of everyday systems.

Understanding Non-Human Identities (NHIs)

What are NHIs?

Non-Human Identities (NHIs) are digital entities or software-based actors that operate autonomously or semi-autonomously within a system. They perform tasks, make decisions, and interact with other digital or human entities. Unlike traditional software, NHIs are typically used by AI agents, enabling them to display behaviour that might seem intelligent or human-like, even though they lack consciousness.

NHIs can be used in various forms, including:

• Autonomous Agents: These are AI-driven entities capable of perceiving their surroundings, analysing data, and making decisions on their own. For example, a financial AI algorithm that independently conducts stock trades based on market trends is an example of an autonomous agent.
• Digital Twins: These virtual replicas that mirror the behaviour of physical objects, processes, or systems. AI-powered digital twins are used in industries like manufacturing, healthcare, and urban planning to model, analyse, and predict the behaviour of real-world counterparts
• Synthetic Personas: AI-generated personas interact with humans on platforms like social media, customer service, or e-commerce. They simulate human behaviour using natural language processing (NLP) and machine learning technologies.
• AI-Driven IoT Devices: Internet of Things (IoT) devices, such as drones, robots, or smart home systems, are part of the NHI ecosystem. They operate autonomously and communicate with other entities by leveraging real-time data.

AI Agents using NHIs

AI agents are entities that operate in an environment and perform actions autonomously to achieve predefined goals. AI agents may use various forms of machine learning (ML) and deep learning (DL) techniques to improve their decision-making capabilities over time. Their functioning can be categorized as follows:

1 – Perception: The AI agent collects data from the environment via sensors, data streams, or external APIs. For example, an AI agent managing an autonomous vehicle processes real-time sensor data (e.g., from LIDAR or cameras) to understand the driving environment.

2 – Decision-Making: After perceiving the environment, the AI agent processes the data using decision-making models (e.g., neural networks, reinforcement learning, etc.). The agent determines the best action by predicting outcomes based on historical data and predefined reward functions.

3 – Action: Finally, the AI agent executes the action by sending control commands to devices, initiating communication with other agents, or updating system states. In autonomous trading, the AI agent could initiate a buy/sell order based on its evaluation of the market.

Threats Posed by AI Agents using NHIs

AI agents’ autonomy and decision-making capabilities, while beneficial, introduce numerous threats to the integrity, privacy, and security of the systems they operate within.

1 – Unauthorized Identity Access and Manipulation – AI agents using NHIs often have access to sensitive data and critical system controls. If these agents are compromised, attackers can gain unauthorized control over the NHI, allowing them to manipulate decisions or impersonate the entity in malicious ways. Such attacks can involve:

• Hijacking of Control Systems: Attackers may exploit vulnerabilities to hijack AI agents controlling industrial machines, leading to operational disruptions or safety risks.
• Identity Spoofing: Attackers can impersonate an AI-driven NHI, such as a digital persona or chatbot, to deceive users or steal credentials in social engineering attacks.

2 – Adversarial Attacks on AI Models – One of the most deceptive and harmful types of attacks targeting AI agents is the adversarial attack. In this scenario, attackers create malicious inputs specifically designed to confuse the AI model. Compromising NHIs, adversarial attacker can manipulate AI agents into making flawed or incorrect decisions, such as:

• Data Poisoning: Introducing malicious or tampered data into the training process of AI models, corrupting the agent’s learning and future behaviour.
• Model Evasion: Crafting inputs that cause AI agents to misclassify data or fail at their tasks. For instance, in autonomous driving, an adversarial attack might trick the AI into misinterpreting a stop sign, causing a vehicle to ignore traffic rules.

3 – Data Privacy and Security Risks – AI agents using NHIs often process personal or sensitive data, which makes them prime targets for data breaches. Threat actors may exploit vulnerabilities in the system to access confidential information, including financial records, medical data, or proprietary algorithms.

• Inference Attacks: Attackers can analyse the output of AI agents to infer private details about individuals or entities, even when direct access to the data is restricted.
• Data Exfiltration: AI-driven NHIs are also at risk of data leakage, where attackers infiltrate systems and steal sensitive information without detection.

4 – AI Autonomy Risks – The autonomy granted to AI agents, while improving efficiency, creates risks when AI-driven NHIs make unintended or harmful decisions due to incomplete data, unforeseen conditions, or model flaws. Examples include:

• Autonomous Vehicles: AI agents controlling self-driving cars could misinterpret their environment due to unexpected stimuli or sensor errors, leading to dangerous outcomes.
• AI in Healthcare: Medical NHIs could misdiagnose conditions or recommend inappropriate treatments due to flawed AI models.

Mitigation Strategies for AI Threats and NHIs

To secure NHIs from these threats, a range of technical and policy-driven mitigation strategies must be adopted.

1 – Secure AI Model Development

• Adversarial Training: AI models should be trained using adversarial examples to enhance their robustness against malicious inputs. Techniques like robust optimization and randomization can also strengthen AI agents against adversarial attacks.
• Regular Model Audits: Continuous testing and auditing of AI models can help identify and rectify vulnerabilities in AI decision-making. Security teams should run periodic evaluations to check for bias, unintended behaviours, and security flaws.

2 – Implementation of Strong Access Control

• Multi-Factor Authentication (MFA): To prevent unauthorized access, AI agents and NHIs should be secured with strong authentication mechanisms, including MFA. This is critical in preventing attackers from gaining control of sensitive NHIs.
• Role-Based Access Control (RBAC): Only authorized users or agents should have access to critical AI functions or sensitive data. Implementing RBAC ensures that access is restricted to trusted parties based on the principle of least privilege.

3 – Zero Standing Privileges

• Transition to a Zero-Trust model by moving away from static secrets to Just-In-Time (JIT) ephemeral secrets making it much hard for a threat actor to compromise NHIs.

4 – Data Privacy Compliance

• Data Encryption: Sensitive data processed by AI agents must be encrypted both in transit and at rest. This ensures that even if an attacker gains access to the data, it remains unusable without the decryption keys.
• Differential Privacy: AI models should be designed with differential privacy, ensuring that individual data points cannot be reverse engineered from the model’s outputs.

5 – Continuous Monitoring and Incident Response

• Anomaly Detection Systems: Deploying anomaly detection systems powered by machine learning can help identify deviations in AI agent behaviour, indicating any potential security incidents or adversarial attacks.
• AI Forensics: In the event of an attack or system failure, AI forensics should be used to understand the cause and assess the impact of the incident. Forensic tools must be tailored to trace AI decision-making processes.

Conclusion

As AI agents become the driving force behind using Non-Human Identities (NHIs), it is essential to recognize the unique threats they pose to security and privacy. From adversarial attacks to ethical concerns, the risks associated with AI-powered NHIs can be substantial if not properly managed.

However, by adopting robust AI model development practices, enforcing strict access controls, a zero trust model using ephemeral secrets and ensuring data privacy and compliance, organizations can mitigate these threats and unlock the full potential of NHIs in a secure and ethical manner.

The future of AI-driven NHIs will undoubtedly transform industries and redefine the digital ecosystem, but addressing their inherent security challenges is critical to their long-term success.

GDPR Fines Hit EUR 1.2Bn in 2024 – 363 Data Breaches Per Day

GDPR Fines Hit 1.2Bn in 2024 – Average Of 363 Data Breaches Per Day

• GDPR fines hit 1.2Bn EUR in 2024, with 8.3% more breach reports in 2024.
• An average of 363 data breach notifications per day vs 335 in 2023.

Whilst no doubt some of these breaches will have been caused by the compromise of Non-Human Identities (NHIs), a key area that the DLA Piper Survey Report calls out is around AI Enforcement, which clearly will have big implications from Non-Human Identity management/security intersection standpoint. Read our blog post on “AI Agents and Their Intersection with Non-Human Identities“.

Commenting on the survey findings, Ross McKean, Chair of the UK Data, Privacy and Cybersecurity practice said:

“European regulators have signalled a more assertive approach to enforcement during 2024 to ensure that AI training, deployment and use remains within the guard rails of the GDPR.”

Here’s a summary of the key headlines from the DLA Piper’s GDPR Fines and Data Breach Survey.

Key Headlines :

1. GDPR Enforcement in 2024:
   • €1.2 billion in fines issued across Europe, marking a significant year in data privacy enforcement.
   • Ireland continues to be the top enforcer with €3.5 billion in fines since May 2018.
2. Decrease in Fines Compared to 2023:
   • 33% decrease in fines compared to the previous year.
   • No record-breaking fines in 2024.
3. Big Tech and Social Media:
   • Primary targets for fines with major penalties against LinkedIn (€310 million) and Meta (€251 million).
4. Expansion to Other Sectors:
   • Enforcement expanded to financial services and energy sectors.
   • Notable fines issued against a large bank (€6.2 million) and a utility provider (€5 million).
5. UK’s Unique Approach:
   • Very few fines issued in the UK in 2024.
   • UK Information Commissioner suggests fines are not the most effective enforcement tool.
6. Personal Liability:
   • Focus on governance and oversight.
   • Investigation into holding Clearview AI’s directors personally liable for GDPR breaches.
7. Data Breach Notifications:
   • Slight increase in the average number of breach notifications per day (363).
   • Netherlands, Germany, and Poland remain top countries for data breach notifications.
8. AI Enforcement:
   • Increased scrutiny on AI technologies for GDPR compliance.
   • European regulators assert a stronger enforcement approach.

If you are interested in Non-Human Identities and their intersection with GenAI read our blog post on “AI Agents and Their Intersection with Non-Human Identities“.

The OWASP Non-Human Identity Top 10

Oasis Security – The OWASP Non-Human Identity Top 10: A Strategic Imperative for 2025

Non-human identities (NHIs), such as service accounts, API keys, and IAM roles, have become fundamental to modern enterprise environments, enabling machine-to-machine access and authentication. However, as organizations embrace cloud-native architectures, microservices, third-party integrations, and, more recently, AI, the proliferation of NHIs has outpaced security controls, significantly expanding the attack surface that adversaries actively exploit.

Despite their importance, NHIs often lack the same level of governance, visibility, and protection as human identities. Mismanagement, overprivileged access, long-lived secrets, and improper offboarding have made them prime targets for breaches, ransomware attacks, and supply chain compromises.

To address this growing risk, the OWASP (Open Web Application Security Project) Non-Human Identity Top 10 provides a structured framework for organizations to identify, prioritize, and mitigate the most pressing security risks associated with NHIs. As we approach 2025, securing NHIs is no longer optional but a strategic imperative. This guide serves as a roadmap for security professionals, helping them implement proactive security measures to reduce risk and protect enterprise systems from evolving threats.

Understanding OWASP NHI Top 10

The OWASP NHI Top 10 is a curated list of the most prevalent and impactful security threats affecting non-human identities in modern applications. Cybercriminals increasingly target these identities due to their privileged access and lack of human oversight.

Built on extensive research, real-world threat intelligence, and attack data, this list serves as a critical reference for security leaders, developers, and IAM teams working to secure machine-to-machine access and authentication across hybrid environments.

Key Takeaways for Organizations

1. Enhanced Awareness: Educating teams on the risks of non-human identities fosters a proactive security culture.

2. Risk-Based Prioritization: Allocating resources effectively by first addressing the most critical threats improves defences.

3. Regulatory Compliance: Aligning with OWASP recommendations helps meet industry standards and legal requirements.

4. Proactive Defence Strategies: Implementing robust identity governance, access controls, and continuous monitoring reduces the risk of exploitation.

The OWASP NHI Top 10 Security Risks

The OWASP NHI Top 10 identifies the most critical security risks related to non-human identities. These include:

● NHI1:2025 – Improper Offboarding: NHIs not properly deactivated or removed remain active beyond their intended use, creating persistent security gaps. Attackers exploit these to compromise critical systems, exfiltrate data, and maintain long-term persistence.

● NHI2:2025 – Secret Leakage: When secrets containing high-impact credentials are leaked, they significantly increase the risk of a severe breach.

● NHI3:2025 – Vulnerable Third-Party NHI: Third-party applications that access sensitive data can be compromised, leading to supply chain attacks, data theft, and critical system failures.

● NHI4:2025 – Insecure Authentication: Insecure protocols used for sensitive, high-access processes can lead to account takeover or privilege escalation.

● NHI5:2025 – Overprivileged NHI: Due to their extensive range of associated privileges, overprivileged non-human identities can have a significant negative impact.

● NHI6:2025 – Insecure Cloud Deployment Configurations: CI/CD misconfigurations enable supply chain attacks and unauthorized access due to high pipeline privileges.

● NHI7:2025 – Long-Lived Secrets: Long-lived secrets are common due to rotation challenges and the lack of ephemeral solutions. Most secret managers track rotation time, making detection easy.

● NHI8:2025 – Environment Isolation: NHIs are often used during deployment and throughout an application’s lifecycle. However, reusing the same NHIs across multiple environments, especially between testing and production, can introduce significant security vulnerabilities.

● NHI9:2025 – NHI Reuse: NHIs are very commonly reused because tailor-fitting NHI for each workload is difficult.

● NHI10:2025 – Human Use of NHI: Most NHI providers do not provide tooling to differentiate between workloads assuming the NHI and humans assuming the NHI.

Solving the problem of NHIs

As organizations scale their digital ecosystems, they must gain comprehensive visibility into these NHIs across their infrastructure. Robust security measures are essential to protect sensitive data and systems, prevent unauthorized access, and minimize misuse. Additionally, governance capabilities ensure compliance with industry regulations and internal policies, helping safeguard digital assets while minimizing the risk of data breaches.

Automating Identity Discovery and Context

One of the biggest challenges organizations face is identifying, mapping, and contextualizing NHIs across their infrastructure. Businesses need a solution that continuously scans and correlates NHIs, including service accounts on-prem, IAM roles in AWS, and service principles in Azure. By reconstructing identity context, businesses gain actionable intelligence on ownership, usage patterns, and risk exposure.

Advanced Threat Detection and Response

Organizations should deploy AI-driven analytics and behavioural monitoring to detect anomalies in NHI activity. By continuously analysing machine identity behaviours, you can flag unusual patterns that may indicate compromised credentials, insider threats, or privilege abuse. With real-time alerts and automated response actions, organizations can contain incidents before they escalate.

Enforcing Least Privilege Access

A solution should enforce policy-driven, least-privilege access for NHIs through dynamic access controls and just-in-time privilege escalation. This ensures that non-human identities only have the minimum permissions required for their function, reducing the risk of malicious actors exploiting overprivileged NHIs.

Policy-Driven Governance

By automating security policies and compliance frameworks, you can ensure that only authorized NHIs have access to critical resources. This minimizes the risk of privilege escalation, credential misuse, and compliance violations, allowing organizations to enforce security at scale without relying on manual intervention.

Conclusion

Oasis Security is at the forefront of solving the challenges associated with non-human identities. It provides a purpose-built platform that automates the discovery, security, and governance of NHIs across enterprise environments. Unlike legacy identity solutions that struggle with NHI governance, Oasis Security provides continuous discovery, contextual understanding, and dynamic privilege enforcement, ensuring real-time protection.

The cloud has a serious and fragile vulnerability: Access Tokens

TrustFour – The cloud has a serious and fragile vulnerability: Access Tokens

The October 2023 OKTA support system attack that so far has publicly involved Cloudflare, 1Password and BeyondTrust informs us just how fragile and vulnerable our cloud applications are because they are built using access tokens to authenticate counterparties.

If a valid access token is stolen by a threat actor, most systems don’t have the internal defenses built-in to detect that a valid token is now being used by a threat actor, leaving them completely vulnerable. To be clear, reliance on access tokens to authenticate counter parties, is NOT unique to Okta and could happen to any of a myriad of cloud services to application functionality such as email, CRM, accounting/finance are just some examples.

What are access tokens and why do they make our cloud infrastructure and applications so vulnerable? Simple, they are what is known as a bearer token, which means that if you possess the token you have the access rights granted to the original possessor of the token. By design the recipient is required to check if the token is still valid and if so, grants access.

Because of their power, access tokens must be protected at all costs from theft. There are four key aspects to protecting tokens:

1. Always keep them in memory, secured (no persistent storage);
2. Always transport them over a secure channel (should be mutually authenticated)
3. Keep their lifetimes as short as possible (minutes for sensitive access rights)
4. Ensure they are only accepted from known and expected sources (security groups, privacy groups, segmentation)

Deviate from these simple rules and applications (cloud, hybrid and classical) that rely on access tokens are extremely vulnerable.

Looping back to the recent Okta breach, it boils down to stolen access tokens due to 3 out of the 4 rules being breached. The only rule that wasn’t fully breached was number 2, which by public reporting does not appear to have been a mutually authenticated connection.

What is an access token?

Think of an access token being similar to a ticket used to get into a sporting event with some notable differences Presenting a valid sporting ticket to a stadium gate agent allows you to enter the venue (authentication). Once inside the stadium gate, you go to your section, row and seat for that ticket (scope/authorization).

Access tokens, technically called OAUTH tokens, work like tickets with two notable differences: reuse and copy protection.

• Reuse: Sporting tickets can only be used once for a specific event. Access tokens are reusable until they expire or are revoked.
• Copy protection: Sporting tickets have copy protection controls such as holograms on physical tickets or cryptographic tying of electronic tickets to a specific phone. Access tokens have no copy controls built into them and instead rely on the rules defined above.

How are access tokens generated and used?

Without getting down into the weeds of how modern Identity Providers (IDPs) and protocols work, the answer is fairly simple in that an Agent (human or system) presents credentials to an IDP and requests access tokens to a resource (e.g. system, application, database, etc,..). The credentials presented to the IDP can be a username/password augmented with multi-factor authentication, a certificate or other types of secrets. If successfully authenticated, the IDP sends the Agent an access token. To protect access tokens, they should only be sent over properly encrypted channels with the valid time period set as short as possible, though the downside to short time durations means the Agent has to re-authenticate to the IDP more often..

Once an Agent has their access tokens, they present them to resources to gain access. The resource validates the tokens with the IDP to see if they have been revoked or expired and if not, grants access based on the authorization rights associated with the Agent.

How do you protect access tokens?

Given how powerful access tokens are, they must be protected at all costs.

Going back to the four methods of protection listed earlier, the first order of business is to never persistently store access tokens. Avoiding persistent storage greatly reduces the attack surface of a threat actor to get a copy of a token. As a side note, ensuring that the original credentials presented to the IDP get the access tokens in the first place should also not be persisted as well. Instead, applications should make use of Key Management Services or Vaults.

The second task is to ensure that tokens are always sent over secure channels which in the majority of cases means using Transport Layer Security (TLS), Using TLS versions older than V1.2 should be avoided as these are no longer considered secure and have been deprecated.

TLS has two modes of operation: One-way (most common) and mutual.

With one-way TLS the channel has only data privacy and data integrity but misses out on authentication due to the fact that only the server providing the resource has a certificate. While many human based use cases can be sufficiently secured using one-way-TLS due to the fact that a human can be asked for additional authentication factors by the IDP as a part of the initial IDP login, it usually leaves open vulnerabilities for machine-to-machine connections where mutual TLS should be used as it serves as a critical second factor for authentication.

Ideally mutual TLS (mTLS) connections should be used, whereby both sides of the connection mutually authenticate each other at the transport layer using certificates or even pre-shared-keys which acts as an additional authentication factor. The use of mTLS ensures the Agent is authenticated with the server to validate that connections are only coming from valid and known sources as opposed to a threat actor’s machine armed with a stolen access token.

The third task is to ensure access tokens have as short a lifetime as possible such that if they are stolen, their useful lifetime is limited. For human Agents, this translates to having to re-authenticate with the IDP, so many of these use cases tend to have lifetimes set in hours or days. For machine based Agents, the lifetime should be set as short as possible without putting unnecessary burden on the IDP. Often this translates to 15 to 60 minutes.

The four task is to ensure that some means of restricting who can connect to servers (defense-in-depth) is vital in that this serves a very significant hurdle to overcome should an access token be stolen. Servers that require all connections to be mTLS based protects itself with a critical second factor ensuring that only authenticated connections can be used to send access tokens. This second factor significantly reduces the attack surface in which access tokens can be abused. Using mTLS combined with cloud privacy or network security groups or layer 3 segmentation solutions go even further with their defense-in-depth attack surface reductions.

Conclusion

Applications and infrastructure must ensure they adhere to solid code and implementation practices such as the ones described in this blog when access tokens are used as the center of the authentication strategy. Best practice of short expirations, never persisting tokens and using mTLS for all connections combined with network capabilities such as network or privacy groups or segmentation are all required to ensure sufficient defense-in-depth protective controls are in place.

Human Identity & NHI Must Be Addressed Together

Karen Crowley, Andromeda

Andromeda – CISO Alert: Human Identity and NHI Must Be Addressed Together

After last week’s Gartner’s 2024 IAM Summit, the importance of Identity Security can not be underestimated. It is also evident that while NHI is a hot topic, human identity remains unresolved, and we must address these issues together.

Gartner considers identity-centric security a top priority for 2025. The main conditions that have led to this focus include:

• A significant increase in Identity-related breaches due to identity sprawl
• The deterioration of traditional security boundaries from cloud and SaaS adoption
• The exponential growth of digital entities resulting in excessive privileges from over-permissioned human & non-human (NHI) identities

Human risk and NHI remain equally unsolved

The recent hype around NHI has thrown fuel on the fire. Recent estimates suggest that each human user has between 10 to 50 NHI. This year’s major identity security incidents include the AWS ransomware incident and Snowflake breach, just a few of the many attacks this year.

The pervading notion that NHI should be the sole focus is flawed, as human risk remains an equally unresolved issue for identity security teams.

• Excessive permissions for human identities in the cloud continue to plague organizations
• The manual provisioning, deprovisioning, and compliance of human identities are still a significant concern

The goal: Reduce Risk

The root cause of the cloud identity security problem is the rapid pace of change and lack of visibility into permissions. In fact, 95% of cloud identities, both human and NHI, have been deemed overprivileged.

At the end of the day, the goal is to reduce the blast risk because a compromised identity, human or NHI, should not equal a breach.

Lifecycle Management: NHI are tied to the lifecycle of a human identity

A human user’s risk is tied to its identity posture and permissions, as well as the posture and permissions of all NHIs they own. To reduce the blast radius of an identity compromise, you must manage the risk and lifecycle of human identity and NHI together.

While NHIs operate autonomously, they require continuous management and must be tied to a human identity for accountability and compliance.

• When a human user leaves the organization, you must either delete, rekey, and/or reassign the NHI to a different owner.
• NHIs can be created automatically and need to be assigned human owners, as orphaned NHIs are a target for exploitation.
• Without a designated human owner, NHI can accumulate excessive or outdated permissions. To achieve the least privilege, permissions must be rightsized across humans and NHI.

Human owners play a critical role in NHI management, reducing operational impacts and proving compliance. They are essential for key rotations, proper permissions, identity lifecycles, and access reviews.

Zero Trust Requires a Holistic Approach Human Identity and NHI

Ultimately, both human identities and NHI will be compromised, and it is crucial to limit your exposure when (not if) it happens.

To reduce complexity stemming from fragmented data and solutions, human identity and NHI must be addressed together as a core requirement on your journey to Zero Trust

Secrets Management Maturity Model

Blog Article by GitGuardian

Secrets Management Maturity Model

As organizations are looking to develop secure digital services faster, the DevSecOps movement has seen its popularity soar, with the promise of breaking the silo between development, operations, and security. Although many tools and practices have emerged to support the development of “secure by default” applications for the cloud, the matter is still far from resolved. Secrets management, in particular, remains a thorny issue even for the most mature organizations. With hyperconnected systems, secrets have become omnipresent along the software development cycle, making the legacy security perimeter obsolete.

With this document, we wish to contribute to the consolidation of knowledge around DevSecOps practices by introducing a secrets management maturity model.

Information security leaders who would like to start by doing a quick assessment of their security posture can take the following five-minute questionnaire (it’s completely anonymous): Secrets Management Maturity Questionnaire The result chart at the end will provide an overview of their current level of secrets management maturity, complete with weaknesses and strengths, and invite them to jump directly to the most relevant part of this white paper.

We propose a 5 level maturity model for secrets management, detection, and remediation in 4 main areas of the software development cycle:

• Developer environment
• Source code management
• CI/CD pipeline & artifacts
• Runtime environments

Splitting the DevOps cycle into distinct phases is necessarily an arbitrary decision, and even more so when talking about something as transversal as secrets. Therefore, we decided to separate it according to the following logic:

Developer Environment

This section corresponds to the daily activities of the developer and how they manage to get access to and share the secrets they need to test their programs and scripts. As awareness about the problem of secrets sprawl rises, some developers encrypt secrets before sharing them, and potentially shield their working environment from leaks with pre-commit hooks. But that’s not all: developers are also on the front line when it comes to secrets remediation. Progressively involving developers in the remediation process is a significant step toward a mature secrets management program.

This is also where we chose to talk about the evolution of secrets’ rotation policies and process, eventually leading to full automation.

Source Code Management (Source Code and Infrastructure-as-Code)

This section is about how source code and templates (Terraform, Dockerfile, etc.), at a global level, can be shielded from secrets sprawl. We consider that secrets found in IaC templates are probably giving access to cloud resources like storage, IAM systems, etc.. and should be removed first. Central repositories’ administrators are in charge of setting up the right controls to continuously scan for secrets before they can be considered compromised.

This is also where we chose to talk about the evolution of the remediation process.

CI/CI Pipeline & Artifacts

This section is about the build process and the resulting artifacts. It is not uncommon to find secrets leaked in Docker images or even binaries. These should be removed in the first place, and the build process itself should eventually include a scanning step to make sure that no secrets can find their way into the artifacts or the build logs themselves. Also, the credentials used in the build process should be rotated and fine-tuned to a very restricted scope to prevent potential lateral movements.

Runtime Environment

Finally, at runtime applications also need secrets. The classic examples would be a database connection string for a web app or third-party API keys. Provisioning these secrets at runtime requires the same thoughtful design decisions about secrets’ lifetime, scopes, rotation, and, maybe more importantly, how to deal with a leak without causing downtime. We observed in the past that a leak could force engineers to temporally shut down part of the production, with direct consequences for the business. Preventing such an outcome definitely has its place in a secrets management mindmap.

Maturity Model

Level 0

No processes or tools for managing secrets — secrets sprawl in the SDLC. No detection (and remediation) in place.

Level 1

Secrets are unencrypted at rest but grouped in configuration files shared across multiple teams. Scanning for secrets is triggered manually at times, but developers are rarely involved in remediation.

Level 2

Secrets are checked encrypted into repositories with decryption keys stored in a secure vault. Secrets scanning and rotation are performed periodically.

Level 3

Secrets are scoped, stored in a vault and shared using a secrets manager. Automated detection on shared repositories and final artifacts is continuous.

Level 4

Secrets are scoped, stored in a vault and shared with a secrets manager. Detection is preventive and integrated into development workflows (local workstations, CI pipelines, etc.). Developers remediate their incidents.

Bonus: Kubernetes

As more and more organizations are making the shift to cloudnative technologies, Kubernetes has become the de facto choice to orchestrate container-based applications. That’s why we decided to give it its own place as a bonus in the Matrix, allowing us to be more specific about this unique technology.

Out of the box, Kubernetes supports ‘Secrets’ objects to store sensitive information like passwords, tokens, SSH keys, etc. securely. This construct eliminates the need for hard-coding sensitive data in the application code but needs to be handled with extreme caution.

Other Considerations

Like any security topic, secrets management does not exist in isolation. To conduct a thorough security posture analysis, it is important to consider related domains. The ones we have listed here have been deliberately excluded from the matrix since we consider that they go beyond the strict framework of secrets management.

However, this does not mean that they are optional: on the contrary, they require an equally important consideration. In other words, if you want to put effort into improving secrets management policies, you cannot overlook the following:

Access Controls

Access controls are used to answer the question: who has access to what and when? It is obvious that nothing can be secret if it can be read or updated by anyone. Engineers should not have access to all secrets in the secrets management system, so the least privilege principle should serve as a guide to progress in maturity. Our matrix does talk about the scope of the secrets at different levels: the secret management system needs to provide the ability to configure fine granular access controls on each object and component to accomplish the least privilege-required principle. Yet well-implemented access controls are a much bigger cybersecurity topic (including Identity and Access Management) that we do not have the vocation to cover in all its subtleties.

Cryptographic & Encryption Quality

The security of a secret depends, among other things, on its basic qualities: if the secret can be any character string chosen by a human, chances are that it will be easily cracked by brute force or a dictionary-like attack. On the other side of the spectrum, the most secure secrets are generated by high entropy hardware random number generators included in specialized HSMs. They would probably be too costly to implement & operate for most use cases. Furthermore, having high entropy secrets is great, but useless if they’re stored in cleartext in a database. Choosing high entropy secrets, the right hashing & encryption algorithms for your secrets at rest & in transit is another important part of any secrets management policy.

Logging and auditing

Logging is an integral part of maintaining an organization’s security posture, and this is also true for monitoring secrets. You should be able to know who requested a secret and for what system and role, when it was used and by which source, when it expired etc. Authentication and authorization errors are also a valuable source of security information. Having auditing tools and processes is definitely something to expect from a mature secrets management system.

Summary

Secrets management has a considerable impact on the security posture of organizations. With the advent of DevOps, the amount of sensitive information in use in software factories has exploded, creating a gap between theory and practice: in theory, all the “crown jewels” are closely guarded within a vault and scrupulously respect the principle of least privilege. In practice, teams continue to generate large quantities of secrets as they scale services and infrastructures, bypassing outdated controls. Secrets are easily exposed, sometimes without anyone noticing. This is a difficult problem to solve, even with all the flexibility automation brings us. That’s why some organizations do not invest sufficient time & effort into it despite the percentage of security breaches originating from exposed secrets.

Reducing this attack surface requires the right controls to be placed along the DevOps cycle, and to encourage collaboration between developers, security engineers, and operations. Not taking into account the human factor in the management of secrets would be a serious mistake.

No matter the technology, leaks will happen. The response lies at the intersection of people, tools, and processes. Having a plan to be notified as early as possible when a leak happens and to face incidents with peace of mind is a must.

We hope that our maturity model will be useful to allow you to take stock of the actual state of secrets management in your organization, and more importantly, what are the steps to improve it.

Securing Your Machine Identities Means Better Secrets Management

Blog Article by GitGuardian

Securing Your Machine Identities Means Better Secrets Management

Machine identities make up the majority of the over 12.8 million secrets GitGuardian discovered in public in 2024. Let’s look at how we got here and how we fix this.

In 2024, GitGuardian released the State of Secrets Sprawl report. The findings speak for themselves; with over 12.8 million secrets detected in GitHub public repos, it is clear that hard-coded plaintext credentials are a serious problem. Worse yet, it is a growing problem, year over year, with 10 million found the previous year and 6 million found the year before that. These are not cumulative findings!

When we dig a little deeper into these numbers, one overwhelming fact springs out: specific secrets detected, the vast majority of which are API keys, outnumber generic secrets detected in our findings by a significant margin. This makes sense when you realize that API keys are used to authenticate specific services, devices, and workloads within our applications and pipelines to enable machine-to-machine communication. This is very much in line with research from CyberArk, machine identities outnumber human identities by a factor of 45 to one. This gap is only going to widen continually as we integrate more and more services in our codebases and with ever-increasing velocity.

Secrets sprawl is clearly a problem for both human and machine identities, so why should we call out this distinction?

Machine identities

GitGuardian will be leaning into the term “machine identities” moving forward as a way to distinguish this area of secrets sprawl and its unique challenges apart from human identities and credentials. Each is problematic, but each calls for different approaches. We are following the naming convention from industry leaders in secrets management, such as CyberArk and analyst firms who define the industry, such as Gartner, in standardizing this terminology. Gartner defines the term in their 2020 IAM Technologies Hype Cycle report as, “Simply put, a machine identity is a credential used by any endpoint (which could be an IoT device, a server, a container, or even a laptop) to establish its legitimacy on a network.” This term covers all API access keys, certificates, Public key infrastructure (PKI), and any other way possible to authenticate machine-to-machine communication.

Is a machine identity the same as a non-human Identity?

From a purely grammatical perspective, it must be a non-human identity if it is not a human identity. So why use the specific term machine identity? Well, practically speaking, a non-human could be a dog, a plant, or even a planet. When using the term “non-human” we must also necessarily further qualify what we mean, while the term ‘machine identity’ already has a widely accepted definition that narrows the scope to the secrets sprawl problem space.

For example, Venafi, a leading machine identity management platform, succinctly states, “The phrase “machine” often evokes images of a physical server or a tangible, robot-like device, but in the world of machine identity management, a machine can be anything that requires an identity to connect or communicate—from a physical device to a piece of code or even an API.”

How did we get here?

Before we can talk about what to do about the issues of machine identities and secrets sprawl, it might be helpful to take a historical look at how we arrived at this point in the industry. In the early days of computer science, the only ‘entities’ we had to worry about accessing our machines and our code were humans. In the days of ENIAC or early UNIX systems, using a simple password and perhaps sturdy locks on the doors were really all you needed to ensure only the proper people could access a system. People love passwords, and we have for thousands of years. The Roman garrison used ‘watchwords’, which needed to be updated nightly, meaning we have been practicing manual password rotation for a couple of millennia now.

So, naturally, when it came time to implement machine-to-machine authentication, ensuring that we were only allowing access to trusted systems to recognize and communicate with one another, it was only natural we would turn to our old friend the password, in the form of a long and hard to guess token to get the job done. This system works okay until you remember the problem statement that started this article: we keep leaking these credentials into our code and into places around our code like Jira, Slack, and Confluence at an alarming rate.

Solving both human identity and machine identity sprawl

Now that we have a common vocabulary and understand the two areas of concern, human and machine, what are our next steps? Let’s start with human identities. People need to be able to authenticate to gain access to systems to get their work done. Using phishing-resistant MFA, preferably hardware-based, at every juncture where a human uses a password is a solid approach. Even if a password is leaked, it is much harder to exploit and gives the user time to rotate the credential. While not a silver bullet, Microsoft believes this could stop up to 99.9% of fraudulent sign-ins. Even better, if there is a way to eliminate that password, such as with a passkey using FIDO2 or hardware-based biometrics for authentication, then we should probably move in that direction.

Dealing with machine resources requires a different approach, as we can’t just turn on MFA for machines. We also can’t disrupt these machine identities, as the business of the enterprise is to do business, and the connections must continue to allow our systems to function and satisfy the availability leg of the CIA Triad. Similarly, we can not devote endless resources and hours to this issue, as new vulnerabilities in the form of CVEs, misconfigurations and licensing issues continue to be other areas security teams need to tackle.

In an ideal world, we could immediately move all of our systems to leverage short-lived certificates or JWTs that are issued at run time when needed and only live for the life of the request. Indeed, there are frameworks such as SPIFFE and its implementation, SPIRE, that can help organizations achieve this goal. While this is indeed a great approach, it has the real-world issues of developer adoption, development time and effort, and the overhead of running such services at scale.

While we can dream up many such ideal scenarios, we need to address the current situation head-on. Developers will continue to use machine identities, which can be leaked and exploited by attackers. At the same time, we know that if a malicious actor gets their hands on a secret, they can only leverage it if it is still valid. We believe the best practical solution for any organization is to rotate secrets much more frequently.

Automatically rotating secrets more frequently

One of the other stand-out findings from our State of Secrets Sprawl Report was the fact that of all the valid secrets we discovered in public, over 90% were still valid five days later. We believe this points to the fact that teams expect secrets to be long-lived and that the current manual approach to secrets rotation is hard. Further evidence of these conclusions can be found in breach reports involving companies such as Cloudflare.

In our Secret Management Maturity Model white paper, a clear differentiator in organizations in the Advanced and Expert categories is that they have adopted regular credential rotation policies. It is very unlikely these mature organizations are doing manual rotation, as that would be an overwhelming, time-consuming, and error-prone process, which potentially could mean disaster in our interconnected architectures.

We need a way to automate the rotation process. The good news is that awesome tools are available, such as CyberArk’s Conjure or AWS Secrets Manager, that make the process of auto-rotation pretty straightforward. Of course, this assumes all of your machine identities already and totally live within their system.

Auto-rotation of secrets first means knowing all your machine identities

Now, we could ask for every developer and infrastructure owner to give security teams a list of all their credentials in plaintext for all their various workloads, services, and devices, but obviously, that is a terrible and highly problematic idea.

In all seriousness, what is needed is a scalable end-to-end solution that can help you systematically and automatically find all the plaintext credentials inside of your code base, leaked out onto GitHub publicly, or even found in the communication tools that surround your code. Good news! GitGuardian makes exactly this. This is the heart and soul of our Secrets Detection Platform.

Automating the discovery and auto-rotation of machine identities with Brimstone

GitGuardian has partnered with CyberArk to offer a unique solution for security teams to detect machine identity leaks and manage their remediation effectively. We call this project Brimstone. This innovative integration allows communication between the GitGuardian Secrets Detection platform and CyberArk’s Conjur, automatically addressing leaked machine identities across various critical scenarios.

• “Unknown” machine identities. Known machine identities already exist in Conjur and need rotation or revocation, while unknown machine identities should be created there and then auto-rotated.
• Known machine identities found in sources monitored by GitGuardian.
• Publicly exposed machine identities on GitHub.com.

GitGuardian can help no matter where you store your machine identities

While we are very proud of our advanced integration with CyberArk, you can reap the machine identity discovery no matter where on your secrets management maturity journey. Taking that first step of understanding the scope of your issue is the best step in the right direction any organization can take to begin fighting secrets sprawl and better securing machine identities. Thanks to GitGuardian’s dashboard and API, teams can quickly get a handle on tackling the problem of hard-coded secrets, machine identities, and human identities alike. And with ggshield we can help you eliminate the issue at the root, on the developer’s machine

Spiffe – Secrets-Free Machine Identity Framework

Blog Article by GitGuardian

How To Get There: Bridging The Technology Gap Preventing You From Adopting A Secrets-Free Machine Identity Framework

Learn how GitGuardian can help you go from a world of secrets sprawl to a future with secrets-free machine identity frameworks by adopting SPIFFE/SPIRE.

In his recent guest blog for GitGuardian, Mattias Gees, Director of Tech Workload Identity Architecture at Venafi, laid out an argument for using Secure Production Identity Framework for Everyone (SPIFEE) and The SPIFFE Runtime Environment (SPIRE). He also covered the technical details for implementing this identity solution. It is a must-read for anyone struggling to find a path forward on IAM across their organization.

Security professionals should love this approach because it addresses multiple challenges around non-human identities at once by eliminating long-lived secrets like API keys and service worker passwords and relying on automatically issuing short-lived certificates for authentication and authorization. Even if an attacker gets their hands on an old x.509 cert, the window of opportunity likely will have closed before they can act.

So, why not implement a certificate-based system like SPIFFE/SPIRE right now in your organization? For some of our readers, the answer is, “I just didn’t know about it yet,” and they will begin as soon as you return to your terminal. The answer for most folks, especially those working in a large enterprise, might be closer to “We can’t just replace hardcoded credentials with managed machine identities! What would fail? This is an overwhelming proposition!”

While we will not say it is a quick and easy journey, there is an achievable route for organizations committed to solving IAM challenges at the root. And that path starts with admitting you are overwhelmed by secrets sprawl.

Understanding the route toward non-human identities

In our post on Hacker News, “End-to-End Secrets Security: Making a Plan to Secure Your Machine Identities,” we laid out a general framework for moving from the Wild West, where no one manages secrets, to a world where all secrets are properly stored, accounted for, and rotated.

We identified the steps:

1. Secrets Detection – Search through code and systems involved in the software development lifecycle to identify existing plaintext credentials, gathering as much information as possible about each.
2. Secrets Management – Accounting for all known secrets through a centralized vault platform.
3. Developer Workflows – Adjust processes and tools to make it easier to properly create, store, and call secrets securely.
4. Secrets Scanning – Continuously monitoring for any new secrets that get added in plain text.
5. Automatic Rotation – Regular replacement of valid secrets shortens their potential exploitation by malicious actors.

Adopting certificate management infrastructure, like that provided by SPIFEE/SPIRE, is the next logical step in solving secrets sprawl in your organization. Every other step will support you as you go system by system and change the way your applications and all related machine identities communicate.

Other approaches to managing short-lived certificates for your non-human identities

While the article we first cited focuses on adopting SPIFFE/SPIRE, we need to acknowledge that there are other ways to approach certificate-based machine identity management. Some approaches involve SPIFFE as part of the process, such as leveraging the open-source service mesh Istio; SPIRE can be leveraged in place of an agent-based approach.

Other paths to short-lived certificates can be found in secret managers themselves. This takes the form of Public Key Infrastructure PKI. Vault by Hashicorp has a path to automated PKI infrastructure. Venafi, which is now part of CyberArk, offers Zero Touch PKI-as-a-Service.

No matter which final destination you aim at or the specific path you take on your machine identity journey, the first step from where you and your developers are today is the same for everyone.

Taking stock of secrets is the needed first step

The first needed step in threat modeling is understanding what you are protecting. The first step in API security is knowing what APIs you even have. It follows that the first step down the road to SPIFFE/SPIRE and better managing non-human identities is understanding what machine identities currently need authentication and authorization.

We know that access has, up to now, relied on API keys and other long-lived credential approaches, so if we find all the secrets throughout our codebases, project management tools, communication channels, and other text files, like logs, we should have an accounting of all the related services, workloads, and devices right?

You might already be down this path as you adopt a secrets management platform like Conjure from CyberArk, Vault Enterprise by Hashicorp, or cloud provider-specific ones like AWS or GCP. Even if this is as far as you plan to go down this path, then we can really speed things up with The GitGuardian Secrets Detection Platform.

Freeing developers from being secrets experts

While the security ramifications of moving away from long-lived credentials are something we could write an entire book about, a productivity argument must also be made. There is a hidden cost to continuing down the route of manually managing secrets per service or device. In their book “Solving the Bottom Turtle,” the authors of SPIFFE/SPIRE say:

“By abstracting cloud provider identity interfaces into a set of well-defined common APIs built on open standards, SPIFFE significantly reduces the burden of developing and maintaining cloud-aware apps.”

A cloud-aware application is simply one that calls services in the cloud. And guess what? Every service is different. Each has a learning curve. Each has permissions with varied levels of nuance to navigate. Developers just want their apps to work, so the easiest path is often just leaving permissions as permissive as possible and hardcoding the resulting credential in the place where it is called in the codebase.

SPIFFE/SPIRE and similar approaches for machine identity access remove this level of complexity from the developer’s world. Developers save a lot of effort when there is a standardized approach across all services and workloads. Again, from their book

Two important aspects of SPIFFE/SPIRE unlock these savings: the fully automated issuance and management of cryptographic identity and its associated lifecycle, and the uniformity and offloading of authentication and service-to-service communication encryption. By removing manual processes associated with the former, and time spent in research and trial/error in the latter, developers can better focus on what matters for them: the business Logic.

This is amazing news for the developer. If they are coding a REST API microservice, there is no need for them to bog down their work implementing a bearer token or any other such mechanism to achieve secure communication. All of those decisions are completely offloaded to the framework.

Their estimates show an average of 530 projected hours saved due to better developer productivity.

Example boost in developer productivity from Solving the Bottom Turtle

We are here to help guide your next steps

If you are ready to embark on this journey, it is important to recognize that you are not on this path alone. Secrets sprawl is an issue every organization struggles with. The more non-human identities in your environments, the more urgent it is to find a way to escape the risks long-lived credentials currently pose.

It is a good thing there are folks like those at The Linux Foundation’s Cloud Native Computing Foundation and OpenSSF who are working on making solutions like SPIFFE/SPIRE free, open source, and accessible to all. Secrets management platforms like Conjure and Vault are going to make sure your current non-human identities that necessarily rely on secrets can continue to function safely while you implement a better approach.

GitGuardian is here to help you with that first step that is ever-ongoing; discovering all the secrets in your code (and other sources) in a scalable and automatable way. Our API-based approach means you can rely on getting the right contextual information in each incident and tie it directly into your remediation processes and tooling. We see a bright future where long-lived secrets have no place in how our non-human identities communicate. We hope to work with you to get you there sooner.

A Quick Take on OWASP API Security Top 10

Blog Article by Corsha

The Open Worldwide Application Security Project (OWASP) is a nonprofit organization dedicated to improving software security. Through resources, tools, and guidance, OWASP supports developers, application architects, and security professionals in building secure applications. One of OWASP’s most well-known contributions is its Top 10 list of the most critical web application security risks. This list helps organizations focus their security efforts on the latest threats and vulnerabilities.

However, as software ecosystems increasingly rely on APIs (Application Programming Interfaces), OWASP has expanded its focus. APIs, which enable communication and data exchange between different software systems, are the backbone of modern enterprises. With API-driven implementations exploding across cloud, on-premise, and edge environments, securing APIs has become more crucial than ever. To address this, OWASP introduced the API Security Top 10—a comprehensive guide detailing the most critical security risks facing APIs.

OWASP API Top 10 (2023 )

The OWASP API Security Top 10 highlights the most significant risks to APIs in 2023:

1. Broken Object Level Authorization (BOLA)
2. Broken Authentication
3. Broken Object Property Level Authorization
4. Unrestricted Resource Consumption
5. Broken Function Level Authorization
6. Unrestricted Access to Sensitive Business Flows
7. Server Side Request Forgery (SSRF)
8. Security Misconfiguration
9. Improper Inventory Management
10. Unsafe Consumption of APIs

With the rise of API-related attacks, these vulnerabilities present significant risks. According to a recent report ¹, 61% of attacks in the past year were authentication-based, highlighting the importance of robust API security practices.

Addressing API Security with Corsha

Corsha takes an identity-first approach to API security. By dynamically tracking machine identities and enforcing multi-factor authentication (MFA) for every API request, Corsha helps mitigate risks outlined in the OWASP API Top 10. Below is a breakdown of how Corsha helps organizations defend against specific vulnerabilities.

Why OWASP API Security Matters

As APIs become more prevalent, they introduce unique vulnerabilities that must be prioritized by organizations. The OWASP API Top 10 serves as an important guide for understanding and mitigating API security risks. By addressing the security concerns identified in the Top 10, organizations can prevent data breaches, service disruptions, and other damaging attacks.

OWASP has announced plans to release the OWASP Top 10: 2025 in the first half of next year, further updating its guidance on the most critical web application security risks. To learn more about the OWASP API Top 10 and the OWASP API Security Project, visit OWASP API Security.