Add Slack notification workflow for PR events

[OS-miguelfreitas]

Introduces a GitHub Actions workflow to send Slack notifications when a pull request is opened or marked ready for review by specific users. The workflow uses a Slack webhook and includes PR details in the notification payload.

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.

[wiz-code-outsystems]

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	-
Sensitive Data	-
Secrets	-
IaC Misconfigurations	1  1
SAST Findings	-
Software Management Findings	-
Total	1  1

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

Pull Request Developer Guidance

Questions? See the Wiz FAQ.

Please contact the Security Office if you encounter issues with Wiz PR scanning.

In general, the fix is to explicitly set a restrictive permissions: block either at the workflow root or within the job so that GITHUB_TOKEN has only the minimal needed permissions. Since this workflow only reads pull request metadata (via github.event) and posts to Slack with a secret webhook, it does not need to use GITHUB_TOKEN at all. The safest configuration is to set permissions: {} at the workflow level (disabling all default permissions) or, if you prefer to keep minimal read access, use permissions: contents: read. Because the workflow doesn’t call the GitHub API via GITHUB_TOKEN, disabling all permissions is appropriate and does not change existing functionality.

Concretely, in .github/workflows/SlackNotification.yml, add a permissions: block near the top of the file, at the same indentation as on: and name:. This will apply to all jobs in the workflow, including slackNotification. No imports or additional methods are needed; this is purely a YAML configuration change. The best single change is:

name: Slack Notification

permissions: {}
on:
  pull_request_target:
  ...

This ensures that the GITHUB_TOKEN granted to the workflow has no repository permissions.