AWS Toolkit

AI Security Review

Evidence context: threat category none; evidence quality moderate.

The AWS Toolkit is published by Amazon Web Services and installed about 5.16 million times. It connects VS Code to CodeCatalyst, Lambda, S3, CloudWatch Logs and CloudFormation. That work requires three things the scanner reacted to: reading workspace files, launching local helper processes, and calling remote service APIs.

The one high-severity hit is YARA--supply_chain_sourcemap_appended_iife at extension/dist/src/stepFunctions/asl/aslServer.js:599. The rule looks for a sourcemap comment appended after a bundled function expression. TypeScript and webpack emit exactly that pattern when they write an inline //# sourceMappingURL= trailer, and this file is the Step Functions ASL language server, which the toolkit starts as a child process to validate state machine definitions. A file that ships inside dist/, carries no obfuscation finding, and does no downloading or spawning of its own is build output.

The three network findings land in webpack chunk files: extension/dist/2824.js, extension/dist/3539.js and extension/dist/7057.js. Each marks a fetch call. An AWS toolkit has to talk to AWS. The SDK bundles service clients into separate chunks, so a fetch in dist/3539.js is a request to a service endpoint such as Lambda or CloudWatch, authorized with credentials the developer supplies. The declared permission list is empty and the bundle lists no fixed endpoints, which fits an extension whose destinations depend on the region and account configured.

Nothing in the evidence targets credentials on disk. There are no findings for .env reads, .ssh keys, .git/config or cloud credential files, and no secret-access findings at all. The toolkit does handle credentials, because signing requests is its purpose, but it takes them from VS Code secret storage and the standard AWS credential provider chain rather than scraping files in the workspace.

The strongest counterargument is that aslServer.js is a language server, and a language server is the ideal disguise: it runs as a separate process with workspace access, and appending a payload to a built file is a known supply chain trick. That reading does not survive the rest of the evidence. The finding is a sourcemap trailer, the file is unminified build output under dist/, there is no second-stage download, no eval pattern, no obfuscation hit, and no suspicious network domain. A single bundler convention plus three SDK fetches, in an extension from a verified publisher with 5 million installs, is what a normal development tool looks like.

Workspace access is broad by design. The toolkit reads and edits SAM templates, CloudFormation files and state machine definitions in the folder you open, and writes them back.

Key Reasons

• Only five findings total for a 5.1M-install extension from a verified publisher (Amazon Web Services).
• The single high-severity hit is YARA--supply_chain_sourcemap_appended_iife at dist/src/stepFunctions/asl/aslServer.js:599, a standard bundler sourcemap trailer in a language server file.
• NET-FETCH findings in dist/2824.js, dist/3539.js and dist/7057.js are webpack chunk fetches to AWS service endpoints, which the toolkit's stated purpose requires.
• No secret, credential-file, obfuscation or IoC findings to corroborate any malicious intent.

False Positive Considerations

• Sourcemap-appended IIFE in bundled dist/ output misread as supply chain injection
• Webpack chunk fetch calls in generated dist/ JavaScript
• One bundled dependency finding counted against a build artifact
• High raw finding volume typical of any large extension bundle

Reviewed 2026-10-13; recommended action: suppress false positive; model confidence 90%.