Six words carry most of the product. Getting them straight makes every other page shorter.
The vocabulary
Organizationwho owns it- The shared workspace for a team. Repositories, connected accounts, findings, the audit log, and the plan belong to the team, not to the person who set them up. You reach them by being a member. See Organizations and roles.
Scanone commit- One analysis of one repository at one commit, on one branch. Everything else hangs off a scan, which is why findings from different scans have different ids.
Findingreported evidence- A scan result attached to this repository and revision. It may be a source finding, applicable dependency advisory, credential pattern, unsafe configuration, or maintainability observation. Check its evidence and verification state before treating it as an exploitable vulnerability.
Matched researchfinding plus context- A finding joined to relevant public security research. A research match provides context; it does not establish that the reported behavior is reachable or has been executed.
Fixa patch- One generated patch for one finding, applying to the exact commit that was scanned, plus the branch and pull request that carry it once you publish.
Finding statethe scanner's verdict- How sure the scan is that the finding is real: confirmed, likely, unconfirmed, dismissed, fixed. Separate from your own triage decision.
How they relate
A scan produces findings and observations with different evidence. Some have matched research, some have source verification, and a separately executed proof records only the requests and variants it tested against a specific revision and environment. A proposed patch needs review. Merging a pull request is not proof of closure: inspect the later scan and any replay evidence.
A worked example
- A scan of
acme/apiat commit4f21c8efinishes. - It reports a source finding: a request query parameter reaches an outbound HTTP request with no host allowlist in between, so the service can be pointed at internal addresses.
- It is also matched, because the retrieval step joined it to published research on that class of request forgery, which is why the finding can explain the impact rather than just naming the rule.
- You generate a fix. It adds the allowlist check, and applies to
4f21c8e, the commit that was analysed. - You read the diff, publish the pull request, and merge it.
- You rescan. The finding does not come back, and the commit history records it as resolved by that commit.
Severity and category
Every finding carries a severity and a category. Severity is how bad it is. Category is what kind of thing it is, and it decides which check produced it.
| Displayed | Wire value | `--severity` accepts |
|---|---|---|
| Critical | critical | critical |
| High | high | high |
| Watch | medium | watch, medium |
| Info | low | info, low |
| Category | What it covers |
|---|---|
code | A vulnerability in code you wrote, reached by a data flow the scan traced. |
dependency | A known vulnerability in a package your manifests or lockfiles declare. |
secret | A credential, key, or token committed into the repository. |
misconfig | An unsafe setting in infrastructure or configuration files. |
os-package | A vulnerable operating system package inside a scanned container image. |
The first four come from scanning a repository. os-package comes from scanning a container image, which is a separate thing to connect. See Container images.
Have a correction or need help?
Email the docs team