When an ISO 27001 audit asks for proof that every piece of code run in production is traceable, you should be able to hand over immutable logs that show who initiated the execution, the exact command line, the time window, and any approvals that were required. The system grants privileged access only for the minimal period needed and never leaves sensitive data in clear text.
Why code execution needs ISO 27001 evidence
Control A.12.4 of ISO 27001 requires organizations to record and monitor system activity, especially actions that can alter data or affect service availability. For developers and automation agents that trigger scripts, containers, or server‑side code, the auditor looks for:
- Identity‑linked records of each execution request.
- Time‑stamped approval events for privileged commands.
- Full command‑level audit trails that cannot be edited after the fact.
- Proof that any secret values (API keys, passwords) are masked before they could be exposed in logs or output streams.
Teams find it difficult to meet these requirements when they rely on ad‑hoc SSH sessions, shared service accounts, or local scripts that bypass any central control plane.
Typical gaps in today’s code‑execution workflows
Many organisations let engineers log directly into production boxes with static SSH keys that are copied across dozens of servers. Scripts often run under a single privileged service account, and the output streams to the console without any filtering. In that model:
- There is no single source of truth for who ran what command.
- Approvals remain informal – usually a chat message or a verbal OK.
- Secrets appear in clear text in logs, screenshots, or terminal histories.
- If a breach occurs, reconstructing the exact sequence of actions consumes time, if it is possible at all.
These gaps prevent the organization from producing the audit artifacts ISO 27001 expects.
Required controls for compliant code execution
To close the gap, an organization needs a boundary that enforces:
- Just‑in‑time (JIT) privileged access that grants the minimum rights for the exact duration needed.
- Formal, auditable approval workflows before high‑risk commands are allowed to proceed.
- Session recording at the protocol level, capturing every request and response.
- Inline data masking that removes or redacts sensitive fields before they are stored or displayed.
- Immutable storage of these artifacts, tied to the identity that initiated the request.
When these controls sit on the data path – the point where traffic moves between the requester and the execution target – they become enforceable and observable.
How hoop.dev provides the necessary data‑path enforcement
hoop.dev acts as a Layer 7 gateway that proxies connections to code‑execution environments such as SSH, container runtimes, or custom command‑line tools. The gateway authenticates users via OIDC/SAML, reads group membership, and then decides whether to allow the request. Because the gateway sits in the data path, it applies the controls listed above on every interaction.
Specifically, hoop.dev:
- Issues a JIT grant that remains valid only for the requested command and expires automatically.
- Routes high‑risk commands to a human approver and records the decision.
- Records the full request‑response stream, creating a replayable session that includes timestamps and the caller’s identity.
- Applies inline masking rules so that secrets never appear in the stored logs.
- Writes all artifacts to a central store that the auditor can query and that hoop.dev manages.
Evidence artifacts generated for ISO 27001
When an execution request passes through hoop.dev, the system produces the following artifacts for the audit team:
- Identity‑bound session logs – hoop.dev tags each line of input and output with the user’s subject identifier and a UTC timestamp.
- Approval records – the approver grants or denies the request and hoop.dev records the exact time and the approver’s identity.
- JIT grant metadata – hoop.dev records the start and end times of the temporary privilege, the scope of the command, and the credential it uses.
- Masked output logs – hoop.dev replaces any field that matches a masking rule (e.g., passwords, API keys) before the log is persisted, ensuring that the audit trail does not expose secrets.
- Replay bundles – you can replay the package in a sandbox to reproduce the exact execution, which aids incident investigations.
hoop.dev guarantees completeness of these artifacts and prevents any user or host from altering them.
Using the artifacts in an ISO 27001 audit
An auditor requests the session logs for a given time window, filters by user, and verifies that every privileged command has a matching approval record. The JIT grant timestamps prove that the privilege existed only for the necessary period, satisfying the “least privilege” principle. Masked logs demonstrate that the organization protects secret data while retaining full auditability. Replay bundles let the auditor observe the exact behavior of the code without needing production access.
Getting started with hoop.dev
Deploy the gateway using the Docker Compose quick‑start, connect your execution targets, and configure OIDC authentication. The getting‑started guide walks you through the steps, and the learn section explains how to define masking rules, approval policies, and JIT windows. You can find all source code and deployment manifests in the public repository.
FAQ
How does hoop.dev ensure that logs cannot be tampered with after they are written?
hoop.dev writes each session record to a central store that only the gateway can reach. Because the gateway alone creates or modifies those records, any attempt to alter a log would require compromising the gateway itself, which the platform detects through integrity checks.
Can hoop.dev mask secrets that appear in command output in real time?
Yes. hoop.dev applies inline masking rules to the response stream before the data is persisted or returned to the requester, so sensitive values never appear in the stored audit trail.
Does hoop.dev replace my existing CI/CD pipeline?
No. hoop.dev sits in front of the execution environment. Your pipeline simply points its execution step (e.g., a kubectl apply or an SSH command) at the gateway endpoint, gaining the same audit and control benefits without changing the build logic.
