Malicious code detection now spans code, pipelines, and runtime

At a glance

What this is: This is Cycode’s guide to malicious code detection, and its central finding is that modern attacks now exploit dependencies, pipelines, containers, and AI-generated code across the software lifecycle.

Why it matters: It matters because IAM, PAM, and NHI practitioners increasingly have to govern secrets, service credentials, and pipeline trust boundaries alongside traditional application controls.

By the numbers:

• Supply chain attacks increased by 200% in 2024, according to Cycode’s analysis.
• The average cost of a data breach reached $5.08 million in 2025, highlighting the financial impact of missed malicious code detection.

👉 Read Cycode's guide to malicious code detection across the SDLC

Context

Malicious code is code intentionally written to harm systems, steal data, or compromise integrity, and the problem has shifted from isolated malware to software supply-chain exposure. In practice, that means risks now live in dependencies, build pipelines, containers, and AI-assisted development, where traditional endpoint-centric controls are too late to help.

For identity and access teams, the governance gap is not only code quality but trust in the credentials, secrets, and automation that move code into production. When pipeline identities, service accounts, and secret material are weakly governed, malicious code can persist, propagate, and reuse legitimate access paths before security teams notice.

Key questions

Q: How should security teams detect malicious code across the SDLC?

A: Use layered detection across source code, dependencies, build pipelines, containers, and runtime rather than relying on one scanner. The strongest programmes correlate SAST, SCA, secrets scanning, and pipeline controls so that malicious code, compromised packages, and exposed credentials are evaluated together before release.

Q: Why do supply-chain attacks create such a large malicious code risk?

A: They exploit trusted delivery paths, which means the malicious payload can enter through a dependency or build step that defenders already accept. Once inside the delivery chain, the code can propagate to many downstream applications before traditional controls notice, making the blast radius much larger than a single host infection.

Q: What do teams get wrong about secrets scanning and malicious code detection?

A: They often treat secrets scanning as a standalone control when it is only one layer of a broader trust problem. A leaked token matters most when it can be used by pipeline identities, deployment automation, or privileged build systems that still have standing access.

Q: How should organisations respond when malicious code has already run in a build or developer environment?

A: Contain the endpoint, revoke the exposed secrets, and check for follow-on compromise in repositories and cloud accounts. Uninstalling the package is not sufficient if persistence, exfiltration, or secondary payloads were already established. Response has to cover the host, the identities it touched, and any downstream systems those identities can reach.

Technical breakdown

How malicious code moves through dependencies and build pipelines

Malicious code no longer needs to arrive as a classic executable. It can enter through compromised open-source packages, poisoned dependencies, or injected scripts in CI/CD workflows, then ride trusted automation into builds and releases. That is why software supply-chain attacks are so effective: defenders often trust the package, the maintainer, or the pipeline more than the payload itself. Static inspection alone misses much of this because the dangerous behavior may be triggered later, after deployment or when a dependency is resolved in context.

Practical implication: scan dependencies and pipeline steps together, not as separate security problems.

Why SAST, SCA, and secrets scanning have to work together

SAST looks for insecure patterns in source code, SCA inventories third-party dependencies, and secrets scanning identifies credentials, tokens, and certificates embedded in repositories or build artifacts. Each covers a different failure mode. SAST will not reliably detect leaked credentials, SCA will not catch a malicious inline script in application code, and secrets tools do not tell you whether an insecure dependency can be exploited. The operational mistake is treating any one of them as complete coverage.

Practical implication: use layered detection so one control does not become the blind spot for another.

How AI-powered analysis changes malicious code detection

AI and LLM-based detectors can identify code semantics, suspicious behavior, and evasive patterns that simple signatures miss, including string splitting, variable renaming, and low-signal obfuscation. They are useful where attackers alter syntax but preserve intent. However, AI detection is only as strong as its training data, its telemetry, and its ability to contextualize runtime behavior. Without pipeline, runtime, and policy correlation, model outputs can become noisy rather than actionable.

Practical implication: pair AI-assisted detection with runtime and policy enforcement, not standalone triage.

Threat narrative

Attacker objective: The attacker aims to convert trusted software delivery into a scalable access and exfiltration channel that reaches many downstream victims at once.

1. Entry occurs when attackers inject malicious code through compromised dependencies, vulnerable packages, or poisoned pipeline inputs.
2. Escalation follows when build and release automation treats the code as trusted, allowing the payload to reach broader environments with legitimate privileges.
3. Impact occurs when the malicious code steals data, establishes persistence, or disrupts production systems across downstream applications.

NHI Mgmt Group analysis

