Sensitive data flow

What mcp-scan saw

No scanner in mcp-scan emits this id. It exists in the SARIF_RULES metadata table in src/utils/sarif-reporter.ts and in no other file in src, so nothing in a scan can produce it. The description below is the SARIF full text, not a derived trigger.

Why it fires

The SARIF entry describes data flowing from a sensitive source to an external sink. In the shipping scanners that shape is emitted under other ids: data-exfiltration-risk for a filesystem, database, or clipboard source paired with a network or process sink, and credential-relay-risk for an env source paired with the same sinks. This entry appears to be a reserved or superseded id retained in the metadata table.

This page is derived from the rule's reported description; the trigger detail has not been re-checked against the emitting scanner's source yet.

When this is a false positive

• Seeing this id in a SARIF file from mcp-scan would itself be the anomaly, since no scanner pushes it. Check what produced the file before treating it as a finding.
• A SARIF report merged from several tools can carry this id from a different scanner entirely, and the mcp-scan rule metadata would then be attached to someone else's finding.
• If you are looking for this rule after seeing a source-to-sink finding, the finding you actually have is data-exfiltration-risk or credential-relay-risk. Read those entries instead.

How to fix it

1. Confirm which tool emitted the result. mcp-scan's own scanners do not push this id.
2. If the SARIF came from mcp-scan alone, the rule appears in the rules table only because the reporter registers metadata for known ids, and no result should reference it.
3. For a real source-to-sink concern, work from the data-exfiltration-risk and credential-relay-risk entries, which document the triggers that actually fire.
4. Suppressing this id in .mcp-scan.json has no effect, since nothing produces it.