Proposal: Attestations navigation item

Summary

This issue proposes the addition of new item in the navigation under the Build menu called Attestations.

Background

Attestations are an important part of Software Supply Chain Security (and SLSA), and are used to verify the provenance and authenticity of artifacts and container images created during the build process.

Adding attestations to the navigation will make them discoverable and usable for necessary verification and audit workflows.

Link to epic / issue with overall feature proposal: SLSA Attestation UI/UX (#562795)

Software Supply Chain Security is a relatively new area GitLab is competing in for marketshare. Early signals indicate a growing desire for SSCS features from our enterprise customers.

Does this navigation proposal facilitate one of our primary JTBDs? Which job?

  1. Release publisher
  2. Deployment standardizer
  3. Deployment optimizer
  4. Standards Enforcer
  5. Compliance Examiner

How does this change improve the workflow for users attempting to complete that job? The attestation is a verifiable output from the build process that guarantees the integrity and authenticity of the output. This process enables users to properly capture all the inputs/outputs expected of the process and build downstream automation. Otherwise, processes today are manual and difficult to enforce as they rely on the correct human processing. This can also cause time delays.

From a Compliance Examiner's POV, this single file has traceability from the job to verifiable attestation. By having a list of attestations which they can verify, they no longer are reliant on manual search and validation processes to conduct their compliance audit.

How many users will be impacted by this proposed change?

  • Limited
  • Moderate
  • All users

What is the product maturity stage of the associated feature?

  • Experimental
  • Beta
  • General availability

Note: The feature is currently in development and considered experimental. We intend to move to GA quickly after the initial release. While experimental we intend to keep the navigation item behind a feature flag.

How often do you expect an average GitLab user (not just your target persona) to reach for this functionality?

  • Several times a day
  • Once a day
  • A few times a week
  • Once a week
  • Less than once a week

Approaches considered

  1. adding an Attestations link or button to the Artifacts page (https://gitlab.com/gitlab-org/gitlab/-/artifacts).
  2. Adding the attestation to the job view, and linking from there (issue).

Both of these approaches limit discoverability, and are contextually confusing because attestations can apply to both artifacts and container images.

Justification

Competing products include Attestations as part of the main navigation in their build product.

Discoverability and ease of access is critical for the success of our Attestations, especially as we continue to build new features in the SSCS space. Having a centralized access point will also address later concerns as we expand beyond Artifacts into Containers.

Review checklist

Requester

  • Review the handbook page for navigation.
  • Add relevant information to the issue description detailing your proposal, including usage and business drivers.
  • List at least two other places you considered to introduce your feature.
  • Add relevant designs to the Design Management area of the issue.
  • Ensure your UI suggestion align with the Documentation Style Guide.
  • Engage Technical Writing. They can help craft a term that best describes the feature(s) you’re proposing.
  • Follow the product development workflow validation process to ensure you are solving a well understood problem and that the proposed change is understandable and non-disruptive to users. Navigation-specific research is mandatory for additions or when restructuring.
  • Engage the Foundations Product Manager for approval. The Foundations DRI (@jtucker_gl) will work with UX partners in product design, research, and technical writing, as applicable.
  • Consider whether you need to communicate the change somehow, or if you will have an interim period in the UI where your item will live in more than one place.
  • Ensure engineers are familiar with the implementation steps for navigation.

Foundations Product Manager

  • Confirm proposal has necessary information
  • Schedule design review for next milestone

Foundations Product Designer

  • Confirm Pajamas guidelines are followed
  • Confirm a11y needs are addressed
  • Confirm burden of proof supplied for stated scope of access

Note: add these labels after internal review:

/label ~UX ~"UI text" ~"documentation" ~"Category:Navigation & Settings"  ~navigation ~type::ignore
/label ~"Nav request::Start"
Edited by Austin Regnery