Using GSkout V1

Open the GSkout workspace and submit a GitHub repository URL or owner/repository name.

Public repositories can be submitted directly. Authentication is used when you need access to repositories exposed through your GitHub App installation.

GSkout can keep multiple analyses open in the workspace at the same time.

GSkout V1 is focused on JavaScript and Node.js projects containing a package.json.

Repository metadata and tree information may include many files, while source analysis intentionally loads a selected subset based on supported file rules.

Public repositories can be analyzed by URL. Private repository availability depends on the repositories selected for the configured GitHub App installation.

GSkout reports repository access metadata but does not expose GitHub installation tokens inside the repository analysis result.

A repository analysis can combine GitHub repository metadata, repository tree information, package metadata, dependency versions, vulnerability advisories, selected JavaScript and TypeScript source files and supported configuration files.

The final report normalizes findings so they can be grouped by category, severity, confidence, dependency and file.

Findings can come from source-code security, committed secrets, dependency vulnerabilities, maintenance signals and selected configuration analysis.

The Findings tab exposes the complete result, including medium and low findings. The Overview is intentionally focused on the highest-priority signals.

Severity describes the potential impact of a finding. Confidence describes how strongly the available evidence supports the finding.

For example, a dangerous shell execution primitive can be reported separately from a higher-severity finding where request-controlled data is traced to that shell execution sink.

GSkout attempts to resolve installed dependency versions from package metadata and supported lockfiles.

When an installed version cannot be resolved, the package is shown as unresolved and its vulnerability state is marked as not evaluated. GSkout does not label an unresolved dependency as having no known vulnerabilities.

Vulnerability findings can include external references such as NVD, OSV, GitHub Security Advisories, upstream advisories and package pages when those references are available.

Repository health is distinct from dependency health. The overall score combines supported source-security signals, dependency condition, analysis coverage and analysis quality.

High-confidence critical source-to-sink findings can heavily affect or cap the repository score.

Coverage indicates how much of the supported repository analysis scope GSkout was able to load and evaluate.

Coverage is not the same as proof that every file, language or execution path in the repository was analyzed.

Completed analyses are persisted in IndexedDB in the browser so reports can survive page refreshes.

Multiple repository analyses can stay open as workspace tabs. Navigation around the GSkout site does not destroy the root-level workspace state.

After a full browser refresh, persisted analyses that were still running can be restored and restarted by the current V1 client.

GSkout V1 is not a full program-wide taint-analysis engine and is not positioned as a replacement for complete SAST, infrastructure auditing, penetration testing or manual security review.

Findings should be investigated in repository context. A clean GSkout report does not prove that a repository is vulnerability- free.