fix: resolve 44 code scanning alerts

[imran-siddique]

Fixes 44 alerts: clear-text logging, URL sanitization, token permissions, pinned deps.

[github-actions]

Dependency Review

The following issues were found:

• ✅ 0 vulnerable package(s)
• ✅ 0 package(s) with incompatible licenses
• ✅ 0 package(s) with invalid SPDX license definitions
• ⚠️ 1 package(s) with unknown licenses.

See the Details below.

License Issues

.github/workflows/welcome.yml

Package	Version	License	Issue Type
actions/first-interaction	34f15f4562c5e4085ea721c63dadab8138be06db	Null	Unknown License

Allowed Licenses: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, PSF-2.0, Python-2.0, 0BSD, Unlicense, CC0-1.0, CC-BY-4.0, Zlib, BSL-1.0, MPL-2.0

OpenSSF Scorecard

Package	Version	Score	Details
actions/codelytv/pr-size-labeler	4ec67706cd878fbc1c8db0a5dcd28b6bb412e85a	Unknown	Unknown
actions/actions/first-interaction	34f15f4562c5e4085ea721c63dadab8138be06db	🟢 4.6	Details Check Score Reason Dangerous-Workflow 🟢 10 no dangerous workflow patterns detected Maintained ⚠️ 0 0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0 Packaging ⚠️ -1 packaging workflow not detected Code-Review 🟢 3 Found 1/3 approved changesets -- score normalized to 3 Binary-Artifacts 🟢 10 no binaries found in the repo CII-Best-Practices ⚠️ 0 no effort to earn an OpenSSF best practices badge detected Token-Permissions ⚠️ 0 detected GitHub workflow tokens with excessive permissions Pinned-Dependencies 🟢 3 dependency not pinned by hash detected -- score normalized to 3 License 🟢 10 license file detected Fuzzing ⚠️ 0 project is not fuzzed Signed-Releases ⚠️ -1 no releases found Security-Policy 🟢 9 security policy file detected Branch-Protection ⚠️ 1 branch protection is not maximal on development and all release branches SAST 🟢 9 SAST tool detected but not run on all commits

Scanned Files

• .github/workflows/pr-size.yml
• .github/workflows/welcome.yml

In general, to fix clear-text logging of sensitive data, either (a) stop logging the sensitive value, (b) fully mask/redact it so no original characters remain, or (c) transform it into a non-reversible surrogate (e.g., a hash) that is not directly identifying. For PHI such as patient_id, HIPAA-oriented examples should avoid logging any recognizable portion of the identifier.

The minimal change that preserves existing behavior while removing the risk is: in access_patient_data, stop showing even a partially redacted patient_id in logs. Instead, either log a constant message (“Accessing patient data”) or log a non-sensitive surrogate derived from patient_id (e.g., a hash) if traceability is required. Since we must not assume external config and should avoid extra complexity, the simplest and safest fix here is to remove the interpolation of patient_id from the log entirely.

Concretely, in packages/agent-mesh/examples/03-healthcare-hipaa/main.py:

• Change line 96 from print(f"📂 Accessing patient data: {_redact(patient_id, 3)}") to a version that does not include patient_id, e.g. print("📂 Accessing patient data").
• No additional imports or helper methods are required for this fix.
• We leave _redact untouched because it might be used elsewhere; CodeQL’s specific tainted path is resolved by removing patient_id from this log message.

To fix the problem, ensure that the logging statement never prints any part of sensitive or tainted data in clear text. Since label is tainted along the path, the _redact function should not reveal any portion of the original string when used for potentially sensitive values, and the call site should avoid relying on partial visibility of the original data.

The best minimal fix is:

1. Strengthen _redact so that it does not leak any characters from the original string, regardless of visible_chars. This ensures that any sensitive data passed through it is completely masked.
2. Adjust the deployment gate print statement to avoid depending on the original label contents for formatting. Instead, log only non-sensitive information such as the deployment status and a generic placeholder label or the risk level if that is considered non-sensitive, while still using _redact for safety.

Concretely:

• In packages/agent-mesh/examples/06-eu-ai-act-compliance/demo.py, update _redact (lines 23–30) so that it always returns "***" (or a similar constant) and ignores visible_chars. This preserves the intent of redaction but removes partial exposure.
• Update the line 138 print statement so that it no longer formats the original label via _redact(label, 20). For example, either:
  • Use _redact("agent", 0) as a neutral placeholder string, or
  • Replace the redacted label with a generic "AGENT" placeholder while retaining the rest of the message.

This keeps functionality essentially the same (a deployment gate summary is printed) while ensuring that no user- or environment-derived strings are logged.

No new imports or external methods are required.

---

In general, the fix is to ensure that sensitive data (here, an SSN-like value) is not logged in clear text, even partially. That means either not logging the sensitive string at all, or logging only a fully redacted or synthetic version that cannot reveal the SSN.

The minimal, behavior-preserving fix is to change the specific print statement in packages/agent-os/examples/financial-sox/demo.py so it does not expose the tainted ssn_message content. Since the demo already computes redacted_msg using a regex that fully masks the SSN, we can log that value instead of the partially redacted _redact(ssn_message, 11). This keeps the demo understandable (it still shows an input string with an SSN masked) while avoiding logging the original sensitive text. Concretely, on line 372 we replace:

print(f'  Input: "{_redact(ssn_message, 11)}"')

with:

print(f'  Input: "{redacted_msg}"')

No new imports or helper functions are required; we only reuse the existing redacted_msg variable calculated on line 371.

