[Spike] Investigate a vulnerability report process

[thepetk]

Which area this user story is related to?

/area api
/area library
/area registry
/area alizer
/area landing-page

Issue description

As part of our security policy, recommended by the CLO Monitor best practices, we could implement a define a vulnerability report process. This way we help the users of devfile org repos to report vulnerabilities found inside the org, following a secure way.

This issue focuses only in the investigation part.

Acceptance Criteria

• Results of investigation have been shared

[thepetk]

I'd prefer following a simplistic approach, with a Security.md file that will simply mention how someone can share with the team that they have found a vulnerability. More detailed I'd suggest adding the below template:

# Reporting of Security Issues

The devfiles team takes immediate action to address security-related issues involving devfile projects.

Note, that normally we try to fix issues found for the latest releases of our projects. Backport fixes will be made only for exceptional cases, if the team has identified the need to do so.

## Reporting process

When a security vulnerability is found is important to not accidentally broadcast to the world that the issue exists, as this makes it easier for people to exploit it. The preferred way of reporting security issues in Devfiles is listed below.

### Email team devfile

An email to team devfile  is the preferred mechanism for outside users to report security issues. A member of the devfile team will open the required issues and keep you up-to-date about the status of the issue.

### What to avoid
Do not open a public issue, send a pull request, or disclose any information about the suspected vulnerability publicly, **including in your own publicly visible git repository**.

Thinking might be better to have a separate email like team-devfile-security@redhat.com? WDYT? @devfile/devfile-services-team

[Jdubrick]

I'd prefer following a simplistic approach, with a Security.md file that will simply mention how someone can share with the team that they have found a vulnerability. More detailed I'd suggest adding the below template:

# Reporting of Security Issues

The devfiles team takes immediate action to address security-related issues involving devfile projects.

Note, that normally we try to fix issues found for the latest releases of our projects. Backport fixes will be made only for exceptional cases, if the team has identified the need to do so.

## Reporting process

When a security vulnerability is found is important to not accidentally broadcast to the world that the issue exists, as this makes it easier for people to exploit it. The preferred way of reporting security issues in Devfiles is listed below.

### Email team devfile

An email to team devfile  is the preferred mechanism for outside users to report security issues. A member of the devfile team will open the required issues and keep you up-to-date about the status of the issue.

### What to avoid
Do not open a public issue, send a pull request, or disclose any information about the suspected vulnerability publicly, **including in your own publicly visible git repository**.

Thinking might be better to have a separate email like team-devfile-security@redhat.com? WDYT? @devfile/devfile-services-team

An email would be convenient we would just need to make sure it is monitored so we don't let things sit too long. I think possibly a section about where to reach us via slack is also good - Noting that they should request a private message in slack and not broadcast the vulnerability.

[thepetk]

I'd prefer following a simplistic approach, with a Security.md file that will simply mention how someone can share with the team that they have found a vulnerability. More detailed I'd suggest adding the below template:

# Reporting of Security Issues

The devfiles team takes immediate action to address security-related issues involving devfile projects.

Note, that normally we try to fix issues found for the latest releases of our projects. Backport fixes will be made only for exceptional cases, if the team has identified the need to do so.

## Reporting process

When a security vulnerability is found is important to not accidentally broadcast to the world that the issue exists, as this makes it easier for people to exploit it. The preferred way of reporting security issues in Devfiles is listed below.

### Email team devfile

An email to team devfile  is the preferred mechanism for outside users to report security issues. A member of the devfile team will open the required issues and keep you up-to-date about the status of the issue.

### What to avoid
Do not open a public issue, send a pull request, or disclose any information about the suspected vulnerability publicly, **including in your own publicly visible git repository**.

Thinking might be better to have a separate email like team-devfile-security@redhat.com? WDYT? @devfile/devfile-services-team

An email would be convenient we would just need to make sure it is monitored so we don't let things sit too long. I think possibly a section about where to reach us via slack is also good - Noting that they should request a private message in slack and not broadcast the vulnerability.

To give more context, I'm suggesting the idea of a new email as we might want to have a smaller group of people as the contacts for those sensitive issue. I'm also good to use the team-devfile one if we're ok with the current list of people who have access to this group.

I'm on the fence for slack tbh. Initially I thought about it but experience says sometimes people find it complicated to identify specific people in a community server/channel.

[thepetk]

@Jdubrick overall I think we agree that the format of the file should be this. I'm going to close this issue as it's an investigation and I'll open a PR in the api to with what I've shared here. We can continue the review there :)