Security issues

A finding belongs to one scan. A security issue is the same problem followed across every build of a repository: the same CVE in the same package and file stays one issue, however many commits it appears in. An issue found in a container image also belongs to that image's repository: when one repository builds several images, the same CVE in two of them is two issues, one per image. Issues are available when your workspace has them enabled. Workspace members and above find them under Security issues in the workspace sidebar. The list shows each issue's repository (or, for an image issue without one, its image repository) and can be filtered by repository.

Where an issue comes from

• Issues come only from scans Loha runs itself (managed Trivy scans). A report your pipeline uploads is shown on the build, but never opens or closes an issue.
• An issue opens the first time a scan on a tracked branch finds it: the repository's default branch, plus any branch your Build Security policy names under protected refs. A build without a repository has no branch to compare, so every one of its builds is tracked.
• A finding on any other branch is added to an existing issue's Seen in builds list, but it never opens an issue and never changes an issue's status.

With secret scanning on push on, a push to your default branch or a protected ref is also scanned for secrets. Such an issue lists the push (Push to main) among its occurrences instead of a build.

Statuses

Status	Meaning
Open	Found on a tracked branch and not yet fixed.
Fixed	A completed scan of a tracked branch, which covered this kind of finding, no longer finds it. A failed or partial scan never fixes an issue.
Reopened	Found again after it was fixed.
False positive	A person decided it is not a real problem.
Accepted risk	A person accepted it until a date (at most 365 days). When that date passes, the issue opens again.

Loha only fixes issues that are Open or Reopened. A decision a person made (false positive or accepted risk) stays until someone reopens the issue or the accepted-risk date passes.

Image issues are tracked per image repository, so a scan of one image never fixes an issue of another. Issues from builds without a repository are tracked per project, on every build, and their image issues are fixed per image in the same way.

Fix deadlines (SLA)

The default deadlines are CRITICAL 7 days, HIGH 30 days, MEDIUM 90 days; LOW and UNKNOWN have none. The clock starts when the issue opens and restarts when it reopens. There is no settings screen for the deadlines yet: an administrator sets them through the API, in the Build Security policy's issueSla field. Saving the policy from Settings → Code security keeps the deadlines it already has. Issues that are already open follow new deadlines. In Enforce mode, making a deadline longer (or removing it) needs a second administrator.

Triage

• Any member can propose "false positive" or "accepted risk", with a reason of at least 10 characters.
• An administrator applies or approves it after confirming their password (step-up).
• Accepting the risk of a CRITICAL issue, or triaging any secret, needs a different administrator from the one who proposed it.
• Only an administrator can reopen a triaged issue.
• An administrator can assign an issue to an owner: a workspace member with the member role or higher (not a guest). A member can attach a link to a ticket in your own tracker (https only).
• Every change is kept in the issue's history. Triage is not available to API keys or MCP: a person has to do it.

Triage does not change what the gate blocks; for that, see Security exceptions.

Notifications

Loha sends one message when a scan finds CRITICAL issues that are new, reopened, or newly raised to CRITICAL, and one when issues pass their fix deadline. Each message lists up to 20 issues and the total. An issue is reported as overdue once per deadline: reopening it, revoking its triage, or its accepted risk expiring starts a new deadline, which can be reported again. Email goes to the issue's owner, or to workspace administrators when nobody owns it. To post to Microsoft Teams, add a notification channel for the security issue events under Settings → Webhooks (the page offers them while security issues are enabled); the events are com.loha.security.issue.new_critical.v1 and com.loha.security.issue.sla_breached.v1 (see Outbound webhooks). A push scan's new or reopened secrets are reported by com.loha.security.issue.secret_detected.v1 instead, at any severity, one message per push. Messages name the CVE or rule, the package and the severity; they never contain file contents or secret values.

Retention

Issues and the list of builds they were seen in are kept after a build's scan report expires. Deleting the workspace deletes them.

CLI and API

loha security issues lists issues and loha security issue <id> shows one. The same data is available at GET /api/v1/security/issues with a key that has the security:read scope, and to AI agents through the read-only MCP tools list_security_issues and get_security_issue. Reading needs the member role or higher. The API list accepts status, severity, category, repositoryId, owner and slaBreached filters. slaBreached only accepts true, which shows issues past their deadline; there is no "not breached" form. Each issue carries repositoryName (the repository's owner/name, or null) and imageRepository (for an image issue, or null).

See also: Fix pull requests — let Loha open a pull request that fixes a vulnerability issue.