Product Security Jan 19, 2026 8min read

Application Security Beyond the Source: What Compiled Code Really Reveals

Modern application security programs are built on scanners.

Static Application Security Testing (SAST), Software Composition Analysis (SCA), and similar tools watch pull requests, repositories, and pipelines. They analyze source code, dependency manifests, and known common vulnerabilities and exposures (CVEs) to keep vulnerabilities from reaching production. Tools like Snyk, Checkmarx, Veracode, and others are now standard in AppSec and DevSecOps workflows.

They also look at only the visible part of your attack surface.

What actually runs in production is not your Git repo but a compiled and linked artifact: a container image, a firmware package, a mobile app build, a fat (Java ARchive) JAR, or some other binary. During the build, linkers and toolchains make thousands of decisions that change what ends up inside that artifact. Those decisions quietly reshape your real attack surface, often in ways that conventional AppSec tools never see.

This is the gap below the surface of the iceberg: source-focused AppSec tools watching the surface, while binary code beneath the waterline quietly defines real exposure. NetRise surfaces that deeper layer.

Where Application Security Tools Stop

Many AppSec programs anchor on three categories of tooling:

SAST that inspects source code for security flaws that can become vulnerabilities.
SCA that parses manifests and package managers to find vulnerable open-source dependencies.
Source-centric Continuous Integration (CI) checks that look at the repository and build configuration before artifacts are produced.

These tools excel at answering a specific set of questions:

What security flaws exist in the source code and dependencies we intend to ship?
Which third-party packages in our manifests have known CVEs?
Which lines of code introduce high risk like broken access control or SQL injection among the OWASP Top Ten?

They rarely answer the deeper question:

What exactly ended up inside the artifact that is actually shipping?

Because SAST and SCA mostly operate on source and metadata, their view is shaped by the contents of your repo and dependency manifests, the package versions reported by your build system, and the files those tools are designed to parse as text.

Anything that happens during or after the build, such as static linking, vendoring, generated code, environment sourced libraries, or firmware packaging, sits below their line of sight.

Attackers know that. They focus on the parts of your software that you are not scanning.

What Lives Beneath Source Scanning

Every software artifact contains more than the code your AppSec tools see in Git or in your IDE. Inside compiled firmware images, application binaries, and containers, NetRise routinely finds:

Components that silently changed during the build
A library that appears as version 2.1.4 in your manifest might be pulled as 2.0.0 from a cached dependency or compiled from a vendored copy buried in a subdirectory. The artifact contains the older, vulnerable version even though your SCA report looks clean.

Misconfigurations frozen into compiled services
Default credentials, insecure protocol settings, and weak Transport Layer Security (TLS) options are often introduced through configuration files and build scripts, then baked into the image. Source scanning may never see the rendered configuration that the process actually uses at runtime.

Secrets and credentials embedded in binaries
API keys, access tokens, and passwords that were meant to be temporary can end up hard-coded in binaries or config artifacts. Standard SAST and SCA workflows, tuned for source and manifests, often miss secrets that were injected late in the build or inherited from base images.

Exposed cryptographic material
Public and private keys, certificates, and trust stores sometimes ship together inside a firmware or application image. These combinations might never show up in your source repo in the same form, but they exist in the compiled artifact that attackers can extract and analyze.

When SCA Says “Safe,” but the Artifact Is Not

The OpenSSL 3.0.0 case NetRise documented for a widely used network operating system is a clear example. The vendor’s own package manager showed OpenSSL 3.0.7 and current shared libraries. SCA tools that relied on that metadata reported a safe posture.

Binary analysis told a different story.

NetRise found OpenSSL 3.0.0 statically embedded inside multiple Python modules on the device. Those modules were built against an older OpenSSL version and carried that code forward, even after the system libraries were updated. Vulnerabilities associated with OpenSSL 3.0.0 could still be exploited through those modules, despite every manifest and package query saying the system was up to date.

From an AppSec perspective, this is more than a firmware problem:

Your SAST pipeline can scan the Python code and still never see which OpenSSL version it will bind to in the compiled artifact.
Your SCA report can list only OpenSSL 3.0.7, because that is what the package database exposes.
Your AppSec dashboards will show “secure,” while production binaries still contain vulnerable code.

The pattern repeats with vendored dependencies, statically linked libraries, and generated code across languages and frameworks. The lesson is the same:

Source-focused tools see only the visible portion of your attack surface. The true attack surface includes everything the compiler and linker pulled into your binaries.

Case in Point: F5 and the Cost of Blind Spots

The F5 BIG-IP incident showed how dangerous invisible software risk can be for even the most mature software supply chain security programs.

