chore(security): add ReversingLabs malware scan workflow

[nirmal-joishi-a0]

✏️ Changes

This pull request adds a security hardening workflow. No functional changes are introduced.

🚧 Untested — automated PR. This is a reusable workflow (workflow_call) — it does not run on its own and cannot be validated by merging. To test it, complete the setup steps below, then confirm the scan passes. Do not merge solely because checks appear green.

No release/build CI to wire it into? If this repo builds manually, add CI if viable — otherwise decline with the remediation: not-applicable label.

If the run fails for repo-specific config we can't see (a missing secret, environment/IAM setup), fixing it before merging is the repo owner's responsibility.

ReversingLabs Malware Scan

This PR adds .github/workflows/rl.yml. It is a reusable workflow (workflow_call) that wraps the okta-approved auth0/devsecops-tooling/.github/actions/rl-scan action.

⚠️ Before merging, complete the two steps below.

Steps to wire it up

1. Replace the placeholder build step in rl.yml with all steps that produce your artifact at the artifact-path you pass — toolchain setup, dependency install, compile, and package.
2. Add a caller in your release or CI workflow, for example:

   jobs:
     rl-scan:
       uses: ./.github/workflows/rl.yml
       with:
         artifact-name: my-artifact
         artifact-path: dist/my-artifact.tgz   # concrete file path — no globs or directories
         version: ${{ github.event.release.tag_name }}
       secrets: inherit

   artifact-path must be a concrete file — the action's [ -f ] check rejects globs/directories and a missing path fails the job.

Required org secrets — all 8 must be present

The rl-scan action declares all 8 as required inputs — if any is missing or empty the scan job fails. Confirm each is available to this repo (set at the auth0/ org level) before merging:

• RLSECURE_LICENSE, RLSECURE_SITE_KEY — ReversingLabs license + site key
• SIGNAL_HANDLER_TOKEN, SIGNAL_HANDLER_DOMAIN — scan telemetry auth + endpoint
• PRODSEC_TOOLS_ARN — AWS IAM role assumed via OIDC (see below)
• PRODSEC_TOOLS_USER, PRODSEC_TOOLS_TOKEN, PRODSEC_PYTHON_TOOLS_REPO — private ProdSec Python index creds + URL

AWS OIDC trust — required, not just a secret

The action authenticates to AWS by assuming PRODSEC_TOOLS_ARN via GitHub OIDC (no static keys), so two things must be in place:

• Job permission: the workflow already sets id-token: write (mints the OIDC token) and contents: read. Removing id-token: write breaks the AWS step.
• IAM trust policy: the role's trust policy must allow this repository to assume it. If it does not yet trust this repo, Configure AWS credentials fails even with every secret set — an infra change the repo/org owner must arrange before merging.

🟠 Declining this workflow

This is an organization-enforced security-hardening workflow, so closing this PR is not enough — the tool treats a plain close as a discard and opens a fresh replacement PR on its next run.

To permanently decline this category, a maintainer must close this PR and add one of these labels to it:

Label	Use when
remediation: not-required	The category is already handled another way for this repo.
remediation: not-applicable	The category genuinely does not apply (e.g. there is no manifest to scan for SCA, or no release/build CI to wire the malware scan into).

Applying a label requires write, triage, or admin access, so the label is a trusted maintainer signal. Once a closed PR carries one of these labels, the tool respects the decline and will not reopen a replacement.

🔮 Type of Change

• Standard

🔗 References

This change applies a standard automated security-scanning workflow as part of routine repository hardening.

• I explained why this change is needed.

📖 Documentation

No user-facing changes have been introduced.

• I reflected this change in the (internal and/or user-facing) documentation, or added an explanation for why no documentation update is needed.

🎯 Testing

⚠️ This reusable workflow has not been tested in this Repository. Wire it up (steps above) and run it green in this PR — or, if there's no release/build CI to call it, decline with remediation: not-applicable.

• Wired into CI and run green in this PR (or declined as not-applicable).

🚀 Deployment

• This change can support multiple releases of the code serving traffic at the same time.

🔥 Rollback

Reverting this PR removes the added workflow file — no further action required.

• I explained what the rollback for this change will look like.

---

Supersedes #418, a previous remediation PR for this workflow that was closed. This workflow is organization-enforced, so a fresh PR was opened to replace it.

[nirmal-joishi-a0]

The previous remediation PR for this workflow was closed. This is an organization-enforced, mandatory security-hardening workflow, so we've opened a new PR to replace the discarded one. Please review the changes and update them if needed. Note: this workflow is untested in this repo — confirm it triggers and passes before merging; do not merge on a green result alone. To permanently decline this workflow, closing this PR is not enough (a fresh replacement will be opened): close it AND add one of these labels — remediation: not-required (handled another way) or remediation: not-applicable (does not apply here). Adding a label needs write/triage/admin access, so it is treated as a maintainer's decision and no replacement will be opened.

[nirmal-joishi-a0]

@auth0/project-dx-sdks-engineer-codeowner please review the files in the PR. This automated security-hardening workflow is untested in this repo — before merging, confirm it triggers and passes (and is not silently ignoring failures); do not merge on a green result alone.

[nirmal-joishi-a0]

An internal service ticket has been filed for the owning team to review and merge this PR.