Beyond the Perimeter: Runtime Visibility for AWS Lambda

The industry has a snapshot problem. Static analysis and SCA tools tell you what might happen based on a manifest, but once a function is triggered, the execution environment becomes a black box. For most security teams, Lambda security is a “hope for the best” strategy.

The “Old Way” relies on coarse-grained IAM policies and VPC flow logs that lack process-level context. The Upwind Way recognizes that serverless is still execution. By moving security into the runtime, we stop guessing about “potential” vulnerabilities and start seeing actual behavioral risks as they happen.

The Questions Your Current Stack Can’t Answer

If you aren’t monitoring the execution hook, you’re missing the signal required to answer:

• Is the execution wrapper being bypassed? Monitoring if a compromised runtime is spawning unauthorized sub-processes.
• What is the destination of this specific egress? Mapping process-level network calls to specific external IPs, beyond basic VPC flow logs.
• Is the vulnerable code path actually being executed? Eliminating the noise of CVEs that exist in a layer but are never loaded into memory.
• What is the actual blast radius of a leaked credential? Connecting runtime execution behavior to identity-based lateral movement.

Technical Implementation: The Upwind Lambda Tracer

We’ve introduced Direct Tracer Reporting, an instrumentation model designed for architectural flexibility. Rather than forcing all telemetry through a centralized Cluster Manager, functions can now report directly to the Upwind backend.

Wrapper-Based Instrumentation

By utilizing a dedicated Lambda Layer and the AWS_LAMBDA_EXEC_WRAPPER variable, Upwind hooks into the runtime initialization. This allows us to capture:

• Process Lineage: Every execution fork and system call within the transient environment.
• Network Telemetry: Identifying egress at the process level, providing the “who” and “how” behind every connection.

Architectural Neutrality

We recognize that VPC-connected functions have different requirements than those running in the AWS public space.

• Direct-to-Backend: Optimized for functions outside a VPC or for teams looking to avoid the overhead of managing regional proxy clusters.
• Cluster Manager Support: Remains the standard for high-security, VPC-restricted environments requiring local data aggregation.

Optimized for Modern Runtimes

We support all major AWS runtimes—Node.js, Python, Java, .NET, and Ruby. Whether you deploy via ZIP archive or Container Image, the instrumentation is handled at the configuration level, requiring zero changes to your application’s source code.

Reducing the “Noise Tax”

Security overhead isn’t just about millisecond latency; it’s about the cognitive load of 5,000 alerts. By correlating static vulnerabilities with runtime telemetry, Upwind filters out the “dead code.” If a critical CVE is present in your Python environment but the tracer confirms the vulnerable package is never imported during execution, the risk is real, but the priority is low.

The Result: Your engineers stop chasing ghosts and start fixing the 5% of vulnerabilities that are actually reachable and exploitable in production.

See It In Action

Serverless environments shouldn’t be security blind spots. With Direct Tracer Reporting, you get process-level visibility and behavioral mapping without refactoring your code. It’s about getting the runtime signal you need to defend your functions in real-time, at the scale of modern serverless infra.

If you’d like to see how this feature fits into your environment – or to explore how Upwind can help you prioritize and remediate risk more effectively – schedule a customized demo with us. We’ll walk through your use cases, integrations, and security goals to show how Upwind delivers actionable cloud security at scale.