Glossary

The words Vulkro prints in a finding, a report or a console tab, each in one or two plain sentences. The same definitions ship inside the product: run vulkro glossary <term> or vulkro-sf glossary <term> on the terminal, and hover any dotted term in the console.

Scanning and findings

call graph

A map of which functions call which other functions. Vulkro builds it to follow data through the code and to tell which code can actually run.

entry point

A place where outside input first enters the program: a web route, a main function, a scheduled job or a plugin hook.

symbol

A named thing in code that the scanner tracks: a function, a method or a class.

Also called: function.

reachability

Whether a piece of code can be run at all, starting from an entry point. Code nothing reaches is unused (dead) code, so a finding in it matters less.

Also called: reachable, unreachable, dead code.

untrusted data flow (taint)

Following data that came from a caller (a request, a form, a file) through the code to see where it ends up. If it reaches a risky operation without being checked, that is a finding.

Also called: taint analysis, data flow, trace.

source

Where untrusted data enters: a request parameter, a form field, a header, a file upload.

sink

A risky operation such as a database query, a shell command, a file write or an HTML render. Untrusted data reaching a sink unchecked is the classic injection bug.

sanitizer

Code that makes untrusted data safe before it reaches a sink: escaping, validating, or passing it as a bound parameter.

Also called: sanitiser, sanitizer gap.

heuristic

A rule of thumb based on how the code looks rather than on tracing the data. Faster and broader, but less certain, so heuristic findings sit in the Unproven tier.

evidence

The individual signals that support a finding: a traced data flow, a matched code pattern, a config setting. Each carries a weight, and the weights add up to the confidence.

Also called: evidence weight, signal.

confidence

How sure Vulkro is that a finding is real: Verified, High, Medium or Low. Low-confidence findings are hidden by default on the terminal.

proof tier

Proven means Vulkro has machine-checkable proof: a traced data flow, a value that matches a known key format, or a confirmed advisory. Unproven means the pattern matched but nothing more. Not checked means Vulkro cannot decide this class offline. The engine calls these tiers admitted, demoted and not-examined.

Also called: disposition, admitted, demoted, not examined, ledger.

risk score

A 0 to 100 number per finding, higher is worse. It folds together severity, whether the bug is exploitable, whether the code is reachable, confidence, and known-exploit data.

health score

A 0 to 100 number for a whole scan, higher is healthier. It drops with every critical and high finding.

severity

How bad a finding would be if it is real: Critical, High, Medium, Low or Info. Severity is about impact; confidence and proof tier are about certainty.

baseline

A saved scan to compare against. A CI gate that uses a baseline only fails on findings that are new since it, so existing debt never blocks a change.

gate

A pass or fail check for CI. Exit code 1 means findings at or above the chosen severity (or new versus the baseline) were found; 0 means the build can proceed.

Also called: quality gate, fail-on.

endpoint

A URL your service exposes, such as GET /api/users. Unprotected means it can be called without logging in.

CVE

A public identifier for a known vulnerability in a software package, such as CVE-2024-45590. Vulkro matches your dependencies against a local copy of this data, so nothing about your project is sent anywhere.

Also called: advisory, vulnerability data, CVE bundle.

CWE

A catalogue of weakness types; CWE-89 is SQL injection. Each finding carries the type it belongs to so you can look the class up.

OWASP category

The OWASP API Security Top 10 is an industry list of the ten most common API risks. Vulkro files each finding under one of them (API1 to API10).

SBOM

Software Bill of Materials: a list of every package your project depends on, in a standard file format (CycloneDX or SPDX) that auditors and tools can read.

SARIF

A standard JSON format for scanner results that CI systems and code hosts can import and show inline.

dependency scan (SCA)

Checking the third-party packages your project installs for known vulnerabilities and licence problems.

Also called: software composition analysis.

transitive dependency

A package you did not add yourself but that one of your dependencies pulls in. It ships with your app all the same.

lockfile

The file that pins the exact version of every installed package (package-lock.json, poetry.lock, go.sum). Vulkro reads it to know what is really installed.

blast radius

How much of the codebase depends on a module, and so how far a change or a bug in it can spread.

Also called: change impact, fan-in, fan-out.

infrastructure as code

Dockerfiles, Terraform, Kubernetes manifests and similar files that describe how the app is deployed. Misconfigurations there are scanned like code.

Also called: IaC.

secret

A credential in the code: an API key, a password, a private key. A provider-format match means the value looks like a real key from a named vendor, checked offline against that vendor's published format.

Also called: credential, provider format.

source coverage

The share of the project's source files this scan actually read. Below 90% the counts describe only part of the code.

Salesforce terms

CRUD / FLS

Salesforce permissions. CRUD is object-level (create, read, update, delete); FLS is field-level security. Apex runs in system mode by default, so code must check both or the running user's permissions are ignored.

Also called: record and field access, USER_MODE.

sharing

Salesforce record-level access. A class declared "without sharing" ignores the sharing rules and can read or change every record.

SOQL / DML

SOQL is the Salesforce query language; DML is create, update and delete. Both are where injection and permission bugs land.

guest user

The unauthenticated visitor of an Experience Cloud site or Salesforce Site. Anything the guest profile can reach is reachable by anyone on the internet.

governor limits

Per-transaction caps Salesforce enforces on queries, DML statements and CPU time. Code that trips them fails at runtime.

managed package

A third-party app installed from the AppExchange. Vulkro checks its security-review status and any published advisories.

org security settings

The security settings of a live Salesforce org: session, password, MFA, sharing and guest settings. Read through the login you already have in the Salesforce CLI.

Also called: posture, Tooling API, Metadata API.

Where these show up

• Findings: severity, confidence and proof tier sit on every finding in the console and in vulkro scan output. The engine ids behind them stay in the Technical details block and in JSON and SARIF exports.
• Overview: "Functions connected" is the call graph; "Source coverage" is the share of files the scan read.
• Supply chain: SBOM, VEX, CVE and transitive dependency come from the dependency scan. See SBOM and VEX.
• Salesforce: CRUD / FLS, sharing, SOQL / DML and guest user drive the AppExchange Security Review readiness checklist.