feat: Split validations to required (stopping release) and optional (not stopping the release)

[andreaangiolillo]

Proposed changes

This PR splits the validations into two required validations, which will stop the release and file an GH issue in the repo, and optional validation which will not stop the release but only file an issue in the repo.

I tested my changes in a fork: https://github.com/andreaangiolillo/openapi-test/actions/runs/10060430357

Example of an issue created: andreaangiolillo#1

[matt-condon]

LGTM very nice PR 🫶

[matt-condon]

(interest piqued) do we normally pin these actions versions?
Any particular reason?

[andreaangiolillo]

The security team recommended using a specific SHA version for actions to prevent the risk of using a maliciously modified action. For GitHub actions like actions/checkout, this isn’t necessary because they are considered secure. However, I copied and pasted from another action xD

Based on The GitHub Actions Worm: Compromising GitHub Repositories Through the Actions Dependency Tree (paloaltonetworks.com)

How to Protect Your Workflows and Assets
Multiple security controls can prevent or raise the difficulty of successfully attacking repositories using the worm. In order of effectiveness, controls include:

• Set GITHUB_TOKEN and PAT contents permission to the minimum required — with special attention to reducing write permissions against the repository — to prevent infection by the worm. Consider using GitHub’s actions-permissions project to reduce workflow permissions. In general, implement strict PBAC (Pipeline-Based Access Controls) to make sure the workflow is granted with the least privileges and access it needs to fulfill its purpose.
• Configure branch and tag protection to further prevent infection and protect the codebase.
• Monitor and limit outbound network connections from workflow runners to prevent the download of malicious code into pipelines and prevent malware from reporting to C2 servers.
• Pin actions using a commit hash to reduce the risk of using a maliciously modified action.

[matt-condon]

Thank you!
@Luke-Sanderson could you double-check to make sure any actions introduced for Postman have pinned versions?

[Luke-Sanderson]

I was using the version tag rather than commit hash. I assume this has the same security implications? I chose to use the version tag because that was used in the Go-SDK

[andreaangiolillo]

We can use the secrets exfiltrated in the flow to infect the repository with malicious code. Overwriting a commit while keeping its hash the same isn’t possible, so we can’t abuse a commit hash reference. We still have two options:

• Infecting by pushing code to a branch: We can use the GITHUB_TOKEN or PAT used in a job to push malicious code to a branch if the token is granted with the contents:write permission.
• Infecting by creating a tag: We can use the GITHUB_TOKEN or PAT used in a job to create a malicious tag or override an existing tag to infect dependent repositories referencing the action by a tag.

[Luke-Sanderson]

Ah okay makes sense. I have only used actions/checkout and actions/cache so far but I'll keep that in mind if I use any external actions in the future.