Security
What we protect, and how to tell us when we slip.
EvalGlass runs on your machine and in your CI. It reads your repo's evidence and writes a Scorecard. Nothing leaves your repo, and there is no hosted runtime to attack. This page mirrors SECURITY.md.
Data handling
EvalGlass is local-first by construction. There is no telemetry, no phone-home, no provider keys, and no hosted service in the required path.
- Runs where your code runs. Entirely on your machine and in CI. Your inputs, outputs, and validated reference data never leave your repo.
- No telemetry, no phone-home. The runtime does not call out. It reads host-owned evidence and writes typed artifacts locally.
- No keys, no hosted runtime. Required paths need no provider SDKs and no SaaS. Nothing to provision, nothing to leak.
- External lanes are opt-in. Optional lanes that touch external services are opt-in, pinned, and deletable. No required import loads them. Extensions →
Report a vulnerability
Please report privately first. Do not open a public issue for a security problem.
- Preferred: GitHub private reporting. Use GitHub's private vulnerability reporting on the repository. SECURITY.md →
- Fallback: email. Write to contact@syntelesis.com with the subject "EvalGlass security".
- Acknowledgement. We aim to acknowledge within 5 working days.
- Disclosure. We follow 90-day coordinated disclosure.
Best effort, no SLA.
EvalGlass is volunteer-maintained and pre-alpha. We will do our best, but we do not promise a response-time SLA. Frame your expectations accordingly.
Scope
| In scope | Out of scope |
|---|---|
The runtime (src/evalglass/**) | Third-party host code that uses EvalGlass |
| Skill-scaffolded code | Disabled optional adapters |
| CI workflows that consume privileged tokens |
One scope note worth stating plainly: a green Scorecard misread as proof of correctness is itself treated as a trust and security issue. Defeating the no-false-confidence guarantee — making an informational, uncalibrated, non-comparable, or partly blocked run look like proof — is in scope. Claim boundary →
Supply chain & supported versions
- Vendored source you can read. The runtime is vendored into your repo, not hidden behind a binary. You can audit what runs.
- Pinned required deps. Required dependencies are pinned, with a manifest and a lock file recording what was vendored.
- Optional deps isolated. Optional-lane dependencies are isolated and pinned, and no required path imports them.
- Supported version. Pre-alpha, version 0.1.0, no tagged releases yet — only
mainis supported until a tagged release.
Related