Visual Code Space
A visual code space is a cloud container that runs your code editor in a browser. You set it up by linking a source repo to a remote virtual machine. Teams use this setup to give every developer the same build tools and runtime packages. Still, teams often grant these remote containers broad cloud roles and static database keys. When a container holds wide permissions, one bad script can drop tables or leak data. How a visual code space works in your team The setup starts with a base image fi
Infrastructure as Code Security Scanning: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A visual code space is a cloud container that runs your code editor in a browser. You set it up by linking a source repo to a remote virtual machine. Teams use this setup to give every developer the same build tools and runtime packages. Still, teams often grant these remote containers broad cloud roles and static database keys. When a container holds wide permissions, one bad script can drop tables or leak data.
How a visual code space works in your team
The setup starts with a base image file stored inside your source control repo. This file lists the operating system, runtime versions, and editor extensions your app needs. When a developer starts work, the cloud host spins up a fresh virtual machine. It pulls your code, installs the listed tools, and opens the editor window. Your local laptop only renders the screen and sends keystrokes over the network. All heavy builds, tests, and scripts run inside that remote cloud machine.
To run the app, the remote container needs to talk to other cloud services. Teams usually load secret keys into the container through user settings or repo store secrets. Some teams attach an identity role directly to the virtual machine host. The container then uses these keys or roles to reach test databases and storage buckets. Every terminal tab inside the editor inherits these exact same permissions and keys.
What native container roles solve and what they miss
Native container roles and repo secrets solve the cold start problem for new developers. A new hire can open a browser and start coding in just a few minutes. They do not need to install local database drivers or fix broken path variables. Platform teams can also update the base image file to push new tools to everyone. When the developer stops working, the cloud host shuts down the machine to save money.
Still, this setup leaves a major gap during daily work. Container roles and stored secrets only check who starts the machine or opens a session. Once the container connects to a database, the native role does not inspect live traffic. It cannot tell a safe read query from a command that deletes rows. Also, any extension or package running inside the workspace can read those stored database keys. If a bad package runs in the background, it can copy keys and query sensitive data. Raw query results with emails, phone numbers, card numbers, or national IDs flow right into the container.
Infrastructure as Code Security Scanning: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Securing data access from remote dev containers
To close this gap, teams must separate code editing from direct database credential storage. Developers need to run code in the cloud without holding raw database keys in memory. Security teams also need a clear log of every command and query run from a workspace. Instead of giving the container a broad network route, teams should check each request in flight. Filtering results so masking rewrites matched fields in results also keeps sensitive records out of dev logs.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How do developers store database keys in a remote workspace?
Teams often use built-in repo secret stores to load keys as variables at startup. While easy to set up, any tool or script in the container can read those plain values.
Can a malicious editor extension steal cloud credentials from a container?
Yes, extensions run with the same user rights as your terminal inside the remote machine. They can read local files, inspect memory variables, and use active network sessions.
How can teams protect sensitive data when developers test against shared databases?
Teams should avoid placing raw production data into shared test databases whenever possible. For live checks, use data masking that rewrites emails, card numbers, and phone numbers in query results.