The Security Imperative: Trust, Speed, and Integral Defense

The systemic nature of software supply chain attacks is growing more complex, creating a critical tension between speed and security.

The Israeli National Cyber Directorate’s (INCD) recent “Breaking the Chain” report validates that the most significant threats live outside your first-party code, highlighting a crisis of trust in the open-source-software (OSS) supply chain.

While the emerging breakthroughs in agentic AI defense are a fantastic and welcome advancement for code security and quality, the INCD report serves as a critical reminder that security must span the full software supply chain, be native and integral to the software delivery process, and focus on the binary to truly reconcile the organizational struggle between speed vs. security.

JFrog’s Stance on Security: End-to-end. Native. Advanced.

JFrog’s philosophy centers on three principal outcomes: ensuring developer productivity, allowing development teams to ensure every software release can be trusted, and making the overall security management process easy to manage. These outcomes effectively address the speed vs. security paradox, enabling teams to achieve both. So, what does it actually take to get there?

Three Pillars of Defense

First, security must span the full software supply chain, end-to-end.

Why? Security isn’t a single point-in-time check; it’s a continuous effort from the moment source code is written until the artifact is deployed in production. This necessitates context and feedback from across the entire artifact lifecycle. An E2E approach provides the single source of truth required to manage risk globally, ensuring compliance and providing the necessary control and traceability across the entire pipeline.

Second, security needs to be natively integrated into the software delivery process – not bolted-on.

Why? Reactive, external security tools introduce friction, slow time-to-market, and simply can’t provide the necessary visibility needed for effective governance. By enforcing policy and continuously scanning within a single platform, compliance and trust are automatically built during the pipeline execution, not checked after the fact. This ensures policy is enforced at every automated gate, turning security into an enabler of velocity, rather than an impediment.

Third, your security architecture should be binary-focused and research backed.

Why? The compiled artifact—the binary—is the key target for attackers. Relying solely on source code scanning creates a critical blind spot, missing vulnerabilities introduced later in the CI/CD process through malicious build scripts or corrupted dependencies. By enforcing policy and continuously scanning the binary artifact, trust is automatically built into the pipeline execution. Your security strategy should also be backed by reliable research. For instance, JFrog has a dedicated team of security engineers and researchers who are solely committed to advancing software security through the discovery, analysis, and exposure of new vulnerabilities and attack methods. Add something about our security research here.

INCD’s Core Security Challenges

The findings from the recent INCD report, “Breaking the Chain: How Supply Chain Attacks Target Package Managers”, provide crucial external validation for why an integral security approach is required.

Challenge 1: CI/CD Pipelines and the Automated Pathway for Risk

CI/CD pipelines automate the entire software lifecycle from development to deployment, aiming to enable the rapid delivery of high-quality code. However, given the close relationship between development, package management, and these automated processes, this pipeline serves as the primary gateway for risk to enter the organization. The INCD’s analysis underscores that bad actors target compromised third-party components to gain entry and a foothold into organizations’ infrastructure, often bypassing traditional perimeter defenses.

Challenge 2: The Crisis of Implicit Trust and Language-Specific Managers

There’s systemic risk rooted in the implicit trust placed in package registries and their hosted packages, significantly expanding the organizational attack surface. The scale is immense: according to the report, “The top 15,000 PyPI packages are collectively downloaded more than 83 billion times per month.” A compromise of a single transitive dependency could have an enormous impact.

The report also details how Language-Specific Package Managers (such as npm, pip, and Maven), unlike more controlled operating system managers, typically lack rigorous central maintenance and approval processes; developers can push updates directly to these ecosystems without manual oversight. This flexibility accelerates innovation but inherently increases exposure to security risks.

Challenge 3: The Malware Blind Spot of Traditional Tools

The failure of traditional security tooling to detect actual malware is another major struggle identified in the defense landscape. Existing tools like Static Application Security Testing (SAST) and Software Composition Analysis (SCA) are primarily designed to find known vulnerabilities, unsafe coding patterns, or logic errors.

On their own, these tools have a functional gap in behavioral analysis: they do not focus on detecting unusual behavior or other indicators that would reveal malware. This deficiency creates a critical window where sophisticated, zero-day supply chain attacks, such as the XZ Utils backdoor incident, can thrive.

Observed Adversary Tactics

The INCD report also helpfully details common tactics that exploit the lack of E2E control and reliance on implicit trust:

• Credential and Identity Compromise: This category includes Project Access Token Hijacking / Account takeover, where attackers exploit leaked credentials or phishing to gain control of a maintainer’s account and publish malicious code. It also includes Gaining Repository Contributor Permissions, where an adversary cultivates the trust of project maintainers over time to gain write access and inject malicious code, as was observed in the XZ Utils backdoor incident.

• Name Exploitation: This includes Typosquatting (mimicking legitimate package names with typographical errors) and Brandjacking (replicating characteristics of well-known company packages) to trick developers into installing malicious code.

• The AI-Native Threat (Slopsquatting): Attackers leverage Large Language Models (LLMs) by publishing malicious packages with names that LLMs hallucinate or generate, corresponding to non-existent packages, which increases the risk of compromise within organizational environments.

