Human Error – The Most Common Cybersecurity Mistakes for DevOps

Even though security tooling and automation in DevOps have advanced, human error remains the primary cause of cybersecurity breaches. It’s commonly known that nearly 95% of security incidents stem from our mistakes. A smiled dev philosopher would say: “We’re all just beta software in the giant simulation called life. Debugging takes time.”

This fact underscores the need to identify and eliminate the most frequent and dangerous errors, as well as develop mitigation strategies.

“68% of breaches involve non-malicious human elements, including errors.”

Source: Verizon Business

User mistake as a constant in the DevOps equation

From a DevOps or cybersecurity perspective, preventing user errors resembles breaking through the Amazon jungle. You know the usual dangers and how to avoid them, but there are so many things you can step on and regret. Even an experienced engineer can misfire a command or misconfigure a setting. 

It doesn’t have to be an extreme, movie-like event like a misplaced wildcard erasing critical data in a production environment (the famous and definitive rm -rf *) or a misplaced decimal in a financial operation, resulting in millions in damages.

Sometimes, a production database can be accidentally deleted while debugging replication issues. 

Call it a textbook instance of a crisis caused by a momentary lap. Of course, mistakes sometimes result from:

• an absent mind
• fatigue
• stress/haste
• overconfidence
• too many responsibilities
• insufficient training
• accident (and many others).

“We must accept human errors are inevitable – and design around that fact.”

Dr. Donald Berwick

Such mistakes may open the way for cyber criminals despite sophisticated security technology. Businesses have known this for a long time, yet many organizations still deny investing in so-called human factor security.

At the same time, it raises the question of what the most common cybersecurity mistakes in DevOps are and what can be done about them.

Mistake 1. Unverified and insecure dependencies

Developers tend to integrate third-party dependencies or container images from public repos. Most of the time, it goes without verification. Such dependencies introduce:

• malware
• outdated libraries
• backdoors.

The above usually compromises all types of production environments.

“87% of container images in production have critical or high-severity vulnerabilities. Only 13% have low, medium, or no vulns.”

Source: Sysdig

In general, all the issues mentioned remain unpatched. Teams manage only 15% of vulnerabilities, the most essential ones.

Use case

An interesting incident happened in April 2021. A security breach harmed Codecov. It involved a tool used to measure code coverage. Attackers exploited a flaw in how Codecov built its Docker (image creation). It enabled them to extract credentials and tamper with the Bash Uploader script.

The company was using the latter in its CI workflows. Attackers modified the script. They aimed to collect and transfer sensitive data to an external server. Hackers got access to environmental variables and other information.

Codecov dealt with the intrusion due to a discrepancy in the hash value. Their customer discovered the problem during the checksum calculation of the mentioned script. It didn’t match the SHA256 hash published by Codecov on GitHub.

Source: Codecov.io

Mitigating insecure dependencies

You can rely on a few solutions to avoid unpleasant surprises with dependencies within your IT stack.

• Enforce signature verification (e.g., Cosign) of container images. This way, you ensure that only signed and trusted images are deployed.
• Utilize Software Bill of Materials (SBOM) generation tools. Maintain a detailed list of all dependencies in use for vulnerability tracking.
• Scan dependencies regularly. Use CVE scanners (like Trivy or Snyk) and integrate these scans into CI/CD pipelines. That prevents the introduction of known vulnerabilities to the system.
• Implement automated security policies in artifact repos (e.g., JFrog Xray). This will block risky dependencies at the source and allow only vetted images. 

apiVersion: v1

kind: ClusterPolicy
metadata:
   name: require-signed-images
spec:
   validationFailureAction: Enforce
  rules:
	- name: verify-signature
  	match:
	resources:
	   kinds:
        	- Pod
  	validate:
    	message: "All container images must be signed with Cosign."
    	pattern:
	   spec:
	      containers:
          	- image: "ghcr.io/*@sha256:*"

An example of enforcing image policies. Source: kyverno.io

• Conduct regular backups. It’s your last resort security measure. You can recover from a compromised state without relying on potentially infected dependencies. In addition, you can utilize:
  • immutable backups that cannot be tampered (e.g., WORM storage)
  • automated rollbacks
  • disaster recovery planning
  • backup verification pipelines.

Mistake 2. Insufficient access control

As always, mismanagement of access controls often results in unauthorized entry to sensitive data. It happens when convenience is prioritized over security. A great example may be shared credentials or privilege misuse.

Imagine a scenario where part of the department uses the same login credentials to access the database. It’s very convenient—there is no need to remember multiple passwords. 

But here’s the danger: If those credentials are compromised or one person leaves the company, everyone’s access is vulnerable. Especially when someone has more access to the given information than is needed.

“74% of data breaches involve a human element, including privilege misuse and credential theft.”

Source: Verizon

Real-life instance

23andMe, a genetic testing company, disclosed a data breach in October 2023. The event affected 14,000 of the company’s customers’ accounts. In five months, the data of 7 million people were exposed. The attackers gained access to user data by compromising individual accounts. Then, they use them to extract data from other accounts.

Earlier in May, Tesla’s confidential data was leaked to a German news organization. The leak originated from two ex-Tesla employees. They stole and provided the information to the media despite Tesla’s policy.

Source: Risk-Strategies.com

“14% of breaches involve the exploitation of vulnerabilities  as an initial access step.”

Source: Verizon

Fortunately, there are several ways to avoid such problems. And even if they occur, their negative impact can be mitigated.