Malicious code detection is now an identity problem as much as an application security problem. The article focuses on code, but the real control plane includes the credentials that let pipelines build, sign, deploy, and fetch dependencies. When those identities are over-privileged or poorly scoped, malicious code inherits legitimate access paths. Practitioners should treat pipeline identities, service accounts, and secret governance as part of malicious code defence, not a separate IAM workstream.

Software supply-chain attack is the right named concept for this risk pattern. The attack surface is no longer just source code, but the chain of trusted handoffs that turns source into production software. That includes package registries, build runners, artifact stores, and AI-assisted coding tools. The practical conclusion is that control ownership must extend across development, security, and platform engineering.

Detection depth matters less if remediation remains slow. Cycode’s emphasis on multi-layer scanning is useful, but the business risk remains in the gap between finding a malicious artifact and neutralising its path to production. Security teams should care about where findings flow, who can block releases, and whether the response process can actually outrun propagation. Practitioners need governance over decision rights, not only more findings.

AI-generated code increases both volume and ambiguity in malicious code review. As code generation scales, security teams will see more machine-produced snippets, more third-party dependencies, and more uncertainty about provenance. That creates a stronger need for policy-based inspection, build-time trust validation, and tighter secret controls around developer tooling. The implication is clear: governance must evolve from code review at the edge to trust management throughout the lifecycle.

What this signals

Software supply-chain attack: malicious code programmes now fail or succeed based on whether trust boundaries are enforced at the pipeline layer. Teams that still separate application security from identity governance will miss the fact that build identities, signing keys, and deployment tokens are part of the attack surface.

AI-assisted development increases volume faster than manual review can absorb, so programmes need policy-driven prioritisation and provenance checks rather than more alert triage. The right operating model is to shrink the set of code paths that can reach production, then use OWASP Non-Human Identity Top 10 style governance to constrain the credentials behind automation.

A practical next step is to align code security with lifecycle control of secrets and service identities, especially where build systems can create, fetch, or reuse credentials. That is where identity governance stops being adjacent to AppSec and becomes part of release integrity.

For practitioners

• Map pipeline identities and release privileges Inventory the service accounts, tokens, and signing identities that can move code from commit to production. Reduce standing access and separate build, test, sign, and deploy permissions so malicious code cannot ride one credential across the whole SDLC.
• Correlate SAST, SCA, and secrets findings Run source, dependency, and secrets checks together in the same release gate so one weak signal does not hide another. Prioritise findings that combine vulnerable code with exposed credentials or high-reachability dependencies.
• Harden dependency and pipeline trust boundaries Pin dependencies, verify package provenance, restrict runner permissions, and monitor for unusual package resolution or build-step behaviour. Use these controls to cut off the trusted paths that supply-chain malware relies on.
• Add response paths for secret exposure in build artifacts Define how teams revoke, rotate, and invalidate secrets that appear in repositories, artifacts, or logs. Tie the response to identity lifecycle controls so exposed credentials do not remain usable after detection.

Key takeaways

• Malicious code has become a software supply-chain and identity governance problem, not only a malware problem.
• Cycode’s analysis shows that modern defences need layered scanning across code, dependencies, pipelines, and runtime, with AI used for context rather than as a standalone answer.
• Practitioners should focus on provenance, pipeline identity, and secret lifecycle controls because those are the leverage points that limit propagation.

Key terms

• Malicious Code: Code deliberately written to perform unauthorized or harmful actions inside software, scripts, dependencies, or build assets. It is narrower than malware because it focuses on the code layer that gets embedded into applications and delivery pipelines, where it can steal data, open backdoors, or alter system behavior.
• Software Supply Chain Attack: A software supply chain attack targets the path software takes from source code to production. The attacker corrupts code, dependencies, build steps, or artifacts so that trusted delivery mechanisms spread malicious logic into environments that would otherwise reject direct intrusion.
• Secrets Scanning: Automated tooling that scans source code repositories, CI/CD pipelines, and cloud environments to detect exposed secrets such as API keys, tokens, and passwords before they are exploited.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.

What's in the full article

Cycode's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step comparisons of SAST, SCA, secrets scanning, DAST, and runtime methods for malicious code detection.
• Tool-selection criteria for CI/CD integration, false-positive management, and reporting workflows across developer and security teams.
• Examples of malicious code types and how each one behaves across source, dependencies, pipelines, and production.
• Practical guidance on staging scans across commits, pull requests, merges, and deployment gates.

👉 Cycode's full post covers detection methods, tool selection criteria, and SDLC scanning practices in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect access control decisions to the trust paths that software pipelines depend on.