Platform

Scans run on your machines. The platform at app.atmoslab.dev handles everything around them: tokens, license validation, the Managed Ruleset, the dashboard and pull request feedback.

app.atmoslab.dev

Sign-ins and the Workspace Token#

On your own machine the CLI authenticates with the sign-in atmos login stores: a link opens in your browser, you approve, and every scan from that machine runs as you, into your active workspace. Each signed-in machine is listed on the Tokens page, where you can revoke it. atmos logout does the same from the terminal. A sign-in expires after a year.

CI and other headless environments use a Workspace Token, a credential starting with atmos_ws_. Owners and admins create it on the Tokens page and pass it as ATMOS_TOKEN or --token, which takes precedence over any stored sign-in. The token is shown exactly once, can carry an expiry set at creation, and can be revoked at any time. For handling guidance, see best practices.

License validation#

Every scan starts with a license check against your workspace, and a scan without a valid credential never runs. Connection problems are retried, up to 3 attempts in total. A denial prints the reason and does not consume a scan. After a successful scan, the CLI also tells you when a newer release is available through atmos self-update.

Managed Ruleset#

After validation the CLI receives the Managed Ruleset, the detection rules Atmos maintains and updates on the platform, with no rule files for you to manage. Your own rules load with it, in the order given in custom rules.

Pull request feedback#

With the GitHub App connected, a CI scan of a pull request posts a check on the pull request and one comment that updates in place on every new scan. The check fails on new critical and high findings by default. Without the app, findings still land on the dashboard and the exit code gates the build.

What leaves your machine#

Scans run in your CI or on your machine, and the platform never clones your repositories. What it receives at the end of a scan is:

• the findings, with severity, message and rule id,
• the repository identity, the branch and the commit,
• file paths relative to the scan root, with line and column numbers,
• the trace behind each finding, as a sequence of those locations,
• for dependency findings, the package, the resolved version, the advisory id and the dependency path,
• one-way hashes of the committer email addresses from the last 90 days, used to compare activity against your seats,
• scan metadata: CLI version, platform, durations and error counts.

Source text is not part of that. The matched line is omitted from findings and from traces unless you pass --snippets yourself. Values matched by rules that detect secrets are redacted before upload either way, and --no-upload keeps even the findings local.

The committer hashes are computed before upload, so the addresses themselves never leave the machine. We treat the hashes as personal data. The Privacy Policy covers the lawful basis and the retention.

EPSS scores#

Dependency findings with a CVE are enriched with EPSS scores, which estimate exploit probability, so the backlog sorts by real-world risk instead of raw severity. A lookup failure only omits the scores and never affects the scan. EPSS scores are published by FIRST and refreshed once a day.