Cybersecurity Beyond OWASP: What Developers Miss

If you have been paying attention to security at all, you know the OWASP Top 10. SQL injection. Cross-site scripting. Broken authentication. These are the greatest hits of web application security, and knowing how to prevent them is table stakes.

But the threat landscape has evolved far beyond web application vulnerabilities. The attacks that cause the most damage today often exploit areas that the OWASP Top 10 does not cover — supply chain compromises, CI/CD pipeline attacks, infrastructure misconfigurations, and social engineering that targets developers specifically. This post covers the security gaps that experienced developers still miss.

Supply Chain Attacks

Your application is not just your code. It is your code plus hundreds or thousands of dependencies, each of which is maintained by someone you do not know, funded in ways you do not understand, and updated on a schedule you do not control.

Dependency Compromise

The SolarWinds attack in 2020 was the wake-up call, but supply chain attacks have only accelerated since then. In 2021, a compromised npm package (ua-parser-js, 7 million weekly downloads) was modified to include cryptocurrency mining malware. In 2022, the node-ipc maintainer intentionally added code that wiped files on systems with Russian or Belarusian IP addresses as a political protest. In 2023, multiple PyPI packages were found to contain data-exfiltration code disguised as popular libraries.

The pattern is consistent: attackers compromise a package that other packages depend on, and the malicious code propagates through the dependency tree. By the time it is detected, it has been installed on millions of systems.

What You Can Do

Pin your dependencies. Do not use version ranges in production. Specify exact versions so that a compromised update does not automatically flow into your builds.

Use lock files. package-lock.json, yarn.lock, Pipfile.lock, and their equivalents ensure reproducible builds and prevent silent dependency changes.

Audit regularly. npm audit, pip-audit, and dotnet list package --vulnerable scan for known vulnerabilities. Run these in CI, not just locally.

Evaluate before you install. Before adding a dependency, check its maintenance status, download counts, contributor base, and funding model. A critical dependency maintained by a single unpaid volunteer is a supply chain risk.

Use a dependency firewall. Tools like Socket, Snyk, and Dependabot can flag suspicious changes in dependencies — new network calls, filesystem access, or obfuscated code in an otherwise straightforward library.

CI/CD Pipeline Security

Your CI/CD pipeline has access to everything: source code, secrets, production credentials, deployment infrastructure. It is one of the highest-value targets in your organization, and it is often one of the least secured.

Common Pipeline Vulnerabilities

Secrets in environment variables. CI systems make it easy to store secrets as environment variables. But those variables are often accessible to any step in the pipeline, logged in debug output, and visible to anyone who can modify the pipeline configuration.

Unreviewed pipeline changes. If a developer can modify .github/workflows/ or .gitlab-ci.yml without review, they can exfiltrate secrets, inject malicious code into builds, or deploy compromised artifacts. Pipeline configuration should receive the same review scrutiny as application code.

Third-party actions and plugins. GitHub Actions, GitLab CI templates, and Jenkins plugins from third parties run with the same permissions as your pipeline. A compromised action can steal secrets, modify source code, or inject malware into your build artifacts. Pin third-party actions to specific commit SHAs, not tags that can be moved.

Build artifact integrity. If an attacker can modify your build artifacts after they are built but before they are deployed, they can inject malicious code without touching your source repository. Sign your artifacts and verify signatures before deployment.

What You Can Do

Treat your CI/CD pipeline as a production system. Apply the principle of least privilege — each pipeline step should have access only to the secrets it needs. Require review for pipeline configuration changes. Audit third-party actions and plugins. Implement artifact signing and verification.

Infrastructure Misconfigurations

The most common cloud security failures are not sophisticated attacks. They are misconfigurations — storage buckets left public, security groups that allow unrestricted access, IAM roles with excessive permissions.

The Usual Suspects

Public storage buckets. S3 buckets, Azure Blob containers, and GCS buckets with public access have exposed billions of records. Every major cloud provider now defaults to private, but legacy configurations and hasty deployments still create exposure.

Overly permissive IAM. The principle of least privilege is easy to state and hard to implement. In practice, developers grant broad permissions to get things working and never tighten them. An IAM role with *:* permissions is a skeleton key to your entire cloud environment.

