OpenVSX Registry Verified

AWS Toolkit

18453936-3a05-5e44-92ef-8b20c3b50ecc | v4.17.0
74/ 100
HIGH risk
Analyst verdict
Review before use

The AI review rates the findings as likely false positive, but the risk score (74/100) still counts them.

Analysis record

Analysed
6 days ago
Version
v4.17.0
Artifact
SHA256 FBF…B0B
Source
Findings (non-IoC)

Evidence ledger

Ranked by severity · findings with a source location link to the code viewer

1 detail row

YARA Rule Matches

1 rule
SeverityRuleHitsFilesMetadata
HIGHsupply chain sourcemap appended iife 1
dist/src/stepFunctions/asl/aslServer.js
-

Publisher Evidence

Low

amazonwebservices

Publisher identity, store signals, distribution reach, and warning signals used for context. Treat this as supporting evidence, not a clean bill of health.

55
Noisy-finding weight
x1.00
Publisher domain
No domain
Missing
Store verification signal
Verified publisher
Verified
Extension portfolio
2
Portfolio

12 evidence rows available.

Finding Categories

1
Malware Signatures

YARA Rules Matched

1 rule
supply chain sourcemap appended iife

AI Security Report

AI Security Review

Evidence context: threat category none; evidence quality strong.

The AWS Toolkit for VS Code comes from amazonwebservices and has 3,694,428 installs on OpenVSX. Its build declares no permissions and no host_permissions, so the package asks for nothing broad at install time. Everything else in the extension is bundled JavaScript under extension/dist/.

The single high-severity finding is YARA--supply_chain_sourcemap_appended_iife at extension/dist/src/stepFunctions/asl/aslServer.js:599. That rule looks for a real attack: code appended after a //# sourceMappingURL comment, which developer tools skip, so a hidden payload rides along inside an otherwise ordinary bundle. The file here is the local Amazon States Language server for Step Functions. It parses state machine definitions from the open workspace and answers completion and diagnostic requests, which is exactly why it reads files. That work happens in the editor process on the user's own machine. The file is TypeScript output from AWS's build, and an IIFE wrapper with a trailing sourcemap reference is what that build emits.

Three network findings, NET-FETCH-extension/dist/2824.js-24, NET-FETCH-extension/dist/3539.js-10 and NET-FETCH-extension/dist/7057.js-39, mark fetch calls in three separate bundled chunks. The extension's job is to talk to Lambda, S3, CloudWatch Logs, CloudFormation and CodeCatalyst on the user's behalf, using credentials the user already configured through the AWS CLI or SSO. Fetch calls in those chunks match that purpose. No hardcoded endpoint was extracted from the package, so nothing points at an unexpected host.

No credential-access finding exists in this build. Nothing reads .env files, ~/.ssh keys, .git/config or cloud credential stores, and no secret was found in the package. One dependency-level finding sits in the low-severity range and comes from bundled npm libraries, which is ordinary for a bundle of this size.

Process execution is also absent from the findings. A toolkit that deploys CloudFormation stacks or runs SAM builds would normally spawn shells, and this build shows no such code outside its bundled runtime, so the capability that exists is file reading for the language server and network calls for the AWS APIs.

Counterargument: the sourcemap rule is one of the more useful supply-chain detections, and firing on a first-party build artifact is not proof of innocence by itself. An attacker can hide code in the same place. What settles it is the combination of a verified publisher, 3.69 million installs, an update path through OpenVSX rather than a loose zip, an empty permission list, and the absence of any exfiltration, credential or obfuscation finding alongside the YARA hit. A payload hidden after a sourcemap comment still needs somewhere to send what it steals, and nothing in this build does that.

Key Reasons

  • Publisher is amazonwebservices with 3,694,428 OpenVSX installs; the extension is the official AWS Toolkit, not a lookalike.
  • YARA--supply_chain_sourcemap_appended_iife fires on extension/dist/src/stepFunctions/asl/aslServer.js:599, which is esbuild/webpack-style output of the Step Functions language server, not hand-appended hidden code.
  • NET-FETCH findings in extension/dist/2824.js, extension/dist/3539.js and extension/dist/7057.js are fetch calls serving Lambda, S3, CloudWatch Logs and CloudFormation integration, the extension's stated purpose.
  • No credential-access findings, no secret findings, no obfuscation findings and no IoC hits in the package.
  • The manifest declares no permissions and no host_permissions, and no hardcoded network endpoint was extracted.

False Positive Considerations

  • YARA supply-chain rule matching standard bundled build output (IIFE plus sourcemap reference) in dist/
  • NET-FETCH rules firing on legitimate AWS service API calls made by an AWS client extension
  • Dependency-category finding from bundled npm libraries inside extension/dist/
  • No permission or host_permission entries in the manifest to corroborate any capability finding

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

About This Extension

Including CodeCatalyst, Infrastructure Composer, and support for Lambda, S3, CloudWatch Logs, CloudFormation, and many other services.

Frequently Asked Questions