Implimentation Proposal for Witness and Archivista The software supply chain faces numerous attack risks, making it crucial to establish a secure and trustworthy system for managing software metadata. A key component is the authoritative policy for a software repository, specifying rules based on attestation metadata. Distributing and trusting the policy poses challenges. It must maintain integrity and confidentiality and be trusted by all parties in the supply chain. The proposed solution uses TestifySec Witness policies and integrates Archivista as the API for the TUF repository. Witness policies enable trustworthiness of software artifacts, while Archivista manages in-toto attestations. The system includes four components: Target Client, Target Service, Snapshot Service, and Timestamp Service, with Archivista handling attestations. Archivista stores attestations in an object store, with some data in a queryable metadata store, accessible through a GraphQL API. This allows for querying relationships between attestations. By employing a TUF repository, Witness policies, and Archivista, this solution offers robust security and a reliable system for managing software metadata, ensuring secure distribution and trust in the software supply chain. Target Client Create Policy Overview

Cryptographic keys are essential to software supply chain security, but managing them can be complex and time-consuming. This is especially true for long-lived cryptographic keys stored on disk. These keys are generally used for signing artifacts or authenticating user accounts. The recent security incident at CircleCI resulting in the compromise of DataDog's RPM package signing key has brought attention to the importance of effective key management practices. Long-lived keys stored on disk can easily be compromised by attackers, allowing them to impersonate official packages and leave customers and users vulnerable to supply chain attacks. This was tragically demonstrated in the SolarWinds hack, where officially signed packages for their flagship product caused a devastating supply chain attack. An alternative approach is to use short-lived, ephemeral keys that are generated on-the-fly for each signature operation, making them more difficult for an attacker to compromise. However, verifying keyless signatures is more complex than traditional signatures, as the corresponding certificate used to validate the signature may no longer be valid when the signature needs to be verified. This article will discuss how to verify keyless signatures and how we implement keyless signing in Witness. Keyless signatures are more difficult for an attacker to compromise.