Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

3/9/2021
03:25 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Linux Foundation Debuts Sigstore Project for Software Signing

Sigstore aims to improve the open source software supply chain by simplifying the process of cryptographic software signing.

The Linux Foundation today announced its launch of Sigstore, a new nonprofit initiative that aims to improve open source software supply chain security by making it easier for developers to adopt cryptographic signing for different components of the software development process.

Related Content:

6 Open Source Tools for Your Security Team

Special Report: How IT Security Organizations Are Attacking the Cybersecurity Problem

New From The Edge: Realistic Patch Management Tips, Post-SolarWinds

Sigstore will be free for software providers and developers, who can use it to securely sign software artifacts such as release files, container images, binaries, and bill-of-material manifests. Signing materials are then stored in a tamper-proof public log. The service's code and operation tooling will be fully open source and maintained and developed by the Sigstore community. 

Founding members include Red Hat, Google, and Purdue University. The idea for the service came from Luke Hinds, security engineering lead in Red Hat's Office of the CTO. He pitched the concept to Google software engineer Dan Lorenc, and the two began to work on it. Now the Sigstore project has a "small but agile community" working on its development, Lorenc says.

Software supply chains face security risks. Users are exposed to targeted attacks, as well as account and cryptographic key compromise. Keys are difficult for software maintainers to manage. Software projects often have a list of keys in use, and maintainers must handle the keys of people no longer involved. These public keys are often stored on git repo readme files or websites, where they may be susceptible to tampering and don't securely convey trust. 

Software signing is meant to convey trust. The process of digitally signing software is meant to provide evidence that the code comes from a known developer or software vendor and hasn't been tampered with. This gives users confidence they're using code from a trusted source.

But few open source projects cryptographically sign software artifacts. "We spent almost the last nine months or so talking to different open source maintainers and communities on how they're doing this, if they're not doing this [then] why not, and then user perspective: Do you care if people are signing? How do you know what keys to check against?" Lorenc says.

Their team found "a huge amount lacking in the space," he continues. Most software projects aren't doing anything at all to improve secure software signing. The tool sets many have used in the past require signing one other's keys in person, which doesn't work for remote developers, Hinds adds. Sigstore aims to both ease the adoption, and lower the risk, of software signing.

"When you take on signing, you take on a lot of risk as well, because … you have to protect a private key and this really exposes the risk of a project," Hinds continues. "It's a kind of chicken and egg: The need to sign things to provide assurance to their users, but once they do start to sign things, they up the ante around their attack surface and a possible key compromise."

How It Works
To make the process simple, Sigstore relies on the OpenID authentication protocol to connect certificates to identities. This allows developers to use security controls they already have, such as multifactor authentication, one-time passwords, and hardware token generators. 

Existing signing solutions essentially work to build a whole new identity system, and give users private keys they're responsible for protecting, Lorenc explains. Sigstore "piggybacks off of an existing identity system that everybody already knows how to work with, that's already federated, and already gets all the attention of security professionals at organizations." 

Sigstore users use its tooling to create ephemeral short-lived key pairs. Its public key infrastructure (PKI) service provides a signing certificate following the successful OpenID connect grant. From there, certificates are recorded into a certificate transparency log, and software signing materials go to a signature transparency log, Sigstore explains on its website.

These transparency logs are a public and tamper-proof record of sign-in events, Hinds notes. "By having that available, anybody can audit or monitor these logs for who's signing what. It makes it publicly transparent," he adds. Anyone can perform queries using an artifacts digest or return entries that are signed by a specific public key or email address. 

Because the keys are short-lived, there is no concern about keys potentially being left and vulnerable to compromise, Hinds says. After that, there's nothing left for the developer to manage and all activity is recorded in the log. 

Today marks the launch of the foundation, Hinds says. While the transparency log is fully functional, Sigstore isn't available to developers just yet. As for what developers will be able to sign and store, the team is first aiming for generic release artifacts such as compiled binaries and container images. Later on, they plan to explore other formats and manifest signing.

The team hopes Sigstore will be made available later this year, though an official date has not yet been determined.

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
Commentary
What the FedEx Logo Taught Me About Cybersecurity
Matt Shea, Head of Federal @ MixMode,  6/4/2021
Edge-DRsplash-10-edge-articles
A View From Inside a Deception
Sara Peters, Senior Editor at Dark Reading,  6/2/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-34682
PUBLISHED: 2021-06-12
Receita Federal IRPF 2021 1.7 allows a man-in-the-middle attack against the update feature.
CVE-2021-31811
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
CVE-2021-31812
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an infinite loop while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
CVE-2021-32552
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-16 package apport hooks, it could expose private data to other local users.
CVE-2021-32553
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-17 package apport hooks, it could expose private data to other local users.