[SSDF Epic] PS: Protect software

[jiekang]

This issue tracks the PS SSDF items and will also contain more detail for them:

Work that addresses these items can reference this epic issue.

• PS.1.1: Store all forms of code, including source code, executable code, and configuration-as-code, based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access
  1. All repositories used to store source code and binary artifacts used in Adoptium offerings must be disclosed as part of Adoptium's internal security assessment and determined to meet all security standards outlined in Adoptium's security repository controls
• PS.2.1: Make software integrity verification information available to all users
  1. All Adoptium offerings must adhere to the Adoptium signing process
     (provide (gpg ?) signed releases temurin-build#1275)
• PS.3.1: Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.
  1. All offerings must store all release files in a secure internal repository and restrict access to them. Each offering will maintain process documentation detailing, Source Code Management (SCM) information (repositories used, repository configurations/settings, version control logging, Risk-based Access Control (RBAC) & Access Control List (ACL) details).
• PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release via a software bill of materials [SBOM]
  1. Generate a machine-readable software bill of materials (SBOM) for each released version of all offerings that contains the following data elements at a minimum and provide this information to customers: Supplier, Component Name, Unique Identifier, Version, Component Hash, Relationship (i.e CONTAINS), SBOM Author

[smlambert]

I will be focussing on PS 3.2.

PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release via a software bill of materials [SBOM]
Generate a machine-readable software bill of materials (SBOM) for each released version of all offerings that contains the following data elements at a minimum and provide this information to customers: Supplier, Component Name, Unique Identifier, Version, Component Hash, Relationship (i.e CONTAINS), SBOM Author

There are already several issues opened related to this work, which I will assign myself.
adoptium/temurin-build#2900
adoptium/temurin-build#2813

[andrew-m-leonard]

I will look into PS.3.1: Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.

[andrew-m-leonard]

Initial comments:

PS.3.1: Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.

1. Might depend on what they mean by "release files" ? Suspecting they are talking about "source code release files", ie.the "source", not the "binaries"

2. Need to gather and maintain:

• List of repositories used, eg. skara mirror github repo, temurin-build repo
• To each repo, snapshot: Merged PRs since last release, "Write" access Adoptium Team members for each repo

3. Does "archive" mean "take a copy"? Do we currently archive/backup our github repos?

=================================

• We could argue simply having these files and supporting PR provenance in github.com repos, is sufficient, ie.by simply querying the github for the release in question gives you all the necessary files and provenance: eg.https://github.com/adoptium/jdk17u/commits/release
• And for access control these are "public" repos, so recording the "write" access Adoptium github Team information.
• Provenance is an interesting question, as essentially the source provenance is from OpenJDK and "everyone" who submits PRs to that upstream repository. Those PRs are recorded in the commits in the github repo, as to who each contributor is finding their github "profile" is about as far as it goes.

[steelhead31]

Im focussing on PS1.1, currently identifying and dcoumenting, the 46 GH repos in the adoptium project, breaking them into functional areas, and once that is completed, documenting the current access control mechanisms, and evaluating whether that meets the security standards detailed below.
'
PS.1.1: Store all forms of code, including source code, executable code, and configuration-as-code, based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access
All repositories used to store source code and binary artifacts used in Adoptium offerings must be disclosed as part of Adoptium's internal security assessment and determined to meet all security standards outlined in Adoptium's security repository controls'

Currently being worked on in issue #143

[steelhead31]

PS1.1 Documentation can be found on this https://docs.google.com/document/d/1NtG03VDr20DN8KX-wbdGr-lplMaXaSHfZQUMlDm7sCk/edit#heading=h.lwt7k16quujk

[tellison]

PS1.1 Documentation can be found on this https://docs.google.com/document/d/1NtG03VDr20DN8KX-wbdGr-lplMaXaSHfZQUMlDm7sCk/edit#heading=h.lwt7k16quujk

Thanks for this. Comments directly in the doc.