You are running our script on production machines. Here is exactly what it does.

What the scanner reads

Two scripts, one per platform, each a single readable file under the MIT license: runtimeclear.sh for Linux and macOS (bash 3.2+) and runtimeclear.ps1 for Windows (PowerShell 5.1+). Each starts with a header listing everything it reads.

For each Java home it reads the plain-text release file (JAVA_VERSION, JAVA_RUNTIME_VERSION, IMPLEMENTOR, BUILD_TYPE). Only when a home has no release file does it run <home>/bin/java -version, with a 5-second timeout; --no-exec (-NoExec) turns that off.

With --repo, it reads Dockerfiles, Compose and Kubernetes YAML, CI files, .sdkmanrc, .tool-versions, Gradle and Maven files line by line, skipping binaries and files over 1 MB, and stores only the matching line, cut at 300 characters. The full list of patterns is in the scanner README.

What it never does

• No network access. The scripts never open a socket. The scanner's test suite runs a full scan under strace and fails if any AF_INET or AF_INET6 socket is opened. The PowerShell script avoids Get-Package because that cmdlet can try to download a provider.
• No changes. Nothing is installed, updated, moved or deleted. The only file written is the JSON output.
• No extra data. No process arguments, no environment variables other than PATH and JAVA_HOME, no file contents beyond a single matched line.
• No sudo required. Unreadable locations are listed under warnings in the JSON. Running as root or Administrator only adds other users' homes and processes.

Verify the download

Every GitHub release attaches runtimeclear.sh, runtimeclear.ps1 and a SHA256SUMS file generated from those exact files. Check the hash, then read the script, then run it.

$ curl -fsSLO https://github.com/techbuilddreams/runtimeclear/releases/download/v1.0.1/runtimeclear.sh
$ curl -fsSLO https://github.com/techbuilddreams/runtimeclear/releases/download/v1.0.1/SHA256SUMS
$ sha256sum -c SHA256SUMS --ignore-missing
# macOS: shasum -a 256 runtimeclear.sh   and compare with SHA256SUMS

PS> Invoke-WebRequest https://github.com/techbuilddreams/runtimeclear/releases/download/v1.0.1/runtimeclear.ps1 -OutFile runtimeclear.ps1
PS> (Get-FileHash .\runtimeclear.ps1 -Algorithm SHA256).Hash.ToLower()
# compare with the runtimeclear.ps1 line in SHA256SUMS

Build provenance attestations

The release workflow is being moved to GitHub Actions with signed build provenance attestations, which link each released file to the workflow run and commit that produced it. Releases up to v1.0.1 were published before that and carry checksums only. Once a release includes attestations, its release notes will say so and this command will succeed:

$ gh attestation verify runtimeclear.sh --repo techbuilddreams/runtimeclear

How the report handles scan files

• The report page reads files with the browser's File API and classifies them with rules.js, a versioned rules file you can read, on your machine.
• So loaded scans survive the trip through checkout, they are kept in the tab's sessionStorage, which the browser deletes when the tab closes. Clear all removes them immediately.
• The organization name and employee count you type are kept in localStorage on your computer.
• The site's Content Security Policy restricts the page to its own origin (connect-src 'self'), so the page itself cannot send data to a third party. You can confirm in your browser's network panel: loading scans makes no requests.

How payment verification works

1. You pay on Stripe's hosted checkout. We never see your card details.
2. Stripe redirects back to /report/?session_id=cs_….
3. The page sends only that checkout session ID to /api/verify.php.
4. The server asks Stripe's API for that session using a restricted key that can only read Checkout Sessions, checks that it is complete and paid, recent, and for a RuntimeClear price.
5. It returns an unlock token: your plan, the session ID and an expiry, signed with HMAC-SHA256. The browser stores it in localStorage.
6. On later visits the page sends only the token; the server checks the signature and expiry without calling Stripe.

The endpoint accepts only same-origin JSON POSTs, rate-limits by a one-way hash of the client IP (about 30 requests per 10 minutes), never logs Stripe's response body or the key, and reads its secrets from a file outside the web root.

Data we hold

Scan files

None. They never reach our server.

Payments

Stripe's records of your purchase: name, email, plan, amount, date, country and payment status.

Server logs

Standard web server logs kept by our host (IP, time, URL, referrer, user agent), plus a short-lived rate-limit counter keyed by a hashed IP.

Email

Messages you send to support@runtimeclear.com, kept to answer you and handle refunds or access.

Analytics, ads, cookies

None.

Full details in the privacy policy.

Website hardening

• HTTPS only, with X-Content-Type-Options, X-Frame-Options: DENY, a strict Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy.
• Content Security Policy default-src 'self' with no inline scripts and no third-party scripts, styles or fonts. Fonts are self-hosted.
• The only third-party destination is Stripe Checkout, reached by a normal link when you choose to buy.

Report a vulnerability

Email support@runtimeclear.com with steps to reproduce. Please don't open a public issue for anything that could be abused before a fix ships. For the scanner, we treat any of these as a security bug: a network connection of any kind, a write to any file other than the JSON output, running anything other than <java home>/bin/java -version, recording data we say is not collected, or output that stops being valid JSON because of a crafted path.

We aim to acknowledge reports within one business day, and we credit reporters in the release notes unless you ask us not to. Machine-readable contact: /.well-known/security.txt. Non-sensitive scanner bugs can go to GitHub issues.