• Configuration and Trust Abuse: This involves Dependency Confusion, where insecure build systems prioritize a public, malicious package (often with a higher version number) over the intended internal one. It also includes Manifest confusion (npm), where the manifest (metadata displayed publicly) is uploaded separately from the package tarball, and the actual metadata and installation scripts inside the tarball are not validated against the manifest, misleading users and automated tools.

INCD Recommends Multi-Layered Software Supply Chain Security

To mitigate these threats, the INCD report recommends implementing a multi-layered approach. The JFrog Software Supply Chain Platform delivers this defense by operationalizing the three core pillars: E2E, native/integrated, and binary-focused.

Pillar 1: End-to-End Coverage and Governance

This pillar ensures continuous security and control across the entire artifact lifecycle, addressing governance gaps and compliance mandates identified by the INCD.

• Proactive Curation and Policy: JFrog Curation reinforces E2E control by restricting developers to building with dependencies only from approved, trusted virtual registries. This prevents threats like Typosquatting, Slopsquatting, and Dependency Confusion from ever entering the environment, adhering to INCD recommendations for implementing strict Change Management and Testing every new package in a controlled environment.
• Supply Chain Transparency: JFrog Xray natively supports generating comprehensive Software Bill of Materials (SBOMs), a critical INCD recommendation for supply chain transparency and rapid response to emerging threats.
• Identity and Threat Governance: JFrog Advanced Security extends E2E coverage by providing essential governance, including leveraging NIST SP 800-204D guidelines. This includes using secret scanning tools to monitor for exposed credentials (addressing Account Takeover threats) and enforcing the Principles of Least Privilege for both human users and Non-Human Identities (NHIs), which mitigates risk and limits the spread of malicious code.

Pillar 2: Native and Integrated Security

Achieving velocity without friction requires security to be structurally integrated, not bolted-on.

• Native Enforcement: JFrog Curation acts as the crucial first line of defense, directly addressing the “implicit trust” problem inherent in public registries. By making policy enforcement native & integral, malicious and risky packages are stopped at the door. This structural approach ensures that compliance and trust are automatically built during the pipeline execution.
• Integral Tooling: The JFrog Platform supports core tooling required by DevSecOps, including leveraging NIST SP 800-204D guidelines for integrating software supply chain security, which includes the recommended use of SAST (available in Advanced Security) and SCA (Xray).

Pillar 3: Binary-Focused Architecture

This pillar ensures protection is applied to the artifact itself—the key target for attackers—covering the source code blind spot.

• Continuous Artifact Scanning: JFrog Xray ensures continuous security by scanning everything inside the compiled artifact. This binary focus provides full integrity checks for the attacker’s target.
• Contextual Analysis: Xray provides transitive & contextual analysis so security teams focus their finite efforts effectively, prioritizing only vulnerabilities that are applicable or exploitable in the context of the running code base, thereby reducing noise.

A Note on Agentic Security Scanners: Advantages and Limitations

The introduction of LLM-powered security researchers represents a powerful step forward in application security. These tools move beyond traditional scanning by leveraging large language model (LLM) reasoning to understand code behavior like a human expert.

While these agentic tools are a necessary addition to the toolbox for improving first-party code quality, they are limited in scope and operate too early in the development cycle to stop the systemic supply chain risks outlined by the INCD.

The Promise—Where LLM-Powered Tools Excel:

• Enhanced Code Analysis: LLMs can analyze vast amounts of code with remarkable speed, potentially identifying subtle patterns and vulnerabilities that traditional SAST tools might miss.
• Improved Developer Experience: By integrating into development workflows, LLMs can provide real-time feedback, helping developers write more secure code from the outset. Furthermore, AI usage is growing in popularity, and developers are more likely to adopt it over other, more intrusive solutions.
• Augmentation of Existing SAST: When used alongside existing SAST tools, LLM scanners can provide an additional layer of scrutiny and insight, enhancing overall code security. It’s recommended to run them in parallel with established SAST solutions until their efficacy and trustworthiness are fully validated.

The Limitations—Where Systemic Risk Persists:

1. They’re Source-Code Centric: Agentic LLMs primarily focus on the code after it’s written and committed to a repository. They don’t manage the binary artifacts themselves.
2. They Miss the Ingress Point: The most critical attacks target the front door—the package registry. If a developer pulls a malicious package via a technique like typosquatting, that package is now inside your organization. The attack has succeeded before the code is even ready for an LLM to scan.
3. They Lack Binary Governance: They don’t provide the end-to-end visibility required to track, secure, and govern the compiled artifact throughout its distribution and deployment lifecycle—a capability vital for true supply chain security.

Shift left tools are necessary for early detection and lower remediation costs, and it’s exciting to see new agentic technology emerging in this space. We encourage teams to take full advantage of these tools, but to do so responsibly—using them alone is extremely risky as you’re ignoring a vast span of attack surface.

Securing the Software Supply Chain with E2E, Integral, Binary-Focused Protection

The path to fast, trusted releases is clear: to achieve robust software integrity and reconcile the speed vs. security dilemma, organizations must adopt the architectural foundation of the three core pillars: security that is end-to-end, native and integrated, and binary-focused.

While powerful new AI tools offer valuable complementary insights, only a centralized platform can provide the necessary governance, control, and binary protection required to secure the modern software supply chain.

Ready to build a truly secure software supply chain without sacrificing speed? To explore the capabilities of the JFrog Platform, start a free trial or schedule a demo today.