Security FAQ
Direct answers to the questions security reviews ask most
The questions below come up in nearly every enterprise security review. Each answer links to the section that covers it in full.
Can any StarSling employee access our source code, API keys, credentials, or environment variables?
Secrets, API keys, environment variables, and build artifacts: no — by architecture, not by policy. GitHub injects secrets and environment variables directly into the runner at job time, and artifacts upload directly to GitHub's storage. None of it reaches StarSling's control plane or database, so there is no stored copy for an employee to read and no access control that could be misconfigured to expose one.
Two qualifications, stated plainly rather than left for you to find:
- The runner itself is our machine. Secrets are in memory and on disk on the VM while your job runs. What protects them there is that the machine is single-use and destroyed with the job, not that the values never arrived. The architectural claim above is about our control plane, not about the runner.
- Printed values are a different question from injected ones. Anything your workflow echoes to the console is part of the job log we retain — see the console-log note below.
Source code and job data: only through a named, audited support path. Platform administrators can open a support session against your account to answer a support request. That session is a real session with your account's permissions — it is granted so an engineer can reproduce what you are reporting, not restricted to reading — so it reaches what you reach: job history, runner assignment, usage, and the retained console output of your jobs, including anything your workflow printed. Source code held for AI analysis is not exposed through this path.
The controls on it are that the session expires (one hour by default), can be revoked sooner, and writes an audit record under both identities for every request made inside it. Administrator rights are a per-person grant on the user record — no environment variable, job title, or GitHub organization role confers them.
Separately, on-call engineers hold direct access to production infrastructure for incident response. That path is governed by MFA and the on-call rotation rather than by the support-session audit trail; see Access Control.
See Operator Access for what that path can and cannot reach.
If operator or support access is required, is it fully audit logged?
Yes for the support path itself. Every request to the StarSling API writes an audit record identifying the person or API key that made it, the operation, the result, and the time. When an administrator is acting on behalf of a user, the record names both identities — the account being viewed and the administrator viewing it — so support activity is never indistinguishable from the customer's own.
To be precise about the boundary: this trail covers access through the application. Direct infrastructure access — on-call engineers reaching production systems during an incident — is governed separately by MFA and the on-call rotation described under Access Control, and is not captured as API audit records.
The application only ever inserts into this trail — no code path updates or deletes a record — and records are retained independently of the accounts they reference, so history survives a user being removed and is not erased by a request to delete your job data. That insert-only behavior is an application guarantee rather than a database or write-once-storage constraint.
See Audit Logging.
Are our jobs isolated from other customers?
Yes. Every job runs on its own dedicated, single-use virtual machine, and isolation between customers is enforced at the virtual-machine boundary rather than by containers sharing a host.
A runner also cannot receive another customer's work even by accident. Each one registers with GitHub using a single-use, just-in-time token minted for one organization's app installation, so the set of jobs it can ever be assigned is scoped to your organization.
Worth knowing before you ask: within a single organization, GitHub — not StarSling — decides which of your queued jobs a given runner picks up. That assignment never crosses an organization boundary, so it is not a cross-customer concern, but it does mean the isolation unit is the GitHub organization. If your company spans several organizations, or shares one with contractors, that is the line to reason about.
See Isolation.
Is the machine destroyed after each job?
Yes. A machine is provisioned when your job is queued and destroyed when the job finishes. There is no reuse across jobs, no warm pool of shared runners, and nothing — filesystem, image cache, process, or credential — carries from one job to the next. The machine is never handed to another job in any case: its registration credential is single-use, so even an instance that outlived a failed teardown could not be assigned further work.
Is source code, or are files, secrets, and credentials retained after the job finishes?
- Secrets, credentials, and environment variables — never received, so never retained as values. What a workflow prints is a separate matter: see the note under the console log below.
- Your job's filesystem, including the checkout — destroyed with the machine. Nothing is copied off it.
- Build artifacts — uploaded to GitHub's storage, never to ours.
- Source code read for AI optimization analysis — held only for the duration of the analysis and deleted within 24 hours.
- Your job's console log — retained, and used to produce optimization analysis for your organization. See the retention table below.
The console log is the one thing we keep. It is the log GitHub itself shows under the Actions tab, retrieved after the job completes, so GitHub's masking of registered Actions secrets has already been applied. Anything else a workflow prints — an unmasked variable, a credential fetched at runtime, a debug dump — is in that output, exactly as it is in GitHub's own log for the run.
See the Data Access Summary for the full table.
How long are logs and cached artifacts retained?
| Data | Retention |
|---|---|
| Workflow job logs | Retained no longer than 12 months |
| Source code held for AI analysis | Deleted within 24 hours |
| Repository metadata | Kept for the life of the account, deleted within 7 days of uninstalling |
| GitHub's own copy of the logs, plus artifacts and Actions caches | Held by GitHub under your repository's own retention settings — StarSling does not store or control them |
Your actions/upload-artifact uploads and actions/cache entries live in GitHub and are governed by your own repository and organization settings. StarSling operates no separate cache or artifact store.
We do retain the console output of jobs that run on StarSling runners, because it is what our optimization agents read to find where your CI time goes. That data is used only to produce analysis for your own organization — never pooled with other customers' data, never used to train models, and never sold or shared. See How Your Data Is Used.
See Data Deletion.
What further documentation can you provide?
Published: Data Handling, Compliance, and GitHub App Permissions.
Available on request for enterprise security reviews:
- CAIQ and SIG questionnaire responses
- Custom questionnaire responses
- A security review call with our engineering team
Contact founders@starsling.dev to request them. To report a vulnerability, email security@starsling.dev — see Responsible Disclosure.
Can Enterprise customers configure custom retention and export audit logs?
Both are available to Enterprise customers as part of an agreement with us, arranged and delivered by our team rather than configured self-serve in the product. Custom data retention policies and audit log export are listed under Enterprise Security Features, alongside SAML single sign-on and a dedicated support channel.
Contact founders@starsling.dev to scope the retention window and export format your compliance program requires.