An extension can have access to a developer’s workspace and the tools around it. Validation considers the package being delivered, the behaviour it enables, and changes between releases.
Publisher and package identity
The assessment starts with the publisher, package identifier, distribution source, and release version. Published artifacts are considered separately from the source repositories they reference.
The objective is a traceable relationship between the reviewed artifact and the package made available in the client repository.
Code, dependencies, and capabilities
Review scope covers included components and dependencies, relevant security findings, and the access required for the extension’s intended workflow. Behavioural evaluation is applied where included in the agreed assessment scope.
| Assessment area | Examples of review considerations |
|---|---|
| Workspace access | File reads and writes; project data handling. |
| Local execution | Commands, child processes, and downloaded executables. |
| External connections | Service destinations, transmitted content, and credential handling. |
| Dependencies | Bundled components, provenance, and relevant known vulnerabilities. |
Validation follows the version.
A new release may introduce dependencies, request additional access, or change its network behaviour. Material changes are evaluated within the agreed review process before the package’s repository availability is updated.
Publisher changes and distribution changes are also relevant to the assessment.
Records stay with the client repository.
Release-specific validation information belongs within the dedicated company environment. The public website does not disclose client package selections or assessment records.
Validation provides evidence for a defined artifact and review scope. It cannot establish every runtime behaviour or eliminate all software risk. Client approval and operational controls remain part of the decision.