How Vidoc works

​

How a scan works

A scan has four stages.

1. Understand the repository. An agent reads the repository and makes a threat model: the applications, the entry points, and where untrusted data goes into the system. Later stages use it as context.
2. Find issues. LLM agents examine the code and report possible security issues with a severity and a category.
3. Confirm issues. A validation agent examines each high and critical finding in the codebase. It can only read and search the code. It decides if the finding is real (true positive), not real (false positive), or unclear (unknown). It also sets the final severity.
4. Report. Vidoc shows the confirmed findings in the web app. For pull request (PR) scans, it also writes comments on the PR.

​

Which findings Vidoc reports

Vidoc reports only confirmed findings. It does not report:

• Findings that validation rejects (false positive).
• Findings that validation cannot confirm (unknown).
• Medium, low, and informative findings from stage 2. Vidoc does not validate them.

​

Which findings go to the pull request

Vidoc comments on the PR for confirmed findings with a final severity of critical, high, or medium. It does not comment on:

• Findings in compliance categories. Refer to Security categories.
• Findings that a user set to Ignored.

A confirmed finding can be medium, because the validation agent can lower the severity. The summary comment shows Fix before merge for critical or high findings, and Check before merge when all findings are medium. These labels are advice. Vidoc does not block merges. Refer to Pull request reviews.

​

Scan types

A push to the default branch does not start a scan. There are no scheduled scans.

​

Finding model

Each finding has these fields. Each category has a risk type: attack, compliance, or other. The web app shows compliance findings as Data & Compliance. Vidoc does not write PR comments for them.

​

Statuses

Users can set these statuses in the web app:

• Open: the issue is active.
• Ignored: a user accepts the issue or decides not to fix it.
• False positive: the finding is not a real issue. Vidoc stores it as Ignored with the reason that the user gives. After that, the web app shows the finding as Ignored.
• Closed: the issue is fixed, or a user closed it.

Users can also change the severity of a finding. Refer to Findings. Vidoc stores two different values for a closed finding:

• closed: a user closed the finding, or revalidation no longer confirmed it.
• fixed: Vidoc closed the finding automatically, because a scan showed that the code no longer has the issue. The reason is “Automatically resolved”.

The web app shows both values as Closed. The REST API shows the stored value. A user cannot set fixed.

​

Finding lifecycle

Vidoc tracks each finding across scans. Each scan updates the status of known issues:

• If the code no longer has the issue, Vidoc sets the status to fixed (shown as Closed).
• If an automatically closed issue comes back, Vidoc sets the status to Open again.
• If revalidation no longer confirms a finding, Vidoc sets the status to Closed.
• If a user set an issue to Ignored or Closed, it stays in that status. Vidoc does not reopen it.

When a later scan analyzed all changed files of a PR and the finding is gone, Vidoc resolves its own comment thread on the PR.

​

Learnings and memory

Vidoc keeps feedback from your team in Memory. Memory has two types of entries. A learning comes from feedback on one finding. Vidoc makes a learning in these cases:

• A user sets a finding to Ignored or False positive and gives a reason, in the web app or through the REST API.
• A developer replies to a Vidoc comment on a PR (GitHub and GitLab only). Vidoc classifies the reply as “true positive” or “false positive”. Vidoc records the reply only when the platform user is linked to a Vidoc user with access to the project. For a false-positive reply, Vidoc also ignores the issue and resolves the comment thread.

A memory entry is a general fact about your code or your policy. A developer tells it to the Vidoc bot in a PR comment, for example “@vidoc remember that all admin endpoints are behind the VPN”. This is available on GitHub and GitLab only. Scope. Memory can apply to a repository, a project, or the organization: How Vidoc uses Memory. The “find issues” stage does not use Memory. In validation, Vidoc selects the learnings and memory entries that apply to the finding and gives them to the validation agent. The agent weighs each entry with the code evidence. For example, a learning can make the agent mark a similar finding as a false positive. Then Vidoc does not report the finding and does not comment on the PR. Memory has an effect only on findings that go to validation. An entry does not remove a finding directly. The validation agent makes the decision.

​

Review new entries regularly

There is no approval step for feedback. Each linked platform user with access to the project can mark a finding as a false positive with a reply on a PR, and Vidoc ignores the issue immediately. On GitHub and GitLab, developers can also add memory entries from a PR. We recommend that the AppSec team examines new entries on the Memory page regularly:

1. Filter by source (False positive, Confirmed true positive, and Pull request) to find the entries that came from PRs.
2. Select Mark superseded for each entry that is wrong. Validation stops the use of the entry.
3. A superseded learning does not reopen the issue that it ignored. To reopen the issue, find it on the Findings page (State: Ignored) and set it to Open.

Only users with the Security Engineer role or higher can supersede, edit, and reactivate entries. Refer to Memory.

​

Results can vary between runs

LLMs are not deterministic. A finding can appear in one scan and not in the next scan. A full scan reuses the findings of files that Vidoc already scanned in the same version. Thus, a new full scan of unchanged code gives the same findings. Each PR scan, also a rescan, runs the “find issues” stage again on the changed files.