Security FAQ

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?

The GitHub App does not fetch your secret values, and GitHub artifact uploads go directly to GitHub. GitHub injects secrets and environment variables into the runner at job time. A workflow can still write those values, source files, or build output into logs or published Disks; those copies are retained data and follow their respective access and deletion controls.

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.
• Persisted values follow their destination's policy. Anything your workflow echoes to the console is part of the job log we retain. Files it publishes in Disks persist across jobs. See the retention details 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. Its ephemeral filesystem, processes, and credentials do not carry over to another job. Published Disks are stored separately and can be mounted by later authorized jobs of the same repository on fresh machines. The machine itself is never handed to another job: 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 — received by the runner during the job. Values printed into logs or written into published Disks follow those retention policies.
• Your job's ephemeral filesystem, including the checkout — destroyed with the machine. Files deliberately published in Disks are stored separately.
• Build artifacts — actions/upload-artifact uploads go to GitHub's storage. Build output published in Disks is stored by StarSling.
• Published Disks — retained across jobs until deletion or retirement. Deleted data is removed within 48 hours, and account deletion includes stored Disks.
• 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.

See the Data Access Summary for the full table.

How long are logs and cached artifacts retained?

Your actions/upload-artifact uploads and actions/cache entries live in GitHub and are governed by your own repository and organization settings. StarSling Disks are a separate persistence service with their own encryption and deletion controls.

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.

How are Disks encrypted, and what does deletion guarantee?

Disks use fscrypt v2 with AES-256-XTS for file contents and AES-256-CTS for filenames. Each immutable layer has a fresh data key; stored layer keys are wrapped with AES-256-GCM under a StarSling-managed service key. File sizes, timestamps, permissions, and directory structure are visible metadata. Authorized jobs can read the plaintext and keys for the layers they are allowed to mount.

Deleted Disks data is removed within 48 hours, and account deletion includes stored Disks. Cleanup removes unreferenced stored keys before deleting encrypted layer files. Running jobs can keep their selected generation until they end; deleting a file in one job affects shared data only after a successful publication. Deletion cannot retract data or keys a job already copied elsewhere.

See Disks at rest and Disks deletion. The separate 48-hour billing delay describes daily usage measurement, not permission to keep accessing deleted data.

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.