Many teams believe that simply running code behind a firewall satisfies SOC 2, but the standard demands verifiable evidence of who executed what and when.
Understanding SOC 2 requirements for code execution
SOC 2 focuses on five trust service criteria, with security and availability most relevant to runtime activity. For code execution, auditors expect documented policies that define who may run which binaries, under what circumstances, and how each run is recorded.
Auditors require that privileged commands receive approval before they reach production systems, that teams protect sensitive data returned by those commands, and that teams detect any deviation from policy.
Evidence must be immutable, time‑stamped, and tied to an identity that can be traced back to a business purpose. Without a reliable audit trail, an organization cannot demonstrate that it enforces the principle of least privilege or that it can investigate a breach after the fact.
Where typical setups fall short
In many engineering groups, code execution is gated by a shared SSH key or a static service account password. Engineers check the key into repositories, copy it across servers, and share it among multiple engineers, eliminating per‑user distinction.
When a script runs, the process inherits the same credential, and the underlying platform logs only the system user, not the individual who initiated the command.
Even when organizations adopt modern identity providers and issue short‑lived tokens, they often present the token directly to the target host. The host validates the token, but the request bypasses any central point that could enforce additional controls.
Because the system cannot inject just‑in‑time approval, cannot mask credit‑card numbers that appear in query results, and cannot record the exact command sequence for later replay, compliance evidence remains incomplete.
The missing enforcement layer
The gap is a data‑path enforcement point that sits between the identity system and the resource being accessed. The identity (or setup) decides who may start a session and what scopes are attached, but it does not inspect the traffic, block dangerous operations, or capture a faithful record of the interaction. Without that gateway, any compliance evidence is limited to authentication logs, which do not satisfy SOC 2’s requirement for detailed execution audit.
How hoop.dev provides the required data path controls
hoop.dev is built as a Layer 7 gateway that intercepts every protocol request, whether it is a database query, a Kubernetes exec, an SSH command, or an HTTP API call. By placing the gateway in the data path, hoop.dev can enforce the controls that SOC 2 expects.
Setup – identity and least‑privilege grants
Engineers authenticate through an OIDC or SAML provider. The gateway reads group membership and token claims to decide whether a request may be initiated. Roles are defined with the minimum permissions needed for a specific task, satisfying the least‑privilege principle. This step alone does not guarantee compliance; it merely establishes who is allowed to start a session.
The data path – hoop.dev as the gateway
Once the identity is verified, the request is routed through hoop.dev before reaching the target system. Because the gateway sits on the wire, it can inspect the payload, apply inline masking to hide sensitive fields, and pause execution for a human approval when a command matches a risky pattern. The gateway never forwards credentials to the client, keeping secret material out of the engineer’s environment.
Enforcement outcomes – audit, masking, JIT approval, session recording
hoop.dev records every session in an audit log that includes the user identity, timestamp, full command stream, and any masking that hoop.dev applies. The log satisfies SOC 2’s evidence requirement for both security and availability criteria.
If a command attempts to exfiltrate data, hoop.dev can block it in real time, and hoop.dev captures the block event in the audit trail. When a privileged operation is flagged, a just‑in‑time approval workflow routes the request to an authorized reviewer; hoop.dev stores the approval decision and its context alongside the session record.
These outcomes exist only because hoop.dev occupies the data path. Removing the gateway would eliminate the audit trail, inline masking, and approval workflow, leaving only the initial identity check.
Getting started with hoop.dev
To align your code execution environment with SOC 2, begin by deploying the gateway using the getting started guide. Configure your OIDC provider, define role‑based access policies, and register the resources you need to protect. The open‑source repository on GitHub provides the full implementation and example configurations: Explore hoop.dev on GitHub. Detailed feature documentation is available in the learn section, where you can read about runtime governance, session replay, and inline data masking.
FAQ
Q: Does hoop.dev replace my existing identity provider?
A: No. hoop.dev consumes the identity token issued by your provider and adds a governance layer on the data path.
Q: Can I use hoop.dev with existing CI/CD pipelines?
A: Yes. The gateway works with standard clients, so pipelines can route their execution through hoop.dev without code changes.
Q: How does hoop.dev help during a SOC 2 audit?
A: It generates the per‑user, time‑stamped session logs, approval records, and masked data artifacts that auditors request as evidence of controlled code execution.
