Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supported Dependencies and Security Policy #2204

Open
balhar-jakub opened this issue Apr 4, 2024 · 3 comments
Open

Supported Dependencies and Security Policy #2204

balhar-jakub opened this issue Apr 4, 2024 · 3 comments
Assignees
Labels
new TSC Technical Steering Committee

Comments

@balhar-jakub
Copy link
Member

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 balhar-jakub added TSC Technical Steering Committee new labels Apr 4, 2024
@balhar-jakub balhar-jakub self-assigned this Apr 4, 2024
@balhar-jakub
Copy link
Member Author

balhar-jakub commented Apr 11, 2024

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
Copy link
Contributor

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new TSC Technical Steering Committee
Projects
None yet
Development

No branches or pull requests

2 participants