Sensitive data reaches logs / Sensitive data reaches a forbidden destination
Rule ID: security.sensitive-data-flow@1.0.0. Availability below refers to source-scan at product 524fa07e.
V-SEC-01 — Sensitive data reaches logs#
Sensitive data reaches logs. It examines trust boundaries, sensitive flows, validation, and security-sensitive effects.
Availability#
Not available in source-scan. There is no source-scan flag to activate this condition.
Example and action#
Illustrative pattern only. This is not a complete runnable package or a reproduced source-scan result. Helper APIs and omitted context must be supplied by the application.
logger.write("Authorization: \(token)")Confirm the trust boundary and required security property. Apply the API-specific protection at the sensitive operation and review all bypass paths.
logger.write("Authorization attempt completed")Intended analysis#
Intended reasoning: Relate the selected security contract to a source, transformation and sensitive operation. The intended check requires identity, flow and policy evidence; a suspicious API name alone does not establish exploitation. Required evidence: source, sink, trust, policy, validation, and flow facts
Assumptions and unknown#
The relevant facts must be admitted for the selected immutable build world. Unknown aliases, external effects, unsupported source forms or incomplete consumers can prevent a conclusion. Availability in this workflow is stated above; the illustration does not expand that availability.
Evidence and interpretation#
The target catalog describes the intended condition. It is not evidence of an active source-scan diagnostic.
Historical evidence at 4558458d: recovery-required (historical qualification is incomplete and needs further evidence). That evidence has not been requalified for this product revision.
How we validate checks explains the evidence boundary. Foundations separates method assumptions from implementation claims.
V-SEC-02 — Sensitive data reaches a forbidden destination#
Sensitive data reaches a forbidden destination. It examines trust boundaries, sensitive flows, validation, and security-sensitive effects.
Availability#
Not available in source-scan. There is no source-scan flag to activate this condition.
Example and action#
Illustrative pattern only. This is not a complete runnable package or a reproduced source-scan result. Helper APIs and omitted context must be supplied by the application.
analytics.send(["email": account.email])Confirm the trust boundary and required security property. Apply the API-specific protection at the sensitive operation and review all bypass paths.
analytics.send(["event": "account_opened"])Intended analysis#
Intended reasoning: Relate the selected security contract to a source, transformation and sensitive operation. The intended check requires identity, flow and policy evidence; a suspicious API name alone does not establish exploitation. Required evidence: source, sink, trust, policy, validation, and flow facts
Assumptions and unknown#
The relevant facts must be admitted for the selected immutable build world. Unknown aliases, external effects, unsupported source forms or incomplete consumers can prevent a conclusion. Availability in this workflow is stated above; the illustration does not expand that availability.
Evidence and interpretation#
The target catalog describes the intended condition. It is not evidence of an active source-scan diagnostic.
Historical evidence at 4558458d: recovery-required (historical qualification is incomplete and needs further evidence). That evidence has not been requalified for this product revision.
How we validate checks explains the evidence boundary. Foundations separates method assumptions from implementation claims.