[nirmal-joishi-a0]

✏️ Changes

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

🚧 Automated PR — verify before merging. It runs on this PR, so confirm it actually triggers and passes, and that a green result is not masking a skipped or silently-ignored scan. Do not merge solely because checks appear green.

If the run fails for anything specific to this repo — a missing secret, environment setup, or other config only this repo needs (which we, as external authors, have no visibility into) — fixing it before merging is the repo owner's responsibility.

OpenSSF Scorecard

This PR adds .github/workflows/scorecard.yml. It calls ossf/scorecard-action directly (SHA-pinned to v2.4.3) — no composite action wrapper, no cross-org dependency. Results are uploaded to the Code Scanning dashboard via github/codeql-action/upload-sarif.

⚠️ Before merging, review the added .github/workflows/scorecard.yml and make the changes described below, plus any other adjustments your CI environment requires.

🧪 Smoke test only on this PR — not authoritative. The pull_request trigger runs this workflow on a real runner from this PR, giving you a pre-merge smoke run. workflow_dispatch does not run from this PR — GitHub offers manual dispatch only for a workflow already on the default branch, so it becomes available for manual re-runs only after this PR merges. OSSF officially documents both triggers as experimental (scorecard-action README: "The pull_request and workflow_dispatch triggers are experimental"); the supported triggers are push and schedule on the default branch. Treat a green pull_request run here only as a signal that the workflow ran — it is considered fully validated only after merge to the default branch, where it runs on the supported push and weekly schedule events. Code Scanning (SARIF) upload is skipped only on fork PRs (their token can't write it); it runs on same-repo PRs and on push/schedule after merge.

If the workflow fails specifically on the experimental pull_request trigger, you may remove both the pull_request and workflow_dispatch triggers and keep only the supported push and schedule events. In that case there is no PR-time smoke test, so validation happens by merging the PR once and confirming the workflow runs on the resulting push to the default branch.

Placeholders to fill in before merging

Placeholder	Description
publish_results: false	Default. Set to true to publish results to the public Scorecard API and enable the badge — also requires uncommenting id-token: write in the job permissions. Leave as false to keep results private (the id-token: write line can remain commented out).

🟠 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 workflow runs on this PR. Before merging, confirm that run triggers and passes, and that a green result is not masking a skipped or silently-ignored scan.

• The PR run has been verified green in this repository's CI (not a skipped/empty result).

🚀 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.

Summary by CodeRabbit

• Chores
  • Added automated security analysis for changes to the main branch, pull requests, and scheduled runs.
  • Scan results are available in code scanning when supported, with downloadable reports retained for five days.

[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.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: c9eb80f5-2721-4b97-a684-8dc3a1db2c87

📥 Commits

Reviewing files that changed from the base of the PR and between 030b6c2 and 7e0614e.

📒 Files selected for processing (1)

• .github/workflows/scorecard.yml

Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review.

📝 Walkthrough

Adds a GitHub Actions workflow that runs Scorecard on configured events. The workflow saves its SARIF output as an artifact and uploads it to Code Scanning except for fork pull requests.

Changes: Scorecard workflow

Layer / File(s)	Summary
Workflow triggers and permissions .github/workflows/scorecard.yml	Documents the workflow and configures push, pull request, manual, and scheduled triggers. Sets workflow-level and job-level permissions.
Analysis and SARIF handling .github/workflows/scorecard.yml	Checks out the repository without persisting credentials and runs the pinned Scorecard action with result publishing disabled. Stores the SARIF output as a five-day artifact and uploads it to Code Scanning except for fork pull requests.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Other

Suggested reviewers: amitsingh05667

Merge Risk: ⚪ Minimal · up to 7e061

This adds a security-scanning workflow and does not change product behavior. Permissions are narrow and no concrete defect was found. Confirm the workflow runs successfully on the default branch after merge.

### Architecture Summary

Architecture risk: 🔵 Low · up to 7e061

The changed surface does not map to a changed system, dependency edge, entrypoint, or external dependency.

Changed systems: None identified.

Architecture concerns
No architecture-level concerns identified.

Review details

Before / after behavior

• observed — Modified behavior in .github/workflows/scorecard.yml: Adds workflow documentation describing its triggers, experimental smoke-test cases, checkout credential setting, and Scorecard publishing requirements.
• observed — Modified behavior in .github/workflows/scorecard.yml: Configures push and pull-request triggers for main, manual dispatch, and a weekly Saturday schedule. Sets read-all workflow permissions; the analysis job grants security-events: write and contents: read, with id-token: write commented out.
• observed — Modified behavior in .github/workflows/scorecard.yml: Adds checkout with credential persistence disabled and runs the pinned Scorecard action to produce SARIF results. Sets publish_results to false.
• observed — Modified behavior in .github/workflows/scorecard.yml: Uploads the SARIF file as an artifact with five-day retention and to Code Scanning, except on fork pull requests.

Pre-merge checks · 5

Passed checks (5 passed)

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly and concisely identifies the main change: adding an OpenSSF Scorecard workflow for security checks.
Docstring Coverage		No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Warning

⚠️ This pull request has been flagged as potential spam (promotional) by CodeRabbit slop detection and should be reviewed carefully.

_{Comment @coderabbitai help to get the list of available commands.}

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[pmathew92]

What exactly is the trigger we are targeting here. since we don't directly push to main all changes are merged via PRs to main. This trigger will run the check two times.
Is this also expected to run for external PRs?

[pmathew92]

cc @nirmal-joishi-a0

[nirmal-joishi-a0]

The exact trigger that openssf scorecard mainly works on as of now is a push to default branch and a cron schedule, hence we are targeting those. As mentioned in the comment, the PR trigger is experimental and is used mainly for smoke testing this workflow before merging, you can remove it once you verify this works pre or post merge. We don't expect this workflow to run for every PR including external, that is a decision for you and your team.