F5 appliances sit in front of some of the world’s largest networks. Their software is routinely scanned, monitored, and patched by customers who depend on those systems for load balancing, security, and availability. Yet state-sponsored attackers were able to maintain long-term access to the BIG IP product development environment and engineering platforms before the intrusion was discovered and disclosed. During that time they extracted source code and internal vulnerability research, including information about flaws that were not yet public.

When F5 announced the incident, it also released fixes for dozens of vulnerabilities across BIG IP and related products in a single coordinated update. The market reaction was immediate, with a sharp drop in share price and renewed scrutiny on how a single vendor’s software can impact the risk profile of hundreds of thousands of devices.

As highlighted in KuppingerCole’s From Scare to Insight discussion of the F5 attack, the episode reinforces a few points for AppSec and software supply chain teams:

Dwell time is a visibility problem. If you cannot see what is changing in build systems, firmware images, and release artifacts, it is hard to detect when attackers start to tamper with your software.
The supply chain can be weaponized. Access to source and unpublished vulnerability data gives adversaries a head start in building targeted exploits.
Vendor risk becomes your risk. You run the software, you carry the exposure. Without visibility into what vendors actually ship, you inherit hidden vulnerabilities you never had a chance to see.

NetRise approached the problem from the artifact side. By analyzing released BIG IP firmware, NetRise could identify vulnerabilities, reachable components, and misconfigurations that customers would never see through source-focused tools or OS scanning alone. The lesson for AppSec is straightforward. It is not enough to secure what the repository shows. You also have to understand what the build produced and what actually runs.

NetRise Is the Last Mile for AppSec

If you are responsible for application security, you do not need another scanner that looks at the same inputs. You need a way to validate that the security posture reflected in your pipeline actually matches the software that ships.

NetRise closes that loop by:

Starting from artifacts, not just repos

NetRise ingests firmware images, application binaries, containers, and other packages from any vendor or build system. It treats the artifact as the source of truth and works backward to identify components and dependencies.

Deep coverage of embedded components

Using binary composition analysis, NetRise detects statically linked libraries, vendored code, and transitive dependencies that never show up in manifests. This produces a software inventory grounded in what is actually present in the artifact, not what is declared.

Finding weaknesses beyond known CVEs

NetRise ZeroLens analyzes compiled code for security flaws in source code (CWEs) that may not yet have assigned CVEs. That lets AppSec teams act on high-risk flaws before they become headlines.

Understanding provenance and contributor risk

NetRise Provenance adds context about where code originates, how securely it is maintained, and whether maintainers, contributors, or ecosystem practices expose risk. By mapping packages to canonical source repositories and contributors, and enriching them with risk signals and dependency relationships, AppSec teams can decide which components to trust, deprecate, or monitor closely when a library or contributor is implicated.

Uncovering secrets, keys, and misconfigurations

NetRise inspects binaries and embedded artifacts for hard-coded secrets, sensitive configuration, and cryptographic material that is stored or packaged in ways attackers can easily extract and reuse.

Showing which components actually execute

Not every vulnerable component in an artifact is reachable or exploitable. NetRise adds execution context, highlighting components that load at startup or expose network-reachable paths, so teams can prioritize the issues that translate into real risk.

Verify, Then Trust: A “Better Together” Model for AppSec

SAST, SCA, DAST, and IAST are not going away, and they shouldn’t. They’re core to how you design, build, and test software. NetRise strengthens the layer they all depend on: trust in the software that actually ships.

Paired with NetRise, your AppSec stack moves from assuming artifacts are accurate to verifying them with compiled code evidence. You keep the same workflows, but anchor their outputs in what is really inside your images and binaries.

Integrated into existing pipelines and review processes, NetRise helps teams close the loop between what the repo says and what the artifact contains. Security and engineering leaders gain a clearer view of exposure, grounded in the software that runs in production.

This combined approach delivers:

Alignment between reports and reality
Validate that dependency versions in SCA reports match what is compiled into artifacts.
More accurate coverage of your software supply chain
Catch hidden libraries and vendored components that would never appear in manifests.
Richer signal on sensitive material
Detect secrets, misconfigurations, and weak cryptography baked into images.
Stronger footing in vendor and SBOM reviews
Provide evidence when you challenge a vendor’s SBOM or security advisory.
More defensible risk conversations
Give leadership a clearer view of where risk truly resides in the applications you ship and run.

Seeing the Whole Iceberg

Your software and device stack is larger, older, and more opaque than most teams realize. SAST, SCA, and test dashboards illuminate only the visible portion of the attack surface. NetRise reveals the rest, the binary artifacts and hidden components your scanners cannot see.

The next generation of application security will depend on what can be verified, not just what manifests, SBOMs, and build logs declare. As pressure around software transparency and secure-by-design grows, the teams that pair traditional AppSec tooling with binary evidence will have the most defensible view of risk.

You cannot secure what you cannot see. With NetRise, you finally see what actually ships in your applications and devices.