Backlog and findings

Backlog shows the findings that still need action (open, triaged, in progress), most urgent first. Findings shows every finding in any status. Both can be filtered by severity and scanner and searched by CVE, package or title.

Owners

If a repository has a CODEOWNERS file (in .github/, .gitlab/, .bitbucket/, docs/ or the root), each finding shows its owners: the owners of the manifest for a vulnerable package, or of the file for a finding in code. Matching follows the code host's own rules: the last matching line wins, and GitLab sections are combined. The backlog can be filtered by owner, and owners appear in Jira issues and evidence exports. Akesis reads the file hourly, and again only when the default branch changes.

The numbers at the top

• Open scanner reports → open findings → actionable: how much raw scanner output became, after merging duplicates and re-scoring, findings worth acting on (medium or above). This is measured for your own backlog, not claimed.
• Re-scored: how many findings Akesis raised or lowered, and how many it couldn't check for reachability.
• Outcomes: what was fixed in the last 30 days, how much Akesis fixed on its own, and the median time to fix.

Below them, the status of each scanner (last successful sync, last error) and the dates of the exploit data in use. If the exploit data is more than three days old, or a scanner is failing, Akesis says so rather than presenting stale data as current.

Why a finding has its priority

The scanner's severity is where a finding starts. Akesis then weighs:

• CVSS, the vulnerability's base score;
• EPSS, the probability it is exploited in the next 30 days (FIRST);
• CISA KEV, whether it is known to be exploited in the wild, which makes it critical;
• Reachability, whether your code can reach the vulnerable package;
• Exploit confirmed, when Strix proved an exploit against your application.

Each finding's Why this priority lists the steps, with the reasons. The severity column shows "was high" or similar when Akesis changed it.

Disagree with a priority? Engineers and above can Dispute this priority, with a reason and, optionally, the severity they think it should have. An engineering lead or above resolves it as agreed or disagreed, with a note on what they did (for example, changing the status or adding a sensitive path). A dispute doesn't change the score by itself. Every dispute stays on the finding and in the audit log, and the backlog header counts the open ones.

Reachability

For npm projects on all three code hosts, Akesis reads your lockfile, package.json and production JavaScript and TypeScript from the default branch, without storing them, and labels each finding:

• Reachable: production code imports the package, or something that depends on it. The evidence names the chain, for example "imported in src/server.ts: express → qs".
• Not reachable: every copy is a development-only dependency. This lowers the priority.
• Not verified: anything else (packages nothing imports, other ecosystems, a failed analysis). Akesis never scores these below what the scanner said.

Tests, stories, fixtures and build files don't count as production code. Only Akesis's own analysis can mark a finding not reachable; a scanner's claim can only raise it.

Statuses

Engineers and above can change a finding's status: open, triaged, in progress, resolved, accepted risk, false positive, closed. A status a person set is never changed by a scanner.

Accepted risk

Accepting a risk is a decision for a security owner or admin. It asks for:

• an owner, an active person who isn't read-only;
• a reason;
• a review date, at most a year ahead.

The finding leaves the backlog until the review date, then comes back for someone to look at again. It also comes back sooner if the owner is disabled or removed. If every scanner report was fixed in the meantime, it is resolved instead. Renewing, ending or expiring an acceptance keeps it in the finding's history. Slack's daily digest lists risks due for review in the coming week.

How to fix

For a finding with a CVE, How to fix shows the vendor's own fix from public sources, most authoritative first:

• CISA's required action, for known exploited vulnerabilities;
• Microsoft KB updates with their Update Catalog link and fixed build;
• Palo Alto PAN-OS fixed releases;
• Cisco security advisories, which point to Cisco's fixed-software guidance because the fixed release depends on each device's version;
• Red Hat errata, and Ubuntu and Debian fixed package versions;
• NVD references the vendor tagged as a patch or advisory.

Nothing is invented: fields appear only when the source states them. Akesis doesn't install patches on your machines.

Where the package is used

If your CI sends code structure (see Scanners and uploads), a dependency finding shows Used in your code:

• the files that import or call the package, with their CODEOWNERS owners;
• the functions that use it, and the functions that call those;
• the commit it was mapped at.

It helps you judge the blast radius of a fix and who to ask. It's context only: it never lowers a priority.

Evidence for compliance

Export evidence on any finding (every role, auditors included) downloads one document with everything Akesis holds about it: its details and status, why it has its priority, every scanner report, fix pull requests, accepted risks, disputes, every audit entry that names it, and its AI narratives, marked as AI-generated. It's a record for your evidence files, not a certified attestation.

In your code

Findings in your own code (from Strix, CodeQL, Semgrep and similar) show where they are (file and line, or HTTP method and endpoint), the weakness class, how sure the scanner is, what the exploit showed and how to fix it. They can become Jira issues, but never automatic merges.