A recent change merged Secrets Manager values into os.environ, which exposed runtime secrets to any action that can read arbitrary environment variables; this change prevents that exfiltration vector for Salesforce private keys.
The intent is to preserve the action's ability to return a Connected App private key while disallowing caller-controlled selection of arbitrary env vars that may contain unrelated secrets.
Custom secret_name values should still be usable when they point to a file path containing the PEM private key, and the default <connected_app_id>_private_key env lookup must continue to work.
Description
Restrict secret_name semantics in apps/salesforce_service_cloud/actions/retrieve_connected_app_private_key.py so custom values are treated as file paths and environment-variable lookup is limited to the default f"{connected_app_id}_private_key" key.
Add a content validation step that rejects values that do not contain a PEM private key before returning them as private_key_pem.
Update the secret_name field description and examples to document the new restriction and add a # mercury: allow-env-use comment at the single allowed env lookup site.
Add regression tests in tests/test_apps/test_salesforce_service_cloud/test_retrieve_connected_app_private_key.py covering default env lookup, rejection of arbitrary env-var names, file-path support, and rejection of non-PEM values.
Testing
Ran uv run pytest -q tests/test_apps/test_salesforce_service_cloud/test_retrieve_connected_app_private_key.py tests/test_secrets.py and the test suite passed (21 passed).
Ran the direct-env-access CI check with uv run python ci_checks/lint_direct_env_access.py which reported no issues.
Ran uv run ruff check apps/salesforce_service_cloud/actions/retrieve_connected_app_private_key.py tests/test_apps/test_salesforce_service_cloud/test_retrieve_connected_app_private_key.py and linting passed.
@venkat82checks…codex/propose-fix-for-secrets-exposure-vulnerability → master2 files · +88 −9updated 1w ago