Concepts
Severity vs priority, reachability, credits, and the vocabulary Argus uses.
You will finish this page able to read any Argus screen: what a finding is, how severity differs from priority, what reachability buys you, and how projects, organizations and credits fit together.
Organization
Your organization is the tenant boundary. Everything, projects, findings, scans, BOMs, API keys, credits, audit log, belongs to exactly one organization, and nothing crosses that line.
You can belong to more than one organization (for example a personal one and your company's). One organization is active at a time; switch with the organization picker in the top navigation. See Team and access.
Project
A project is one repository that Argus watches. It carries a name, repo URL, default branch, language, and a rolling risk score. Projects are created by importing a repo through the GitHub App, or by pointing Argus at a Git URL.
| Project status | Meaning |
|---|---|
Pending | Created, never scanned |
Scanning | A scan is in flight |
Scanned | At least one scan completed |
Failed | The last scan did not complete |
Namespace
A namespace groups projects (by team, business unit, or environment). Most list and dashboard queries accept a namespaceId so you can scope a view to one group of repos.
Findings
A finding is one security issue in one place. Every finding has a category, a severity, a status, and a location.
Categories
| Category | What it is | Produced by |
|---|---|---|
SAST | A vulnerability in your own source code | Semgrep + AI analysis passes |
SCA | A known CVE in a dependency, a malicious package, or a base-image CVE | OSV.dev advisories, Trivy |
Secret | A credential committed to the repository | Gitleaks, entropy analysis, assignment analysis |
IaC | A misconfiguration in Terraform, CloudFormation, ARM, Dockerfiles, Kubernetes or Helm | Trivy config |
DAST | An issue found by actively probing a running API | Argus API DAST (opt-in, allowlisted) |
Container base-image CVEs are reported as SCA findings whose location is the Dockerfile that pulls the image. Kubernetes and Helm misconfigurations are reported as IaC.
Severity
Five levels, ordered: CRITICAL → HIGH → MEDIUM → LOW → INFO.
Severity answers "how bad is this class of bug?" It does not answer "should I fix this one first?". That is what priority is for.
Status
| Status | Set by | Meaning |
|---|---|---|
Open | Scanner | Live and untriaged |
Resolved | You, or a re-scan | Fixed. A re-scan that no longer reports a finding resolves it automatically |
false_positive | You, or AI re-verification | Not a real issue. Also sets the falsePositive flag |
accepted_risk | You | Real, understood, deliberately not being fixed |
Setting a finding to false_positive sets its false-positive flag; moving it to any other status clears the flag. The two never drift apart.
Key finding fields
| Field | Notes |
|---|---|
severity | CRITICAL … INFO |
cvss | CVSS v3.x base score, 0-10. Computed from the advisory's vector string for SCA findings |
cveId | CVE-…, or an OSV family id (GHSA-…, GO-…, PYSEC-…, RUSTSEC-…) |
epss | EPSS exploit-probability, 0-1 |
kevKnownExploited | Listed in CISA's Known Exploited Vulnerabilities catalog |
reachable | true / false / null (unknown), see below |
priorityScore, priorityBand | Blended 0-100 score and its band |
package | The dependency a SCA finding attaches to |
file, line | Location in the repo |
ruleId | The detection rule that fired |
scanAgent | Which engine produced it |
attackTechnique | MITRE ATT&CK technique id, where one maps |
secretValidity | For secrets, when AI validation ran: Live / Rotated / Test / Unknown |
aiConfidence, aiReasoning | Present when an AI pass triaged the finding |
onChangedLine | The finding sits on a line the current pull request changed |
Reachability
Reachability answers a single question for dependency findings: is the vulnerable package actually imported by your code?
Argus resolves each dependency name to the module name your source would import, then statically searches your source for that import.
| Value | Meaning |
|---|---|
reachable | An import of the package was found in your source |
unreachable | The package is declared in a lockfile but never imported anywhere |
unknown (null) | Not analysable, e.g. a SAST or Secret finding, or an ecosystem Argus does not import-analyse |
Analysed ecosystems: npm/yarn/pnpm (.js .jsx .ts .tsx .mjs .cjs .vue .svelte) and PyPI (.py .pyi). Python distribution names are mapped to their real module names (pyyaml → yaml, pillow → PIL, scikit-learn → sklearn, and so on).
Not analysed: Go, Maven, Cargo and RubyGems dependencies are always reported as reachable.
Reachability is deliberately biased toward safety. A finding is only marked unreachable when the source walk completed without truncation, source files of the right ecosystem were actually found, the package-to-module name is unambiguous, and zero imports matched. Any uncertainty resolves to reachable. Argus marks findings. It never silently deletes them.
Each classification carries an evidence string, for example imported in server/routes.js or declared but never statically imported across 412 JS/TS source files.
Priority score
Severity tells you the class of bug. Priority tells you what to fix first. Argus computes a 0-100 score per finding:
anchor = cvss / 10 (or the severity band when no CVSS is available)
exploitMult = 1 + (0.5 × epss) + (0.7 × kev) + (0.3 × internetFacing) + (0.6 × attackPathScore)
reachMult = 1.00 reachable
= 0.85 unknown
= 0.25 unreachable
score = clamp(anchor × exploitMult × reachMult, 0, 1) × 100
When no numeric CVSS exists, the anchor falls back to the severity band: CRITICAL 0.9, HIGH 0.7, MEDIUM 0.5, LOW 0.3, otherwise 0.1.
| Score | Band |
|---|---|
| ≥ 80 | Critical |
| ≥ 60 | High |
| ≥ 40 | Medium |
| ≥ 20 | Low |
| < 20 | Info |
The practical effect: a reachable, actively-exploited CVE on an internet-facing service rises to the top; an unreachable dependency CVE sinks to the bottom without disappearing.
The four exploitability weights are configurable per organization, see Policies and gates.
False positives
Two paths mark a finding as a false positive:
- You triage it. Set the status to
False positivefrom the Issues table, the detail drawer, or in bulk. - AI re-verification. Re-verify with AI re-examines a finding and its stored evidence, then conservatively auto-marks confident false positives. See Issues and remediation.
Marking a finding as a false positive also excludes it from gate policy evaluation and from VEX affected statements.
SLA
Each severity has a time-to-fix budget. A finding older than its budget counts as an SLA breach on the dashboard.
| Severity | Default budget |
|---|---|
| Critical | 24 hours |
| High | 72 hours |
| Medium | 168 hours (7 days) |
| Low | 720 hours (30 days) |
Change these in Settings → Gate policies / SLA.
Credits
Credits meter AI work. Deterministic scanning is not credit-priced. It is limited by your plan's monthly rule-scan quota instead.
| Action | Credits |
|---|---|
| Standard scan | 3 |
| Deep Agentic scan | 10 |
| Agentic fix (Assign to Agent) | 15 |
| AI PR review | 5 |
| Auto-fix draft | 5 |
| Ask AI question | 2 |
| Re-verify a batch of findings with AI | 2 |
| Rule-only scan | 0 |
Every charge and grant is written to a ledger you can read in Settings → Billing. A scan that fails is refunded automatically, exactly once. Full detail in Billing and credits.
Scan job
A scan job is one execution against one project. Jobs carry a status (Queued → Running → Completed / Failed), the branch and commit scanned, a finding count, timings, and who triggered it.
Argus reconciles results between scans: findings that a new scan of the same categories no longer reports are auto-resolved, and findings that reappear are reopened. Categories that a scan did not cover are left untouched, so a standard scan never wipes out results from a Deep Agentic scan.
Next
- Scanning, what each engine looks at and how to run one
- Issues and remediation, working the backlog
- Policies and gates, turning findings into build decisions