SigstoreCon North America 2022

 Autodesk has a long history of producing software that commercial entities use to build and make the world around us. Trust in our software is critical to our success, and as we move to government sales, that has never been more true. Additionally, Autodesk’s software is now more than ever a hybrid of desktop and cloud based solutions. We must build and deploy software to both end user machines and public clouds. Existing software supply chain solutions must be augmented to meet these new system models and secure them wherever they live. In this talk Jesse Sanford will review how Autodesk is adapting it’s existing CI and CD tooling with the Sigstore project to meet current and future compliance needs. Jesse will speak in detail about the container provenance tracking solution built on Cosign with InToto vuln scanning attestations. A demo of our deployment governance solution will be shown which will block out of policy images from being allowed through the CD pipelines. If there is time, I will go into our future plans to implement a machine Identity solution with SPIRE for keyless signing with Cosign, Fulcio and Rekor.

By some estimates, the rate of software supply chain security attacks has more than doubled in recent years, leading to renewed demand for software integrity defenses, especially for popular open source projects. In response to this demand, healthy competition has emerged between signing technologies like Sigstore and Notary v2 to set a new standard for secure delivery of open source container images. But how do these technologies fare when applied to private container image signing? While building integrity controls for their internal Kubernetes software supply chain, Datadog's security team has found that signing and verifying images internally is subtly different than in an open source setting. This talk will compare the unique challenges of signing container images internally versus in open source, and discuss how the leading open source signing frameworks meet those challenges at scale.

Are you skeptical of how a free, transparent, and community operated code signing service can be secure? If “keyless” signing sounds too good to be true, then this is the talk for you! In this talk, we will describe what Sigstore’s public infrastructure must protect in order to deliver this visionary future of keyless signing for software supply chain security. Then, we will discuss how it achieves this using a trust root that follows Sigstore core principles for openness. And finally, for good measure, we will put a Sigstore client to the test with a demo that mimics a real-life compromise of the critical components!

Presentation talks about how InfluxData added signing of container images to its SaaS offering that uses around 100 different container images, is deployed on dozens of Kubernetes clusters in all major clouds. It shows the process from the perspective of DevOps and security teams.

It starts off by answering the important questions - “why are we doing it?” and “what would we get when this is done?”.

Session covers the roadmap InfluxData has taken to move from not signing any images, having partial checks in place to all critical workloads requiring signed images.

The SaaS offering consists of over 50 microservices, whose images are built multiple times a day via CD/CD.

It also uses open-source images by other teams inside the company as well as images provided by other companies.

The session provides details as to how each group differs and gets signed.

Presentation gives technical details on some aspects of the implementation - i.e. adding secure signing of container images in multiple CI/CD systems, key management.

It shows plans for reacting to security issues with images - from regular key rotation to getting all image signatures updated and invalidating older public keys.

Confidential computing is a breakthrough security technology. With it data can be kept encrypted during processing. Tools in the confidential computing space utilize these new concepts to provide fully-encrypted, high security environments, but as everyone in security knows: you are only as strong as your weakest link. Supply Chain Security is one of our industries weakest links. This talk will provide a deep drive of how Sigstore can help confidential (and other high security) products maintain a high level of security, keep their trusted compute base minimal, all the while preserving a high engineering velocity. To that end we will sketch out an architecture to build and sign in the cloud without malicious actors being able to steal signing keys or tamper with build processes. We will also show a live working demo of how such a system could be realized.

Recently, Kubernetes SIG-release announced that the official Kubernetes container images have adopted Sigstore code signing to protect the supply chain of millions of downstream users. Sigstore, an open-source project aiming to be the LetsEncrypt of code signing, allows Kubernetes users to validate that their images came from the simple, free, and trusted official supply chain. But how does Sigstore actually work? What happens behind the scenes when I sign an image? Why should you even trust it? This talk follows the life of a Sigstore signature for your container image. On this journey, you’ll encounter keyless code signing, certificate authorities, and transparency logs. You’ll also configure an admission controller to create a signing security policy for your clusters.Our request hits every Sigstore component and you’ll stop to learn how they work, from the cryptographic and architectural levels, and discover how Sigstore mitigates supply chain attacks.

Kubernetes offers a powerful declarative configuration management system which allows users to specify the desired state using a set of resources. In this talk, Yuji and Jim will show how you can establish trust and protect the integrity of Kubernetes resources. They will use Sigstore to sign YAML definitions and Kyverno to verify resources during admission controls. They will highlight real-world use cases for resource signing such as tamper-prevention and approval workflows which can be driven using OSS tools like Cosign and Kyverno.

Sigstore’s ecosystem enables signing, verifying, and protecting software artifacts in a new way. By doing so, we can confirm that the software is what it claims to be. As part of the rising concerns of software supply chain attacks, we decided to adopt the Sigstore tooling, integrate it as part of our environment to increase the integrity level of our software artifacts, and share our insights of the process. In implementing Sigstore's ecosystem, we encountered several challenges that may be common to other organizations - our artifacts run on cloud-native, self-hosted, and even on-premise environments, and we use several build services, including a self-hosted K8s cluster. During the talk, we’ll explore the following concepts: - The trade-off for self-hosting rekor/fulcio instances against using public ones’. - Implementing “keyless” commit signatures with the gitsign utility instead of standard GPG. - Developing methodology and tools to verify commit signatures. - Using spiffe/spire to give our ephemeral build workloads identities. - Utilizing OIDC tokens for keyless signatures on artifacts in various build environments. - Developing methodology and tools to verify artifacts.

Sigstore is coming to the Python packaging ecosystem! For the past 9 months, engineers at Trail of Bits have worked with members and stakeholders within the Sigstore community to develop sigstore-python, a high-quality Python API and CLI for performing Sigstore-style signatures and verifications. Now comes the hard part: convincing members of Python's packaging ecosystem, among the largest and most critical, to adopt Sigstore into their package publishing and consumption workflows. This talk will perform a survey of Python packaging, and consider some of the ways in which Sigstore fits into the packaging user experience. Particular consideration will be given to two groups of packaging ecosystem users: "ordinary" users, who should benefit from baseline authenticity and integrity without having to substantially alter their workflows, and "proactive" users, who should be able to opt into *additional* security guarantees (such as verification against TUF-attested claims) both when packaging and consuming others' packages.