{% extends "base.html" %} {% block title %}{{ finding.title }} · ai-protect{% endblock %} {% block autorefresh %}window.AI_PROTECT_NO_AUTOREFRESH = true;{% endblock %} {% block content %} ← back to all findings
{{ finding.severity.value }} Tier {{ finding.tier }} {{ finding.category.value }}

{{ finding.title }}

app: {{ finding.app_name }} adapter: {{ finding.adapter }} stage: {{ finding.stage }} fingerprint: {{ finding.fingerprint }}
{% if auto_resolve_change %}
Auto-resolved by re-scan.

Change {{ auto_resolve_change.change_id }} — adapter {{ auto_resolve_change.rescan_adapter }} did not re-emit this fingerprint on the most recent {{ auto_resolve_change.notes.split('stage=')[1].split(' ')[0] if 'stage=' in (auto_resolve_change.notes or '') else 'scan' }}-stage scan ({{ auto_resolve_change.last_state_at|localtime }}). The scanner is treating this finding as fixed/gone. If that's wrong (e.g. the file was moved rather than fixed), revert the Change from its detail page — subsequent absent re-scans will respect the revert and not re-auto-resolve.

{% endif %} {% if finding.evidence.get('intel_match_unverified') %}
Unverified intel match — review before acting.

This finding came from intel_match, which cross-references manifest text against external CVE feeds via token overlap. It is not ground truth that the affected product is in use — only that a word in this app's manifest ({{ finding.evidence.get('matched_tokens', [])|join(', ') }}) appeared in the feed's CVE title/summary. Severity is capped at HIGH for unverified matches even when the CVE is on CISA KEV. Verify by opening the advisory below and confirming the product/version matches what's actually deployed — if it doesn't, dismiss this finding.

{% endif %}

Description

{{ finding.description }}

{% if finding.remediation %}

Remediation

{{ finding.remediation }}

{% endif %}

Evidence

{% for k, v in finding.evidence.items() %} {% endfor %}
{{ k }}
{{ v }}

Affected

{% for k, v in finding.affected.items() %} {% endfor %}
{{ k }}{{ v }}
{% if finding.compliance %}

Compliance evidence

{% endif %} {% if finding.references %}

References

{% endif %} {% if cve_ids %}

Related intel external feed coverage for CVE{{ 's' if cve_ids|length > 1 else '' }} mentioned in this finding

CVE{{ 's' if cve_ids|length > 1 else '' }} in this finding: {% for c in cve_ids %}{{ c }}{% if not loop.last %}, {% endif %}{% endfor %}. Intel feeds supplement the scanner's own data — the finding above is the source of truth for what's in your code; these rows show what external feeds are saying about the same CVE.

{% if related_intel %} {% for r in related_intel %} {% endfor %}
CVESeverityCVSSTitleSource feedPublishedFetched
{% if r.item.link %}{{ r.item.cve_id }}{% else %}{{ r.item.cve_id }}{% endif %} {% if r.item.severity %}{{ r.item.severity }}{% else %}—{% endif %} {{ '%.1f'|format(r.item.cvss) if r.item.cvss is not none else '—' }} {{ r.item.title }} {{ r.feed_name }} {{ r.item.published }} {{ r.item.fetched_at|localtime }}
{% else %}

No intel matches yet for these CVEs. Configured feeds may not have surfaced them, or none of your feeds cover this CVE source. Add or fetch feeds on Feeds.

{% endif %}
{% endif %}

Remediation

{% if existing_changes %}

This finding already has {{ existing_changes|length }} change(s):

{% endif %} {% if remediators %}

Auto-fix available via {{ remediators|join(', ') }}. Proposed changes are reviewable before any file is touched; backups are taken automatically.

{% else %}
No automated remediator for this finding.

Phase 1 covers SUPPLY_CHAIN findings (pip_audit / grype / osv_scanner) and Nuclei missing security header findings. Other categories — Bandit, Semgrep, secrets, MCP scope, AI red-team — go on the human path. Open a ticket against {{ finding.adapter }} + {{ finding.category.value }} for AppSec triage.

{% endif %} View remediation queue
{% endblock %}