AppSec — Application Security Add-on

1 What AppSec does

AppSec is V/ergent's application-security add-on. You send it findings from any scanner that emits SARIF; it normalises them into one schema, deduplicates across runs, enriches each with live exploit intelligence, risk-scores everything, auto-triages true vs false positives, and pushes the real ones into your CyberCore assessment or your GitHub pull requests.

2 Signing in

AppSec lives at a separate subdomain but shares identity with V/ergent — no second login.

1. 1
   Sign in to V/ergent at app.vergent.co.ke.
2. 2
   Click AppSec in the top nav (bug icon, next to CyberCore).
3. 3
   V/ergent mints a short-lived token, auto-submits it to AppSec's handoff endpoint, and drops a session cookie. You land on the dashboard without typing credentials again.

3 Trying it with demo data

First visit? Click Load demo findings on the empty dashboard. AppSec populates 15 curated sample findings — Log4Shell, subprocess command injection, SQL injection, hardcoded Stripe keys, overly permissive IAM, a few confident false positives — so you can explore every feature before wiring up a real scanner. Clear demos removes them (real ingested findings are never touched — demos are scoped by fingerprint prefix).

4 Uploading a SARIF file

1. 1
   Run any supported scanner with SARIF output (e.g. semgrep --sarif, trivy --format sarif).
2. 2
   On the dashboard, drag the .sarif (or .json) file onto the orange Upload SARIF zone, or click Choose file.
3. 3
   Fill in repo (required) — the canonical identifier like acme/webapp. Commit SHA and skip triage are optional.
4. 4
   Upload completes, AppSec responds with {ingested, new, duplicates}, and the page refreshes showing your findings sorted by risk.

5 Reading the dashboard

Findings are listed by risk score — a 0–100 number that combines severity, EPSS exploit probability, CISA KEV listing, and reachability. Ten thousand raw findings become the thirty-seven that genuinely matter this sprint.

1. 1
   Top cards summarise counts: total, critical, high, true-positive, false-positive, needs-review.
2. 2
   Click any row to expand into the four-tab detail view. See next section.
3. 3
   The KEV red badge means CISA lists this CVE as actively exploited. The unreachable green badge means reachability analysis thinks the vulnerable code isn't hit from production entry points.

6 The four-tab finding view

Each expanded finding has four tabs matching the review convention used across V/ergent:

• Observation — raw scanner output: title, description, scanner + rule + severity, file path and line, CVE with EPSS percentile and KEV status, reachability.
• Rationale — why it matters (or doesn't): the triage engine's reasoning plus the verdict, confidence, and risk score.
• Action — concrete remediation steps in plain language.
• Remediation — where the engine is confident, a unified-diff patch you can review and apply.

7 Triage verdicts

Every triaged finding lands in one of three buckets:

8 Live exploit intelligence

Findings with CVE identifiers get two extra signals fed into the risk score:

• CISA KEV — the Known Exploited Vulnerabilities catalogue. If your CVE is on it, someone is actively exploiting it. Flagged in red.
• EPSS — first.org's Exploit Prediction Scoring System. A 0–1 probability that the CVE will be exploited in the next 30 days. 94%+ is very high.

Both feeds are cached in Postgres with a 24-hour TTL and a retry-with-backoff pattern — if CISA is down, the dashboard keeps serving whatever was last known to be true instead of blanking out.

9 Merge-gate policies

Block merges when they'd introduce unacceptable risk. Rules are declarative — YAML or JSON — and evaluated via a single API call from your CI:

POST /policy/evaluate
{
  "rules": [
    { "id": "block-kev-confirmed",
      "block_when": { "kev_listed": true, "triage_verdict": "true_positive" } },
    { "id": "block-many-highs",
      "block_when": { "severity": ["critical","high"], "count_at_least": 6 } }
  ]
}

Response is {allowed, violations[]}. Fail the CI step if allowed=false. Untriaged findings never trip gates, so flaky triage doesn't break the merge pipeline.

10 For your CI

Every data endpoint accepts the same V/ergent JWT — no second identity plane. Mint a token, attach it as a bearer header, done.

POST /ingest/sarif         — SARIF + repo + optional PR → queued for triage
POST /ingest/sarif/upload  — multipart; same semantics as above
GET  /findings             — org-scoped list, sorted by risk
POST /policy/evaluate      — rules → allow/deny decision
GET  /health               — liveness + enrichment metrics (unauth)

11 Troubleshooting