Default credentials. Database servers, admin panels, and management interfaces deployed with default passwords. This should not still be happening in 2026, but it is.

Unencrypted data at rest. Cloud providers make encryption easy, but it is not always the default. Data stored unencrypted is one misconfiguration away from exposure.

What You Can Do

Use infrastructure-as-code tools (Terraform, Pulumi, CloudFormation) with security linting built in. Tools like tfsec, checkov, and cfn-lint catch misconfigurations before they reach production. Implement automated drift detection to catch manual changes that bypass your IaC pipeline.

Social Engineering Targeting Developers

Attackers have figured out that developers are high-value targets. A developer's credentials provide access to source code, deployment pipelines, and production infrastructure. Social engineering attacks targeting developers are becoming more sophisticated and more common.

How It Happens

Fake recruiters. An attacker poses as a recruiter on LinkedIn, sends a "coding challenge" that is actually malware, and gains access to the developer's machine. This technique was used in the Lazarus Group attacks against cryptocurrency companies.

Compromised open-source contributions. An attacker submits a legitimate-looking pull request to an open-source project that introduces a subtle vulnerability. The maintainer reviews it, it looks reasonable, and the vulnerability is merged. This is extremely difficult to detect.

Phishing through developer tools. Fake npm login pages, phishing emails disguised as GitHub notifications, and malicious VS Code extensions have all been used to steal developer credentials.

Watering hole attacks. Compromising websites that developers frequently visit — documentation sites, package registries, developer forums — to deliver malware.

What You Can Do

Enable multi-factor authentication on everything — GitHub, npm, PyPI, cloud accounts, and email. Use hardware security keys where possible. Be skeptical of unsolicited messages, even on professional networks. Verify the source of any executable you run, including "coding challenges" from recruiters.

API Security Beyond Injection

APIs are the backbone of modern applications, and their security surface extends well beyond SQL injection and parameter tampering.

Rate Limiting and Resource Exhaustion

An API without rate limiting is an invitation for abuse. Not just denial of service — attackers can use unrestricted APIs to enumerate data, brute-force authentication, or scrape content at scale. Rate limiting should be implemented at multiple levels: per-IP, per-user, per-endpoint.

Broken Object-Level Authorization

The most common API vulnerability is also the simplest: failing to verify that the authenticated user has permission to access the specific resource they are requesting. If changing /api/users/123/records to /api/users/456/records shows you someone else's data, you have broken object-level authorization. Every API endpoint that accepts a resource identifier must verify the requesting user's permission to access that specific resource.

Excessive Data Exposure

APIs often return more data than the client needs, relying on the frontend to filter what is displayed. An attacker can bypass the frontend and see the full response, which might include sensitive fields that were never meant to be exposed. Return only the data that is needed for each endpoint.

Secrets Management

Secrets management is conceptually simple and operationally difficult. Everyone knows not to hardcode passwords. The failures happen in the nuances.

Where Secrets Leak

Git history. You removed the secret from the file, but it is still in the git history. Once a secret has been committed, consider it compromised — rotate it, do not just delete it.

Log files. Request logging that captures headers (including Authorization headers), error messages that include connection strings, and debug logging that prints environment variables all leak secrets.

Error responses. Stack traces and error details returned to clients can reveal database connection strings, internal hostnames, file paths, and framework versions.

CI/CD output. Build logs that echo environment variables, test output that includes API responses with auth tokens, and deployment logs that show configuration details.

What You Can Do

Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, 1Password for development). Implement secret scanning in your CI pipeline (tools like gitleaks, trufflehog, and GitHub's built-in secret scanning). Configure your logging framework to redact sensitive patterns. Review your error handling to ensure internal details are not exposed to clients.

The Human Element

The most sophisticated security architecture in the world fails if someone clicks the wrong link, reuses a password, or shares credentials in a Slack message. Security is ultimately about human behavior, and developers are humans.

Build security into your workflow so that the secure path is the easy path. Make it easier to use the secrets manager than to hardcode a password. Make it easier to use parameterized queries than to concatenate SQL strings. Make it easier to deploy with proper configurations than to cut corners.

Security that depends on every person making the right decision every time is security that will eventually fail. Security that is built into the tools and processes is security that scales.