[SSDF Epic] A: Secure Adoptium

[jiekang]

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

Work that addresses these items can reference this epic issue.

• A.1.1: Defined support & lifecycle maintenance plan
  1. Adoptium will maintain published information detailing its support and maintenance policies, including plans for sunsetting the offering at the end of its lifecycle.
• A.1.2: Monitor and ensure the integrity of customer-facing repositories
  1. Adoptium must use public-facing repositories approved by the organization to store files for public access.
• A.2.1: Identify layered dependencies
  1. Adoptium must maintain documentation that details all of the offering’s layered dependencies. This documentation must be updated whenever there is a dependency change, or at least once prior to every major version release.
• A.2.2: Track Provenance and Pedigree
  1. Adoptium must be able to provide a report within 48 hours that shows the source of ALL included source code and binary artifacts (Provenance), as well as a record of all changes made to these items (Pedigree)
• A.3.1: Data lifecycle management
  1. Adoptium must adhere to organizational policies set forth by the ASG for managing it's data lifecycle
  2. Adoptium will maintain process documentation listing the data types (at rest or in transit), the level of sensitivity of each data type and the method(s) used to secure each data type.
• A.3.2: Data lifecycle validation
  1. Adoptium must protect customer data appropriately based upon the data type (at rest or in transit) and the level of sensitivity of each data type
• A.4.1: Conduct code scanning
  1. Adoptium will conduct reviews of the code, including scanning code released. These scans should include, but are not limited to: Scanning software for coding defects, Scanning software for known security vulnerabilities or secure coding errors, Scanning software for malicious content, such as rootkits or viruses

[jiekang]

For A.1.1, Adoptium has a support policy on:

https://adoptium.net/support.html

Action Items

• Possibly re-define the community level of support. The text mentions that "Our support means that you can raise an issue to describe a bug you have found in the build, and we will work with you and the appropriate development team to resolve it" but the response to a bug really depends upon the good will of the community. The text suggests that there will be response and work for every issue raised.
• Better define what artifacts are covered by the support policy: e.g. is Eclipse Mission Control supported?
• Adoptium vs. Temurin. The support page mentions Adoptium releases while the JDK is released as Eclipse Temurin. Should that be Temurin releases?
• We should mention the length of availability of our releases. Something like: "The most recent release for each major version will be kept available. Old releases will not be guaranteed to be kept forever."
• We should document the plan for when releases need to be sunsetted. In the current case, when the upstream OpenJDK is no longer maintained, we will stop performing builds. Then see above for length of availability of releases
• Is JDK 16 still supported? The page above mentions availability until 2021, but the supported platforms page (https://adoptium.net/supported_platforms.html) still has a column for 16
• Also, term "availability" should be reviewed. Technically, all releases on GH are still there, so it's all still "available"...

[jiekang]

Adoptium support policy page was updated alongside the website revamp. Here's an updated list of notable items:

• Policy mentions "our commitment is to triage any issues raised and champion them in the appropriate source code project". For Adoptium project management, we should have documentation on our triage and issue raising process for future contributors to understand. I believe the current case is we have a number of contacts who have the right permissions to raise bugs in upstream OpenJDK, so whenever that situation arises, we @ them in the respective issue. I think we can detail this more formally in the adoptium-support repo.
• For the release roadmap, can we link to https://www.java.com/releases/ ? This provides more exact dates for the upstream releases that we follow

[jiekang]

Noting here I plan to investigate A.1.2

[jiekang]

For A.1.2: Monitor and ensure the integrity of customer-facing repositories:

Customer facing repositories that Adoptium directly controls the uploading of artifacts to include:

• GitHub repositories, GitHub releases
  • e.g. https://github.com/adoptium/temurin17-binaries/releases
• JFrog repository
  • https://adoptium.jfrog.io/ui/packages
• Homebrew upload
  • https://formulae.brew.sh/cask/temurin#default
• DockerHub images
  • https://hub.docker.com/_/eclipse-temurin

Customer facing API that Adoptium controls and users can download artifacts from include:

• API
  • https://api.adoptium.net/
  • https://adoptium.net/ (also https://adoptium.net/marketplace)

All of the items above should be monitored to ensure the continued integrity of Adoptium artifacts that users can download onto their machines. A possible solution is to periodically download the artifacts (binary, sha file, metadata, etc.), and when applicable, verify them against an internal 'vault' copy. This should also be done using the API to monitor the integrity of that service.

Note: Third party distributors such as SDKMan/Chocolatey that take our binaries and redistribute them are not of concern for this issue.

Note: The json metadata provided by vendors for the Marketplace already includes public/private key checking