Git Hub Code Spaces
You set up git hub code spaces by defining a container file in your repo. This file starts a cloud virtual machine with your code and tools ready. Engineering teams use these cloud workspaces to skip local machine setup. Still, teams often grant broad database and cloud keys to these remote containers. When permissions are too wide, any script in the workspace can change live data. How git hub code spaces work in your workflow A cloud workspace runs inside a dedicated virtual machine hosted b
AWS Security Hub + Infrastructure as Code Security Scanning: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up git hub code spaces by defining a container file in your repo. This file starts a cloud virtual machine with your code and tools ready. Engineering teams use these cloud workspaces to skip local machine setup. Still, teams often grant broad database and cloud keys to these remote containers. When permissions are too wide, any script in the workspace can change live data.
How git hub code spaces work in your workflow
A cloud workspace runs inside a dedicated virtual machine hosted by the platform. When a developer opens a branch, the platform reads the container setup file. It builds a fresh container image with the right language runtime and extensions. The developer then writes code through a browser or a local editor link.
To run an app, the container needs secrets like API keys and database passwords. Teams store these secrets in user settings or repo settings. When the virtual machine boots, the platform places those secrets into workspace variables. The platform also creates a temporary token so the workspace can push code back.
Network rules control how ports inside the container talk to the outside world. A developer can forward a web port to test an app in a browser. They can keep that port private or share it with other team members. Admin rules at the org level can limit which machine sizes developers pick. Admins can also restrict which base images a project is allowed to pull.
What native workspace rules solve and what they miss
Native workspace settings solve the problem of slow local setup and machine drift. Every person on the team gets the exact same compilers, libraries, and linters. Admins can stop untrusted repos from reading org secrets during a build. They can also set idle timeouts so stopped machines do not waste money.
Still, native container rules leave a big gap during daily work. Once a secret lands inside the workspace, every process in that container reads it. A third-party extension or a bad package install can read those same variables. The platform checks who starts the machine, not what commands run inside it.
AWS Security Hub + Infrastructure as Code Security Scanning: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
This gap grows when developers link cloud workspaces to staging or live databases. Teams often hand out shared database passwords so developers can debug real issues. Native workspace logs show when a machine started, not which SQL queries ran. They cannot block a bad drop statement or rewrite emails and card numbers.
How to reduce risk in cloud dev containers
Start by scoping repo secrets to the smallest possible role in your cloud. Never put admin database passwords or root cloud keys into workspace secret stores. Split your secrets by branch or task so test workspaces only touch test data. Review third-party editor extensions before adding them to your shared container setup file.
Next, tighten how the workspace talks to internal data stores and cloud services. Instead of static passwords, require developers to log in per session with short roles. Check every query and command in flight rather than trusting the whole container. Mask sensitive fields like phone numbers and national IDs when results return to the workspace.
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 secrets get into a cloud workspace?
Admins or users save encrypted secrets in their account or repo settings. The platform loads these values as variables when the container starts up.
Can editor extensions read workspace secrets?
Yes, extensions running inside the remote container share the same user permissions. They can read local variables and files just like your own app code.
Do stopped workspaces keep their local file changes?
A stopped workspace keeps your uncommitted files on its attached cloud disk. Still, if the workspace is deleted after a timeout, unpushed work is lost.