Secure Code Conversion: Why Your Source Code Shouldn't Leave Ephemeral Containers

Your source code is your company's most valuable intellectual property. Every line represents design decisions, business logic, competitive advantages, and years of accumulated engineering effort. When you send that code to a conversion tool, you're trusting that tool with your crown jewels.

Most teams don't think hard enough about what happens to their code during conversion. They should.

The Threat Model

Code conversion involves three data states, each with distinct risks:

Data in transit. Source code traveling from your repository to the conversion service. Risk: interception. Mitigation: TLS encryption, VPN tunnels, or private network connections.

Data at rest. Source code stored on the conversion service's infrastructure. Risk: unauthorized access, data breach, regulatory violation. Mitigation: encryption at rest, access controls — or better yet, don't store it at all.

Data in processing. Source code loaded into memory for conversion. Risk: cross-contamination between customers, retention in logs, inclusion in model training data. Mitigation: isolated processing environments, ephemeral containers, explicit no-training policies.

Why Ephemeral Containers Matter

An ephemeral container architecture eliminates the "data at rest" risk entirely. Each conversion job runs in its own isolated container. When the job completes, the container is destroyed — along with every copy of the source code, converted output, and intermediate data.

There's nothing to breach because there's nothing stored. There's no cross-customer contamination because containers don't share state. There's no lingering copy in a temp directory or log file because the entire filesystem is gone.

Contrast this with pasting your proprietary source code into a general-purpose LLM chat interface. That conversation may be logged, may be used for model training, may be accessible to the provider's employees, and persists indefinitely unless explicitly deleted.

The Training Data Question

This deserves its own section because it's the question security teams ask first: is my code used to train or fine-tune models?

For any code conversion service you evaluate, the answer must be an unambiguous "no." Your code should be processed, not learned from. The conversion should use pre-trained models via API calls, not custom training. There should be no feedback loop where your code improves the service's capabilities for other customers.

Compliance Implications

SOC 2 Type II. Requires demonstrable controls for data security, availability, processing integrity, confidentiality, and privacy. Ephemeral processing with no data persistence simplifies the compliance story significantly.

GDPR. If your code contains personal data references (hardcoded names, email addresses, test data), processing it in a jurisdiction-compliant manner matters. Ephemeral containers that are destroyed immediately after processing create minimal GDPR surface area.

HIPAA. Healthcare organizations converting code that processes PHI need assurance that the code itself (which may contain schema definitions, field names, and processing logic that reveals data structure) is handled with appropriate controls.

Your Evaluation Checklist

Before sending source code to any conversion service:

1. Where is my code processed? Look for specific answers (AWS Fargate in us-east-1), not vague ones ("the cloud").
2. How long is my code retained? The best answer is "zero seconds after processing."
3. Is my code used for model training? The only acceptable answer is "no."
4. Are jobs isolated from each other? Look for container-level or VM-level isolation.
5. What logs are retained? Metadata (job ID, file count, duration) is fine. Source code in logs is not.
6. What certifications do you hold? SOC 2, ISO 27001, and relevant industry certifications.

B&G CodeFoundry runs every job in isolated Fargate containers that are destroyed after processing. No data persistence, no training on user code, and code never leaves the ephemeral processing environment.

---

References: OWASP Secure SDLC guidelines; NIST SP 800-190 (Container Security); SOC 2 Type II framework; GDPR Article 5 (purpose limitation and storage limitation).