Most application-security teams live in a pile of scanner tabs: SAST in one console, SCA in another, container and IaC and secret scans somewhere else, each with its own IDs, severities, and export format. Nobody can answer the two questions leadership actually asks — how many real issues are open, and are we fixing them fast enough? — without a spreadsheet.
Talarity’s AppSec findings register is the answer to both. Every scanner feeds one normalized table: one deduped row per issue, each with a CVSS-based severity, a repository, a live SLA state, and a status. This walkthrough covers the whole loop — ingest, triage, SLA, and hand-off — from the point of view of an application-security engineer.
The register at a glance
Open Application Security → Findings. The header cards answer the leadership questions immediately: open findings, criticals, highs, how many have breached their remediation SLA, how many are at risk, and how many carry an accepted-risk decision. Below them, a posture-by-class strip shows where the open work lives — SAST, SCA, container, IaC — and doubles as a one-click filter. The table normalizes every class into the same columns: the finding, its class, severity with the CVSS score, the repository, the SLA state, and the status.
The four tabs scope the list the way a triage session actually runs: Active (open and in-progress), SLA breaches (overdue), Accepted risk, and All.
Step 1 — Feed it from your scanners
Click Import scan. Talarity ingests SARIF 2.1.0 (Semgrep, CodeQL, Snyk) plus the native JSON of Trivy, Grype, Checkov, tfsec, Gitleaks, and TruffleHog — pick the format, choose the repository, and paste the report. It maps each tool’s own model into the shared taxonomy: Trivy vulnerabilities become container findings, its misconfigurations become IaC, its detected secrets become secret findings. Secrets are never stored in the clear — only a one-way hash of the rule and location is kept.
Import is idempotent. Every finding carries a stable fingerprint, so re-running the same scan updates the existing rows instead of duplicating them, and a finding seen by two different tools is merged into one row that keeps the higher severity and never downgrades a human triage decision. That is what makes the register trustworthy over time: the count reflects distinct issues, not scan runs.
Step 2 — Record what the scanners miss
Not every finding comes from a tool. Click + Add finding to record a pen-test result or a manual review by hand — a title, a class, a severity, an optional repository (chosen by name, not an internal id), a CVSS score, the affected file or package, and the CVE and CWE identifiers so it correlates with everything else.
The remediation deadline is set from the severity you choose — which is the whole point of the next step.
Step 3 — Triage from the row
Each row carries its own triage menu — assign it for remediation, mark it remediated, accept the risk, or mark it a false positive — so you never leave the table to move a finding through its lifecycle.
The severity column pairs the qualitative band (Critical/High/Medium/Low/Informational) with the CVSS score, so a “High 8.6” and a “High 7.5” are distinguishable at a glance. The status column shows a ↪ tracked marker once a finding has a remediation work item, so you can tell at a glance which findings are already in someone’s queue.
Step 4 — Put every severity on a clock
Findings without a deadline never get fixed. Click Configure SLA to set your organization’s remediation window per severity — the platform defaults to 7 days for critical, 14 for high, 30 for medium, and 60 for low. Leave a field blank to inherit the default; override it to match your own policy.
Every finding’s due date is computed from when it was first seen plus its severity’s window, and its SLA state — on track, at risk (inside the final quarter of the window), or breached — is recomputed on every query, not stamped once. A nightly sweep re-checks open findings against their deadlines and escalates the ones that have gone overdue, exactly once, so a breach is surfaced without spamming the same alert every night.
The SLA breaches tab is where you start a remediation stand-up: it shows only the findings that are already past their deadline.
Step 5 — Hand it off, or close it with a reason
Assign for remediation routes a finding to a teammate. Pick the assignee by name; Talarity spins up a tracked work item for them in Work Items — on the same SLA and reminder engine as the rest of your governance work — and flips the finding to in progress with the ↪ tracked marker.
Not every finding gets remediated. Accept risk closes it with a documented, audit-logged reason and an optional expiry, so the decision resurfaces for review instead of quietly ageing forever.
Mark false positive closes it with a documented reason too — because “we looked and it isn’t exploitable” is a decision your auditor will ask you to justify, and Talarity keeps the justification.
Step 6 — Find the work that matters
A large register needs to narrow fast. Filter by severity, class, status, or repository — so you can pull “every open finding in the checkout service” in one click.
The posture-by-class chips are filters too: click SAST and the register narrows to your static-analysis findings, with the chip lit to show it’s the active filter.
What you walk away with
A single register that every scanner feeds, deduped to one row per real issue, each with a CVSS severity, a repository, a remediation deadline that a nightly sweep enforces, and a one-click path to a tracked work item. The two questions leadership asks — how much is open, and are we hitting our windows? — are answered by the header cards, live, without a spreadsheet.
Findings ingest maps to the OASIS SARIF 2.1.0 standard and preserves each tool’s CWE and CVSS metadata; severity uses CVSS 3.1/4.0 bands; and the remediation windows follow the standard practice of tying a fix deadline to severity so the highest-risk issues get the shortest clock.