top of page

Cybersecurity Beyond OWASP: What Developers Miss

Shift Quality Editorial
Apr 18
7 min read

Updated: 6 days ago

Corrected, 4 October 2026. We re-checked this post's claims against their original sources and corrected or removed those we couldn't verify.

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 compromise, which prompted CISA's Emergency Directive 21-01 in December 2020, was the wake-up call, and attacks through package registries have kept coming since. In October 2021, attackers hijacked the maintainer account of ua-parser-js, an npm package downloaded millions of times a week, and published versions that installed a cryptominer and a password stealer (CERT-EU, 2021). In 2022, the node-ipc maintainer intentionally added code that overwrote files on systems with Russian or Belarusian IP addresses as a political protest (CVE-2022-23812). In May 2023, PyPI temporarily suspended new user and project registration because, in its administrators' words, the volume of malicious users and projects "outpaced our ability to respond to it in a timely fashion" (BleepingComputer, 2023).


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 may already be installed everywhere that package is pulled in.


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. The NSA's cloud guidance calls misconfiguration "the most prevalent cloud vulnerability" (NSA, 2020). 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 large volumes of sensitive records. Amazon S3 has blocked public access on new buckets by default since April 2023, but existing buckets keep their old settings, and hasty deployments still create exposure (AWS, 2023).


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. Attackers target them directly.


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. CISA has documented North Korea's Lazarus Group using fake job offers to get employees at cryptocurrency companies to download trojanized applications (CISA AA22-108A, 2022).


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 top entry in the OWASP API Security Top 10 (2023) 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.


Sources




Part of the Software Quality Engineering guide — ShiftQuality's complete map to building quality in.

bottom of page