How to avoid access control insufficiencies 

The answer lies in automation, strict access control, and continuous security monitoring. The latter also includes validating introduced policies. It sounds obvious, yet it remains overlooked.

Enforce the Principle of Least Privilege (PoLP)

Ensure that all users and services have the minimum permissions required to function. Implement Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) in cloud environments.

Adopt Just-In-Time (JIT) access

Utilize tools like AWS IAM Access Analyzer, Azure PIM, or Google Cloud IAM Conditions to provision temporary, time-limited access instead of persistent permissions.

Here’s a simple example of the restricted IAM role scope.

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
	"StringNotEqualsIfExists": {
  	"aws:PrincipalArn": "arn:aws:iam::123456789012:role/allowed-role"
	}
  }
}

Use Multi-Factor Authentication (MFA)

For additional security, MFA is required for all privileged accounts, and passwordless authentication, such as FIDO2 or WebAuthn, must be enforced.

Implement Infrastructure as Code (IaC) scanning

Leverage tools like Checkov or Terrascan. Before deployment, detect and remediate overly permissive IAM policies in Terraform or CloudFormation templates.

Remember about backups

When an access misconfiguration leads to data exposure or unauthorized changes, it’s good to maintain an efficient backup strategy, including immutable backups. Thus, you will be able to restore compromised or deleted data to a known good state. 

Mistake 3. Weak authentication mechanisms

Among the reasons behind stolen credentials, you can often find:

• weak password policies
• lack of hardware-based authentication
• insecure credential storage mechanisms (e.g., plaintext secrets in environment variables).

Weak password policies

Short, easily guessable passwords are trivial to crack using:

• dictionary attacks (common passwords)
• brute-force attacks (using all possible character combinations_ 
• rainbow tables (precomputed hashes of common passwords).

Simple (weak) passwords without a variety of characters are a straight way to disaster. Especially if the company does not enforce password policy and MFA. Even though the topic is trivial and makes your eyeballs roll, it’s still the weakest link in the security chain.

“80% of confirmed breaches are caused by stolen, weak, or reused passwords.” 

Source: Sprinto

“88% of passwords used in successful attacks consisted of 12 characters or less.”

Source: Secureframe

Hardware-based authentication

Such an authentication method ties credentials to a physical device. A fine example may be smart cards or security keys (like YubiKeys). This approach makes it significantly harder for attackers to steal credentials remotely.

Even if a password is compromised, the attacker still needs physical possession of the hardware token to gain access. Otherwise, access remains blocked with the correct password.

Insecure credential storage mechanisms

Storing secrets in plaintext within environment variables, configuration files, or code repos is highly risky. Especially when it comes to:

• API keys
• database passwords
• cryptographic keys. 

If the hacker gains access to the system, e.g., through a server vulnerability of a compromised developer’s machine, these secrets are readily available.

Environment variables, in particular, are often easily accessible to processes running on a system. 

Embedding login details directly into the application’s code makes those secrets visible to anyone who can access the code itself. Whether by viewing the (original) source or reverse-engineering (decompiling) the app.

Preventing the weaknesses

To minimize the likelihood of credential theft:

Enforce FIDO2-based passwordless authentication

Hardware security tokens are required to eliminate the risks associated with password-based authentication.

Mandate phishing-resistant MFA

Demand MFA policies that utilize FIDO2/WebAuthn rather than SMS-based MFA, which is vulnerable to SIM swapping attacks.

Replace shared credentials with identity federation

Utilize OAuth 2.0, OpenID Connect, or SAML-based authentication to administer centralized authentication and authorization controls.

Secure secrets management

Store credentials in secure vaults instead of hardcoding them in repositories or environment variables. For instance, use HashiCorp Vault, AWS Secret Manager, or Azure Key Vault.

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: dXNlcg==  # Base64-encoded 'user'
  password: cGFzc3dvcmQ=  # Base64-encoded 'password'

An example use of Kubernetes Secrets instead of environment variables

Have your data backed up

• Backup encrypted credentials: Store authentication secrets in encrypted, versioned backups to ensure rollback in case of breach.
• Monitor for leaked credentials: Deploy a GitProtect.io tool to automatically back up repos and scan for exposed secrets in Git history using tools like GitGuardian.
• Immutable backups: Use object lock policies in S3-compatible storage to prevent tampering with authentication-related backup data.

Looking at the above, it seems impossible to avoid a statement that mitigating human error in DevOps security demands a comprehensive strategy. These words are ubiquitous. Yet, statistics show “they” have difficulty breaking through to the general consciousness. What’s even worse is that it is also in business.

A word of summary

Human error in DevOps security is given, but its impact is not. Avoiding and preventing discussed mistakes should encompass:

• cryptographically validated dependencies
• zero trust access
• passwordless authentication
• secure-by-default configurations
• real-life misconfiguration monitoring
• immutable backups.

Shifting security left and automating threat detection substantially reduces risks from human fallibility. 

After all, the fewer the breaches, the less downtime. This is a win for security and operations. At the same time, it boosts your: 

• company’s reputation – Security Incident Rate, MTTD, MTTR, Customer Trust & Sentiment Analysis
• competitive edge – Ris Score over Time, Zero Trust Adoption Rate, Backup & Disaster Recovery Readiness Score, etc.

[FREE TRIAL] Ensure compliant DevOps backup and recovery with a 14-day trial 🚀

[CUSTOM DEMO] Let’s talk about how backup & DR software for DevOps can help you mitigate the risks