In general, to fix clear-text logging of sensitive information, ensure that logs contain only non-identifying metadata (e.g., an internal audit ID, role, action, timestamps) and never PHI/PII, even partially. Where correlation is needed, log a non-sensitive surrogate such as an audit ID or an opaque, non-reversible token.

For this specific case, the best fix that preserves existing functionality is to stop logging the patient_id value (even in partially redacted form) and instead log a non-sensitive surrogate that’s already available: the most recent audit_id from self.audit_log.entries[-1].audit_id. This still lets operators correlate a log line (“Chart Review Request”) with the corresponding audit trail without exposing the patient identifier. Concretely, in review_chart we will change the line:

print(f"   Patient: {_redact(patient_id, 3)}")

to instead print the audit id, for example:

print(f"   Audit ID: {self.audit_log.entries[-1].audit_id}")

No new imports or helpers are required; self.audit_log is already used later in the method to return audit_id, so we are reusing existing functionality. All other behavior (access checks, role-based output, return payload) remains unchanged.

---

In general, to fix clear‑text logging of sensitive data, avoid logging the sensitive value at all, or replace it with a fully redacted placeholder or a non‑sensitive surrogate (such as an internal audit or correlation ID). Partial masking that reveals some characters can still be considered PHI/PII leakage, especially in healthcare contexts, so the safest fix is to omit the value or log only derived, non‑reversible identifiers.

For this specific case in packages/agent-os/examples/healthcare-hipaa/main.py, the best fix without changing functional behavior is:

• Stop logging any part of patient_id in the emergency access request banner.
• Instead, log a generic placeholder like [PATIENT_REDACTED] while preserving the log structure and other fields (User, Reason, and the compliance warnings).
• This change is localized to the emergency_access method: update the print(f" Patient: {_redact(patient_id, 3)}") line to print a constant redacted label.

No new methods or imports are required; we reuse existing behavior and only adjust the log format string.

General fix: Do not log values that derive from PHI/PII or sensitive medical information unless they are properly de-identified and aggregated. Where logging is necessary, ensure that logged data cannot be linked to an individual patient (e.g., remove patient-specific context, use aggregates across many patients, or use synthetic demo data clearly separated from real runs).

Concrete best fix here without changing functionality of the core agent:

• Leave review_chart’s returned structure unchanged (so application logic using findings_count remains intact).
• Adjust only the example/demo code in the __main__-style test block (around lines 800–809) so it no longer prints the tainted findings_count associated with a specific patient_id.
• Since the count is only printed for demonstration, we can either:
  • remove the line entirely, or
  • replace it with a non-sensitive, static message (e.g., “Findings count: *** (hidden in logs)”).
• This change stays within packages/agent-os/examples/healthcare-hipaa/main.py and requires no new imports.

Specifically, modify line 805:

print(f"Findings: {_redact(result.get('findings_count', 0), 5)}")

to avoid reading/logging findings_count from result. For example:

print("Findings: *** (count hidden from logs for HIPAA compliance)")

This preserves the example flow while ensuring no tainted value is logged.

---

In general, to fix clear-text logging of sensitive information, you either (1) avoid logging the sensitive value altogether, or (2) ensure it is irreversibly and fully masked or aggregated so that no sensitive content remains. For PHI/PII in particular, logs should not contain identifiers or detailed clinical attributes that could be linked back to an individual.

For this specific case, the tainted field is f["severity"], which is then passed through _redact(..., 10) and logged. Because _redact allows the first visible_chars characters through, CodeQL still considers this a clear-text leak. The simplest fix without changing application behavior materially is to stop logging the severity string and replace it with a non-data-bearing placeholder (e.g., just "finding detected") or an ordinal index. This removes the tainted data from the log entirely while preserving the informational value that there was a finding and whether it was critical (which is already reflected by the icon chosen earlier).

Concretely, in packages/agent-os/examples/healthcare-hipaa/main.py, update line 808 within the first test block after result = await agent.review_chart("P12345", doctor, "routine_review"). Replace the formatted string that includes [{_redact(f.get('severity', ''), 10)}] with a string that omits severity altogether, such as f" {icon} finding detected". No new imports or helper functions are required; we are simply removing the sensitive (tainted) value from the log.

In general, to fix clear-text logging of sensitive information, either (a) avoid logging sensitive values altogether, or (b) ensure redaction/aggregation such that no PHI/PII can be reconstructed from logs. Taint analyses are conservative, so any value derived from PHI should be treated as sensitive, even if it “looks” harmless.

For this specific case, result is tainted because it originates from patient_id. Even though status is designed as a constant like "completed" or "denied", CodeQL flags it because it flows through the tainted dict and into _redact, which may reveal a portion of the value. The simplest, safest, and behavior-preserving fix is to stop logging the tainted status value and instead log an equivalent non-tainted representation. We can do this by:

• Computing a local, non-tainted indicator from result['status'] (e.g., a boolean or fixed string) without echoing the underlying tainted value, or
• Logging a fixed message that does not include any data flowing from the request/patient, or
• In this test harness, simply removing the Status: line if it’s not essential.

To minimally change functionality while satisfying HIPAA constraints and the static analyzer, we will replace:

print(f"Status: {_redact(result.get('status', ''), 10)}")

with a print that does not log the tainted value. A simple approach is:

status_ok = result.get("status") == "completed"
print(f"Status: {'success' if status_ok else 'not completed'}")

Here, the string literals 'success' and 'not completed' are constants not derived from user/PHI input, so there is no PHI logged. The behavior (informing the user whether the operation completed) is preserved at an appropriate level of abstraction. No new imports or helper methods are required.