The Source Is Closed. Here's How You Can Still Trust the Supply Chain.

Security considerations of the GreenOps Scan CLI

Whenever someone asks “why isn’t this open source?” about GreenOps Scan, the honest answer is: it isn’t. The CLI is free to use — npx greenops-scan runs on your machine, with your credentials, without a login or a paywall — but the source code itself is not published. If you clone github.com/spidgorny/greenops-scan, you’ll find a README.md and a LICENSE, not the implementation.

That’s a deliberate trade-off, not an oversight, and it’s fair to ask what it costs you as a user. If you can’t read the code yourself, how do you know it’s safe to point at a real AWS account? This post is about the two things you can independently verify — the published package’s dependency supply chain and its behavior at runtime — and why both hold up well even without access to the source.

What “closed source” does and doesn’t mean here

Closed source means you can’t read src/providers/aws/modules/ec2.ts on GitHub. It does not mean the package you actually install is a black box:

• npx greenops-scan downloads a real, versioned npm package (greenops-scan) with a public npm registry page, a public dependency list, and a full history of every published version.
• Every dependency it pulls in is itself open source and independently auditable — the AWS SDK for JavaScript v3, @inquirer/prompts, pdfkit, ora, chalk, and so on.
• Third-party supply-chain scanners (not us, not anything we control) independently analyze the published package and its transitive dependencies for known vulnerabilities, licensing issues, and suspicious behavior.

That last point is the part worth taking seriously: you don’t have to trust our claims about the code — you can check what independent tooling says about the artifact you’re actually running.

What Snyk says

security.snyk.io/package/npm/greenops-scan runs Snyk’s vulnerability database against every published version of the package and its full dependency tree. It’s the same database and scanning approach Snyk uses for every package on npm — GreenOps Scan gets no special treatment, favorable or otherwise.

What Socket.dev says

socket.dev/npm/package/greenops-scan/alerts/0.1.30?tab=dependencies goes a step further than a CVE database. Socket’s static analysis looks at behavior, not just known vulnerabilities — install scripts, filesystem/network/shell access, obfuscated code, typosquatting risk, maintainer changes, and dependency freshness. That kind of analysis is exactly what you’d want to check for a CLI tool that’s about to run with your AWS credentials.

We treat Socket’s findings as a maintenance backlog, not a one-time checkbox. Recently that meant:

• Bumping every @aws-sdk/* client to a current release (one older version had a documented caching bug in credential resolution, unrelated to Socket but worth fixing anyway)
• Bumping googleapis, @inquirer/prompts, ini, open, ora, and pdfkit off stale majors
• Pinning gaxios to a version that drops a deprecated rimraf/glob chain pulled in transitively through googleapis-common — a case where the direct dependency (googleapis) was current, but a deep transitive pin was still forcing a deprecated package into the tree
• Deliberately not jumping chalk to its latest major, because that version is ESM-only and would have forced a much larger, riskier rewrite of the CLI’s module system for no security benefit — a reminder that “bump everything to latest” isn’t always the safer choice

Some low-severity items remain and are expected to for a while — node-domexception, for instance, is deprecated several layers deep inside node-fetch (a dependency of Google’s own gaxios HTTP client), with no fix available from our side short of dropping GCP support entirely. That’s a normal, low-risk state for a Node.js project with any HTTP or cloud SDK dependencies — the goal isn’t a zero-alert dashboard, it’s making sure nothing exploitable or high-risk sits unaddressed.

What the CLI actually does at runtime — verifiable independent of the source

Beyond the dependency tree, the two things that matter most for a tool touching your cloud account are (1) what API calls it makes and (2) where your data goes. Both are observable without reading a line of source:

• Read-only AWS calls only. Every AWS API call GreenOps Scan makes is a Describe*, Get*, List*, or equivalent read-only operation. You don’t have to take our word for it — run the scan against an IAM profile with only the AWS-managed ReadOnlyAccess policy attached (see our read-only profile walkthrough) and any accidental write call would fail with AccessDenied, loudly, immediately. IAM enforces this, not the tool’s good behavior.
• Nothing leaves your machine. The scan runs locally, reads your local AWS credentials the same way the AWS CLI does, and writes its report (JSON, table, or PDF) to your local terminal or filesystem. There’s no telemetry endpoint, no upload step, no server-side account required to get a scan result. You can verify this yourself with a network monitor (e.g. lsof -i or a proxy like mitmproxy) while a scan runs — the only outbound calls you’ll see are to AWS’s own API endpoints (and Google’s, if you’re scanning GCP).
• Standard, versioned distribution. The package is published to the public npm registry under a fixed name and semantic version, the same distribution mechanism as every other npm package — no custom installer, no binary blob, no curl | bash.

So why keep the source closed at all?

Fair question, and we don’t dodge it: GreenOps Scan is free to use but not free to fork or resell — the business behind it depends on that. Closed source is a commercial choice, not a security posture. The point of this post is that those are separable: you can independently verify the security of the published artifact (via Snyk and Socket) and its runtime behavior (via IAM and network inspection) without needing the source itself. Both checks currently come back clean, and we intend to keep it that way as new versions ship.

If you want to see the current numbers for yourself rather than trust a screenshot in a blog post, the links are right there at the top — check them before you run the scanner, and check them again after every version bump.