Effective AppSec must move beyond source code

The tech world is abuzz with the potential of AI-assisted and automated software development. But at the same time, this acceleration has created a sharp rise in regulatory scrutiny and risk to the software supply chain. While many organisations still rely heavily on source code scanning, focusing on code alone leaves a growing malware blind spot. Modern applications are assembled from binaries, third-party packages, container images and, increasingly, AI models—not just written line by line.

 

If you only secure what your developers write, you’re missing the actual targets that attackers exploit. To reconcile the tension between release speed and security, organisations must focus on binaries.

 

Insufficient for supply chain security

Source code represents intent; binaries represent reality. Once code enters the CI/CD pipeline, it’s transformed by build systems, dependencies, plugins and configuration files. Vulnerabilities or malicious behavior can be introduced well after code is committed, whether through compromised build scripts, poisoned dependencies or tampered artifacts.

 

Traditional AppSec approaches have emphasised “shift left” practices such as static application security testing (SAST). These techniques are still valuable, but on their own they leave gaps. Many of today’s most disruptive supply chain incidents start with third-party components or in the compiled outputs that ultimately reach production. Without visibility into those binaries, you’re basically securing a blueprint rather than the finished structure.

 

Better vulnerability prioritisation

As the number of vulnerabilities continues to grow, they’re easily outpacing most teams’ ability to remediate them. When you treat every vulnerability as equally urgent, it leads to alert fatigue and an inefficient use of security resources, which are often scarce to begin with.

 

Context-aware prioritisation changes the game in this sense. By understanding whether a vulnerability is actually reachable or exploitable within a specific app, teams can focus on the small subset of issues that represent the real risks. Going a step further, analysing configuration, transitive dependencies, and runtime context provides a more accurate picture of where exposure risks are, helping security and development teams align on what truly needs to be fixed.

 

This type of contextual intelligence is increasingly being built into modern AppSec platforms, allowing teams to move from raw vulnerability counts to risk-based decision-making.

 

Stopping malware before the SDLC

The recent string of attacks, which primarily target the npm registry, proves that the "front door" of your development environment is the primary gateway for risk. If a developer pulls a malicious package, the attack succeeds before the code is even scanned.

 

This means preventive controls at the point of consumption are critical. Verifying requested packages, plugins, models, and extensions against your organisation’s policies can stop known malicious or suspicious components before they enter the development lifecycle. So, rather than reacting after the fact, organisations can significantly reduce risk by preventing entire classes of attacks from ever taking hold.

 

A single system of record for AppSec

Fragmented tools create what many refer to as a "crisis of trust." When security is bolted on after the fact rather than native and embedded throughout the lifecycle, it ultimately slows down your release velocity.

 

It sounds simple, yet it’s effective: combining artefact management and security signals within a single system of record gives teams continuous, automated governance. This means policies can be enforced consistently across repositories and pipelines, audit readiness becomes ongoing rather than a last-minute scramble, and both security and DevOps teams work from the same source of truth.

 

The result? Stronger security with less disruption to development workflows.

 

AI, transparency and emerging regulation

AI and machine learning are arguably the most disruptive technologies since the smartphone, but they require unprecedented transparency. Models, training data and dependencies are increasingly treated as software artefacts, bringing them squarely within the realm of supply chain security.

 

Regulatory frameworks such as the EU AI Act illustrate what’s at stake with potential penalties reaching up to 6% of global revenue for non-compliance. Meeting these requirements demands greater transparency, traceability and governance across both traditional software components and AI assets.

 

Preparing for the software supply chain

If it’s not obvious by now, securing modern software requires more than a standalone code scanner. It calls for an end-to-end, DevSecOps-oriented approach that’s binary-aware, focused on the supply chain and integrated directly into how artefacts are built, stored and promoted.

 

Combining artefact management with native security capabilities turns security into an enabler of speed rather than a blocker. More broadly, organisations that align AppSec with the realities of today’s software supply chain are better positioned to ship faster without sacrificing trust, compliance or resilience.

 

And that’s a win for both DevSecOps teams on the ground as well as for the business as a whole.

 

---

 

Eyal Dyment is VP of Product, Security at JFrog

 

Main image courtesy of iStockPhoto.com and MTStock Studio