Supported Dependencies and Security Policy

[balhar-jakub]

Zowe should take into account when preparing for the release whether there are any components that are out of support or doesn't have community at all.

The top-level-dependencies should be reflected.

The supported components has few characteristics:

• Either they have Active Lifecycle Management explained in which case there is clear statement on when and what versions are supported
• For the rest these are warning sign:
  • They don't have that kind of lifecycle management
  • There is no webpage with information
  • The project doesn't have Open SSF Badge at least the Basic
  • There is no place to discuss or can't be find
  • The release cadence is less than once a year
  • The list of contributors in last two years in the repository has less than three names

If there is at least one warning sign, the squad should for every release grant an exception to release with such component If there are two or more, the security workgroup needs to agree with the exception If there are four or more, the TSC needs to agree with the exception.

If there is an Active Lifecycle Management and the version is out of support, the TSC approval is necessary to ship with that component in the relevant version.

[balhar-jakub]

The top-level dependencies must be analysed before every major release. The support needs to be treated in following way:

• There is an Active Lifecycle Management policy
  • For every major release, we must use versions that are supported
• There is no Active Lifecycle Management policy (This in itself is a warning)
  • Red flags
  • 0 Committers
  • No release for more than two years
  • Orange flags
  • Releasing once a year or less
  • There is no place to discuss
  • There is no webpage with information
  • There are less than 5 contributors in last 12 years
  • The score on scorecards is either unavailable or below 4

For every major release, approval by TSC is necessary for the following:

• Versions of libraries with Active Lifecycle Management policy that aren't supported at the time of release
• Versions without Active Lifecycle Management Policy that have
  • one or more red flags
  • three or more orange flags if there is no red flag

For every major release, the squad must accept risk for libraries without an Active Lifecycle Management Policy that have less than three orange flags. This must be documented in a searchable way.

[adam-wolfe]

I think the proposal is reasonable. However, I'm wondering what we should do with respect to versioning for packages that do not have an active lifecycle management policy (which is the case for most CLI/Explorer for VS Code dependencies).

For dependencies that have no red flags and have less than 3 orange flags, we might be several versions behind the latest major release of the dependency. Should the policy include that these should either be updated to the latest major version on each Zowe major version release or the squad should request an exception?

[balhar-jakub]

Yes, that's a good point, I will try to update the text to make it clear.

The top-level dependencies must be analysed before every major release. The support needs to be treated in following way:

• There is an Active Lifecycle Management policy
  • For every major release, we must use versions that are supported
• There is no Active Lifecycle Management policy (This in itself is a warning)
  • Red flags
  • 0 Committers
  • No release for more than two years
  • Orange flags
  • Releasing once a year or less
  • There is no place to discuss
  • There is no webpage with information
  • There are less than 5 contributors in last 12 years
  • The score on scorecards is either unavailable or below 4

For every major release the libraries without active lifecycle management policy needs to be updated to the latest available version.

For every major release, approval by TSC is necessary for the following:

• Versions of libraries with Active Lifecycle Management policy that aren't supported at the time of release
• Libraries without Active Lifecycle Management Policy that have
  • one or more red flags
  • three or more orange flags if there is no red flag
  • more recent versions that the squad doesn't want to update to.

For every major release, the squad must accept risk for libraries without an Active Lifecycle Management Policy that have less than three orange flags. This must be documented in a searchable way.